Thread: [Embeddedxen-devel] Regarding DOMU Xen-ARM
Brought to you by:
rossierd
From: akshay st <aks...@ya...> - 2013-04-23 16:45:41
|
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. 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 Warm Regards, Akshay |
From: Rossier D. <Dan...@he...> - 2013-04-24 11:14:23
|
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 |
From: Rossier D. <Dan...@he...> - 2013-04-24 11:24:26
|
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 |
From: akshay st <aks...@ya...> - 2013-04-24 16:45:35
|
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 without any drivers but simulated uart in Linux (for the busybox application)working 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 |
From: akshay st <aks...@ya...> - 2013-04-24 16:55:52
|
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 |
From: Rossier D. <Dan...@he...> - 2013-04-25 07:46:37
|
Hi Akshay, > -----Original Message----- > From: akshay st [mailto:aks...@ya...] > Sent: mercredi 24 avril 2013 18:45 > To: Rossier Daniel; emb...@li... > 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. Sure, you can find all information here: http://sourceforge.net/p/embeddedxen/code/ci/master/tree/ The cloning line is: git clone git://git.code.sf.net/p/embeddedxen/code embeddedxen-code > > Any issues with source forge code repository? No, the code is working, but we have reworked quite a lot of things and fixed various issues in the head git. So, I recommend to work on the git version. And you will also find some additional domU (especially 3.4.6-domU) which is more recent and can work with a complete rootfs (rootfs is also available for download : http://sourceforge.net/projects/embeddedxen/files/rootfs/ (We will also upload a light qt-enabled rootfs). By the way, what domU are you using ? > > I have got basic DOMu without any drivers but simulated uart in Linux (for > the busybox application)working 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? > Definitively. If you call flush_cashe_range, make sure to have IRQs disabled before otherwise you will get possible inconsistencies. Back to the current code (2.6.26-domU), IRQs are disabled anyway when devicemaps_init() is called. Maybe, it can be worth to summarize the different steps we need to take care in devicemaps_init(). Let's examine the situation at the beginning of devicemaps_init(): The current running vector page (at 0xffff0000 location) is actually a simple mapping of the original hypervisor vector page but in the domU virtual address space. We can't simply leave this page as such for domU because there are some other stuff used by user helpers of the guest domain (you have currently information used by dom0). For sure, domU will need to use its own helpers data. Furthermore, some additional cache flush mapping can reside in this page as well, which is partly controlled by the guest (not only by the hypervisor). It means that domU must have its own vector page, even if the interrupt vectors remain the same because the ISRs still belong to the hypervisor. So, we start doing a copy of the vector page in a new page allocated to domU, thus preserving the hypervisor vectors. Then, we also allocate a guest vector page (another domU-private page) which will store the *real* vectors of domU used during the upcall path to call the right handlers. However, this guest vector page must be known by the domU kernel, but is not resident at 0xffff0000. Finally, we are mapping the true vector page (0xffff0000) on the duplicated page containing the hypervisor vectors in order to make this vector page private to the domU address space. And doing a flush which, in our case as you saw, leads to an hypercall which in turn leads to re-enable IRQs during the upcall (so, after the hypervisor has done the flush!). That's why all the IRQs vector machinery has to be set-up correctly before descending into the hypervisor. > 1 more thing if i mail directly (of course will keep embeddedxen mailling list in > CC)to your email id will it work? Sure. Cheers Daniel > > 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 |
From: akshay st <aks...@ya...> - 2013-08-27 06:23:09
|
Daniel, Do you have Xen support for SMP ARM A9? If yes can you please point me to the code. Warm Regards, Akshay ________________________________ From: Rossier Daniel <Dan...@he...> To: akshay st <aks...@ya...>; "emb...@li..." <emb...@li...> Sent: Thursday, 25 April 2013 1:16 PM Subject: RE: [Embeddedxen-devel] Regarding DOMU Xen-ARM Hi Akshay, > -----Original Message----- > From: akshay st [mailto:aks...@ya...] > Sent: mercredi 24 avril 2013 18:45 > To: Rossier Daniel; emb...@li... > 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. Sure, you can find all information here: http://sourceforge.net/p/embeddedxen/code/ci/master/tree/ The cloning line is: git clone git://git.code.sf.net/p/embeddedxen/code embeddedxen-code > > Any issues with source forge code repository? No, the code is working, but we have reworked quite a lot of things and fixed various issues in the head git. So, I recommend to work on the git version. And you will also find some additional domU (especially 3.4.6-domU) which is more recent and can work with a complete rootfs (rootfs is also available for download : http://sourceforge.net/projects/embeddedxen/files/rootfs/ (We will also upload a light qt-enabled rootfs). By the way, what domU are you using ? > > I have got basic DOMu without any drivers but simulated uart in Linux (for > the busybox application)working 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? > Definitively. If you call flush_cashe_range, make sure to have IRQs disabled before otherwise you will get possible inconsistencies. Back to the current code (2.6.26-domU), IRQs are disabled anyway when devicemaps_init() is called. Maybe, it can be worth to summarize the different steps we need to take care in devicemaps_init(). Let's examine the situation at the beginning of devicemaps_init(): The current running vector page (at 0xffff0000 location) is actually a simple mapping of the original hypervisor vector page but in the domU virtual address space. We can't simply leave this page as such for domU because there are some other stuff used by user helpers of the guest domain (you have currently information used by dom0). For sure, domU will need to use its own helpers data. Furthermore, some additional cache flush mapping can reside in this page as well, which is partly controlled by the guest (not only by the hypervisor). It means that domU must have its own vector page, even if the interrupt vectors remain the same because the ISRs still belong to the hypervisor. So, we start doing a copy of the vector page in a new page allocated to domU, thus preserving the hypervisor vectors. Then, we also allocate a guest vector page (another domU-private page) which will store the *real* vectors of domU used during the upcall path to call the right handlers. However, this guest vector page must be known by the domU kernel, but is not resident at 0xffff0000. Finally, we are mapping the true vector page (0xffff0000) on the duplicated page containing the hypervisor vectors in order to make this vector page private to the domU address space. And doing a flush which, in our case as you saw, leads to an hypercall which in turn leads to re-enable IRQs during the upcall (so, after the hypervisor has done the flush!). That's why all the IRQs vector machinery has to be set-up correctly before descending into the hypervisor. > 1 more thing if i mail directly (of course will keep embeddedxen mailling list in > CC)to your email id will it work? Sure. Cheers Daniel > > 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 |
From: Rossier D. <Dan...@he...> - 2013-08-27 09:52:12
|
Hi Akshay, Yeap, we are currently working on that point these days. For the time being, we do not push our progress on sourceforge since we have preferred to maintain separate repositories to avoid confusion. The board we are working on is a ZynQ Zedboard with an integrated Cortex-A9 and FPGA. We ported the dom0 and domU so far, and now we are looking for a scenario where we want to run dom0 on one core and domU on the other. Tell me if you are interested in this work, we would be happy to collaborate (I put in cc Christian who is working on SMP). Kind regards, Daniel From: akshay st [mailto:aks...@ya...] Sent: mardi 27 août 2013 10:38 To: akshay st; Rossier Daniel; emb...@li... Subject: [Embeddedxen-devel] Xen support for ARM A9 SMP mode Changing the subject. Daniel, Do you have Xen support for SMP ARM A9? If yes can you please point me to the code. Warm Regards, Akshay |
From: akshay st <aks...@ya...> - 2013-08-29 14:06:22
|
Daniel, I am interested to work , however i will not be able to work full time(but can dedicate some part of my time for this), please let me know the expectations , Good to hear u r working on zynq zed board. i have a zynq zed board with me too and am quite familiar with basic peripherals. We are using Zynq as our reference board for now. Warm Regards, Akshay ________________________________ From: Rossier Daniel <Dan...@he...> To: akshay st <aks...@ya...>; "emb...@li..." <emb...@li...> Cc: Müller Christian <chr...@he...> Sent: Tuesday, 27 August 2013 3:06 PM Subject: RE: [Embeddedxen-devel] Xen support for ARM A9 SMP mode Hi Akshay, Yeap, we are currently working on that point these days. For the time being, we do not push our progress on sourceforge since we have preferred to maintain separate repositories to avoid confusion. The board we are working on is a ZynQ Zedboard with an integrated Cortex-A9 and FPGA. We ported the dom0 and domU so far, and now we are looking for a scenario where we want to run dom0 on one core and domU on the other. Tell me if you are interested in this work, we would be happy to collaborate (I put in cc Christian who is working on SMP). Kind regards, Daniel From:akshay st [mailto:aks...@ya...] Sent: mardi 27 août 2013 10:38 To: akshay st; Rossier Daniel; emb...@li... Subject: [Embeddedxen-devel] Xen support for ARM A9 SMP mode Changing the subject. Daniel, Do you have Xen support for SMP ARM A9? If yes can you please point me to the code. Warm Regards, Akshay |
From: akshay st <aks...@ya...> - 2013-08-27 08:38:35
|
Changing the subject. Daniel, Do you have Xen support for SMP ARM A9? If yes can you please point me to the code. Warm Regards,Akshay |