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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Resending again as it appears sourceforge website wont accept more than certain characters per line.

----- Forwarded Message -----
From: akshay st <aks...@ya...>
To: Rossier Daniel <Dan...@he...>; "emb...@li..." <emb...@li...>
Cc: 
Sent: Wednesday, 24 April 2013 10:15 PM
Subject: Re: [Embeddedxen-devel] Regarding DOMU Xen-ARM

Thanks Daniel for the reply.

I have directly downloaded Embedded Xen 2.1 from SourceForge. Can you please point me to git path? i couldn't find one.

Any issues with source forge code repository?

I have got basic DOMu working  without any drivers but simulated uart in Linux (for the busybox application)with some hacks. Basically
 i call
    local_flush_tlb_all();
    flush_cache_all();
in multiple places of devicemaps_init. For some reason, this solved the issue, Although i don't know how it got solved.

I am thinking the problem may be because of following
Basically in the code it clears Page table entry 0xffff0000, after that there is flush_cache_range and then my disable_IRQ, 
local_tlb_flush_all.  Now even though flush_cache_range clears cache , if interrupt occurs if TLB is valid it can populate 
the cache after TLB Walk.  However if TLB is not valid then it may hang. I am thinking solution can be to disable irq before 
we clear pagetable entry and reenable after we copy the vectors properly. I will try this sometime tomorrow.  
Does this theory make any logical sense?

1 more thing if i mail directly (of course will keep embeddedxen mailling list in CC)to your email id 
will it work?

Warm Regards,
Akshay

----- Original Message -----

From: Rossier Daniel <Dan...@he...>
To: Rossier Daniel <Dan...@he...>; akshay st <aks...@ya...>; "emb...@li..." <emb...@li...>
Cc: 
Sent: Wednesday, 24 April 2013 4:54 PM
Subject: RE: [Embeddedxen-devel] Regarding DOMU Xen-ARM

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 