Thread: Re: [Embeddedxen-devel] [Xenomai-help] Running Xenomai in a virtual machine
Brought to you by:
rossierd
From: ROSSIER D. <Dan...@he...> - 2009-06-22 15:05:18
|
> -----Original Message----- > From: Gilles Chanteperdrix [mailto:gil...@xe...] > Sent: lundi, 22. juin 2009 16:27 > To: ROSSIER Daniel > Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen- > de...@li... > Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > > ROSSIER Daniel wrote: > >> -----Original Message----- > >> From: Jan Kiszka [mailto:jan...@si...] > >> Sent: lundi, 22. juin 2009 15:55 > >> To: ROSSIER Daniel > >> Cc: Johan Visser; xen...@gn... > >> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > >> > >> ROSSIER Daniel wrote: > >>> Just going through this interesting thread, I though it might be of > >> interest - probably not fully related to the topic, but... - to know > >>> that we are currently working on some integration efforts of > Xenomai > >> on top of the XEN hypervisor in the context of the > >>> embeddedXEN project. For the time being, it is purely devoted to > ARM- > >> based processors. > >>> In case of interest, please visit: > >> https://sourceforge.net/projects/embeddedxen. Xenomai will appear as > a > >> natural subtree of embeddedXEN, like xen or minios, > >>> but currently it is not present yet. The hypervisor and miniOS > boots > >> up in Mainstone/QEMU and soon on a Colibri/PXA270 board. EmbeddedXEN > is > >> mainly devoted to integrate multiple kernels into a single binary > image > >> for embedded systems with the support of hard realtime (domainU-RT, > a > >> new kind of Xen domain). > >> > >> Interesting, will have a look (again). Last time I checked was two > >> years > >> ago when MontaVista (IIRC) announced it. Does/will this version Xen > not > >> suffer from the RT problems Xen upstream has, e.g. lacking > >> preemptibility? > > > > Indeed, it is a major point we want to investigate; we will assess > the overhead bound > > to the upcall model of XEN. It is too early to make some predictions > > > >> And what will be the impact on Xenomai? A new sub-arch per real > arch? > >> Will Xenomai run stand-alone or together with a Linux kernel as on > real > >> silicon? In the former case, what will be the programming model, > >> specifically regarding RT<->non-RT communication? > > > > We are actually working out a standalone version of Xenomai (removing > i-pipe) keeping > > the strict minimum of Linux functionalities in order to bootstrap a > simple Xenomai domain (memory manager, . > > I do not have yet a clear vision of how the RT/non-RT communication > will look like, but probably > > it will rely on the event channel mechanisms of XEN. Maybe Patrick > can tell us more about that... > > Maybe a stupid question: but does the Xen domain/context switch routine > flush the cache? Not really a stupid question: every time a MMU-context switch occurs, the flash is invalidated, therefore mostly each time there is a domain context switch. The way how it is invalidated will depend on the processor; it is badly implemented with PXA270/Xscale where the entire cash is flushed, requiring quite a lot of latency... We can improve it using the Fast Context Switching Extension, but never made some tests with that. Daniel > > -- > Gilles |
From: ROSSIER D. <Dan...@he...> - 2009-06-22 15:45:39
|
> -----Original Message----- > From: Gilles Chanteperdrix [mailto:gil...@xe...] > Sent: lundi, 22. juin 2009 17:17 > To: ROSSIER Daniel > Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen- > de...@li... > Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > > ROSSIER Daniel wrote: > >> -----Original Message----- > >> From: Gilles Chanteperdrix [mailto:gil...@xe...] > >> Sent: lundi, 22. juin 2009 16:27 > >> To: ROSSIER Daniel > >> Cc: Jan Kiszka; xen...@gn...; GERBER Patrick; embeddedxen- > >> de...@li... > >> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > >> > >> ROSSIER Daniel wrote: > >>>> -----Original Message----- > >>>> From: Jan Kiszka [mailto:jan...@si...] > >>>> Sent: lundi, 22. juin 2009 15:55 > >>>> To: ROSSIER Daniel > >>>> Cc: Johan Visser; xen...@gn... > >>>> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > >>>> > >>>> ROSSIER Daniel wrote: > >>>>> Just going through this interesting thread, I though it might be > of > >>>> interest - probably not fully related to the topic, but... - to > know > >>>>> that we are currently working on some integration efforts of > >> Xenomai > >>>> on top of the XEN hypervisor in the context of the > >>>>> embeddedXEN project. For the time being, it is purely devoted to > >> ARM- > >>>> based processors. > >>>>> In case of interest, please visit: > >>>> https://sourceforge.net/projects/embeddedxen. Xenomai will appear > as > >> a > >>>> natural subtree of embeddedXEN, like xen or minios, > >>>>> but currently it is not present yet. The hypervisor and miniOS > >> boots > >>>> up in Mainstone/QEMU and soon on a Colibri/PXA270 board. > EmbeddedXEN > >> is > >>>> mainly devoted to integrate multiple kernels into a single binary > >> image > >>>> for embedded systems with the support of hard realtime (domainU- > RT, > >> a > >>>> new kind of Xen domain). > >>>> > >>>> Interesting, will have a look (again). Last time I checked was two > >>>> years > >>>> ago when MontaVista (IIRC) announced it. Does/will this version > Xen > >> not > >>>> suffer from the RT problems Xen upstream has, e.g. lacking > >>>> preemptibility? > >>> Indeed, it is a major point we want to investigate; we will assess > >> the overhead bound > >>> to the upcall model of XEN. It is too early to make some > predictions > >>> > >>>> And what will be the impact on Xenomai? A new sub-arch per real > >> arch? > >>>> Will Xenomai run stand-alone or together with a Linux kernel as on > >> real > >>>> silicon? In the former case, what will be the programming model, > >>>> specifically regarding RT<->non-RT communication? > >>> We are actually working out a standalone version of Xenomai > (removing > >> i-pipe) keeping > >>> the strict minimum of Linux functionalities in order to bootstrap a > >> simple Xenomai domain (memory manager, . > >>> I do not have yet a clear vision of how the RT/non-RT communication > >> will look like, but probably > >>> it will rely on the event channel mechanisms of XEN. Maybe Patrick > >> can tell us more about that... > >> > >> Maybe a stupid question: but does the Xen domain/context switch > routine > >> flush the cache? > > > > Not really a stupid question: every time a MMU-context switch occurs, > the flash is > > invalidated, therefore mostly each time there is a domain context > switch. > > The way how it is invalidated will depend on the processor; it is > badly implemented > > with PXA270/Xscale where the entire cash is flushed, requiring quite > a lot of latency... > > We can improve it using the Fast Context Switching Extension, but > never made some tests with that. > > The problem I see with FCSE is that you will need a way to allocate the > PIDs globally, i.e. at Xen level. > Yeap. It will definitively not be obvious to manage. Thanks anyway for raising up the issue. Any idea is welcome.... > -- > Gilles |
From: ROSSIER D. <Dan...@he...> - 2009-06-22 19:41:30
|
> -----Original Message----- > From: Jan Kiszka [mailto:jan...@si...] > Sent: lundi, 22. juin 2009 15:55 > To: ROSSIER Daniel > Cc: Johan Visser; xen...@gn... > Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine > > ROSSIER Daniel wrote: > > Just going through this interesting thread, I though it might be of > interest - probably not fully related to the topic, but... - to know > > that we are currently working on some integration efforts of Xenomai > on top of the XEN hypervisor in the context of the > > embeddedXEN project. For the time being, it is purely devoted to ARM- > based processors. > > > > In case of interest, please visit: > https://sourceforge.net/projects/embeddedxen. Xenomai will appear as a > natural subtree of embeddedXEN, like xen or minios, > > but currently it is not present yet. The hypervisor and miniOS boots > up in Mainstone/QEMU and soon on a Colibri/PXA270 board. EmbeddedXEN is > mainly devoted to integrate multiple kernels into a single binary image > for embedded systems with the support of hard realtime (domainU-RT, a > new kind of Xen domain). > > Interesting, will have a look (again). Last time I checked was two > years > ago when MontaVista (IIRC) announced it. Does/will this version Xen not > suffer from the RT problems Xen upstream has, e.g. lacking > preemptibility? Indeed, it is a major point we want to investigate; we will assess the overhead bound to the upcall model of XEN. It is too early to make some predictions > > And what will be the impact on Xenomai? A new sub-arch per real arch? > Will Xenomai run stand-alone or together with a Linux kernel as on real > silicon? In the former case, what will be the programming model, > specifically regarding RT<->non-RT communication? We are actually working out a standalone version of Xenomai (removing i-pipe) keeping the strict minimum of Linux functionalities in order to bootstrap a simple Xenomai domain (memory manager, . I do not have yet a clear vision of how the RT/non-RT communication will look like, but probably it will rely on the event channel mechanisms of XEN. Maybe Patrick can tell us more about that... Daniel > > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux |