Re: [Embeddedxen-devel] [Xenomai-help] Running Xenomai in a virtual machine

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

> -----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