Re: [Embeddedxen-devel] Regarding DOMU Xen-ARM

[Rossier D. <Dan...@he...>]

By the way, are you using the release from files available on Sourceforge or from git directly?

We strongly suggest that for now you are working with the last git source code.
We plan to make a new release (with tar.gz files) in the middle of the Year.

In the git version, we're doing nearly daily updates.

Cheers

Daniel


> -----Original Message-----
> From: Rossier Daniel [mailto:Dan...@he...]
> Sent: mercredi 24 avril 2013 13:01
> To: akshay st; emb...@li...
> Subject: Re: [Embeddedxen-devel] Regarding DOMU Xen-ARM
> 
> Hi Akshay,
> 
> > -----Original Message-----
> > From: akshay st [mailto:aks...@ya...]
> > Sent: mardi 23 avril 2013 18:46
> > To: emb...@li...
> > Subject: [Embeddedxen-devel] Regarding DOMU Xen-ARM
> >
> > Hi,
> > I took Embedded Xen 2.1 sources for ARM, i am modifiying for my
> > board, i could understand and bring up DOM0 without issues, However i
> > have some doubts regarding DOMU w.r.t devicemaps_init(),
> > Here we wont
> >  clear oxFFFF0000 for high vectors assuming that during upcall ISR may
> > come(Because of flush), However in my implementation i dont use XEN
> > hyper calls For TLb/Cache flush , i take the same implementation as
> > DOM0(which i guess it shd be ok?). Basically i keep devicemaps_init()
> > implementation same as DOM0, With this when i run local_flush_tlb_all()
> > Linux hangs, I have disabled IRQ's before using local_irq_disable(). I
> > dont know why it hangs, Any pointers will be helpful.
> 
> Well, even if you do not use hypercall at this stage, you need consistent
> vectors since some IRQs
> previously configured by dom0 may occur (of course, if you disable IRQs, you
> should not have any problem).
> That's why domU vectors are placed somewhere else in the memory.
> Try to debug step-by-step the flush function to see what happens. It may
> well be a freeze after the local_flush_tlb_all()
> at a point where IRQs get re-enabled...
> 
> >
> > 1 more question on devicemaps_init
> > Why
> >  is the below commented on DOMu and not on DOM0, Does Xen
> Hypervisor
> > populate any of this area? if so what does it do and can you please
> > point me to the code?
> > #if 0
> >     for (addr = VMALLOC_END; addr < HYPERVISOR_VIRT_START; addr +=
> > PGDIR_SIZE)
> >         pmd_clear(pmd_off_k(addr));
> > #endif
> 
> Basically, you do not need any I/Os in domU since hardware access are under
> control of dom0.
> Except for debug purposes, but it  mainly concerns UART.
> So we can leave the mapped I/O as such in domU without doing any I/O
> mapping.
> 
> I hope it helps.
> 
> Regards
> Daniel
> 
> >
> > Warm Regards,
> > Akshay
> >
> >
> > ------------------------------------------------------------------------------
> > Try New Relic Now & We'll Send You this Cool Shirt
> > New Relic is the only SaaS-based application performance monitoring
> service
> > that delivers powerful full stack analytics. Optimize and monitor your
> > browser, app, & servers with just a few lines of code. Try New Relic
> > and get this awesome Nerd Life shirt!
> http://p.sf.net/sfu/newrelic_d2d_apr
> > _______________________________________________
> > Embeddedxen-devel mailing list
> > Emb...@li...
> > https://lists.sourceforge.net/lists/listinfo/embeddedxen-devel
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> _______________________________________________
> Embeddedxen-devel mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embeddedxen-devel