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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

ROSSIER Daniel wrote:
>> -----Original Message-----
>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Sent: lundi, 22. juin 2009 16:27
>> To: ROSSIER Daniel
>> Cc: Jan Kiszka; xenomai@xenomai.org; GERBER Patrick; embeddedxen-
>> devel@domain.hid
>> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
>>
>> ROSSIER Daniel wrote:
>>>> -----Original Message-----
>>>> From: Jan Kiszka [mailto:jan.kiszka@domain.hid]
>>>> Sent: lundi, 22. juin 2009 15:55
>>>> To: ROSSIER Daniel
>>>> Cc: Johan Visser; xenomai@xenomai.org
>>>> 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.

-- 
                                          Gilles