[Xenomai-help] Running Xenomai in a virtual machine

[Xenomai-help] Running Xenomai in a virtual machine

[Peter Soetens]

I'm looking for a more agile way to run my unit tests (and build farm)
on a Xenomai system, without running them directly my development
system (nor rebooting to a Xenomai patched kernel). I was hoping that
a virtualisation solution would do the trick. Does anyone have
experience with running a Xenomai patched kernel + applicaiton in
vmware or another virtualisation package ?

I've found this http://www.cs.ru.nl/lab/xenomai/vmware.html
but I was hoping to hear if this is gonna work or what the best combination is.

Peter

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

[Sebastian Smolorz]

Peter Soetens wrote:
> I'm looking for a more agile way to run my unit tests (and build farm)
> on a Xenomai system, without running them directly my development
> system (nor rebooting to a Xenomai patched kernel). I was hoping that
> a virtualisation solution would do the trick. Does anyone have
> experience with running a Xenomai patched kernel + applicaiton in
> vmware or another virtualisation package ?
>

Xenomai runs perfectly inside qemu, without real-time guarantees, of course.

-- 
Sebastian

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

[Jan Kiszka]

Sebastian Smolorz wrote:
> Peter Soetens wrote:
>> I'm looking for a more agile way to run my unit tests (and build farm)
>> on a Xenomai system, without running them directly my development
>> system (nor rebooting to a Xenomai patched kernel). I was hoping that
>> a virtualisation solution would do the trick. Does anyone have
>> experience with running a Xenomai patched kernel + applicaiton in
>> vmware or another virtualisation package ?
>>
> 
> Xenomai runs perfectly inside qemu, without real-time guarantees, of course.
> 

Most of the time we are developing on and for Xenomai inside qemu-kvm,
often using '-smp 2' (or more) and an SMP host so that the more
interesting races are triggered. In contrast to other hypervisors, this
offers the chance to do source-level kernel debugging, also when the
target hopelessly locked up deep inside I-pipe - situations that are
almost undebugable on real x86 hardware.

For sure, you don't get reasonable latencies this way (though evaluating
kvm under -rt /wrt soft-rt is on my to-do list for the next weeks), but
a lot of testing does not require this anyway. Moreover, qemu/kvm
cleanly integrates with Linux, thus can easily be scripted. If you plan
to set up some test farm, you may also want to have a look at
kvm-autotest (currently under merge into autotest).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Peter Soetens]

On Fri, Jun 12, 2009 at 13:02, Jan Kiszka<jan.kiszka@domain.hid> wrote:
> Sebastian Smolorz wrote:
>> Peter Soetens wrote:
>>> I'm looking for a more agile way to run my unit tests (and build farm)
>>> on a Xenomai system, without running them directly my development
>>> system (nor rebooting to a Xenomai patched kernel). I was hoping that
>>> a virtualisation solution would do the trick. Does anyone have
>>> experience with running a Xenomai patched kernel + applicaiton in
>>> vmware or another virtualisation package ?
>>>
>>
>> Xenomai runs perfectly inside qemu, without real-time guarantees, of course.
>>
>
> Most of the time we are developing on and for Xenomai inside qemu-kvm,
> often using '-smp 2' (or more) and an SMP host so that the more
> interesting races are triggered. In contrast to other hypervisors, this
> offers the chance to do source-level kernel debugging, also when the
> target hopelessly locked up deep inside I-pipe - situations that are
> almost undebugable on real x86 hardware.
>
> For sure, you don't get reasonable latencies this way (though evaluating
> kvm under -rt /wrt soft-rt is on my to-do list for the next weeks), but
> a lot of testing does not require this anyway. Moreover, qemu/kvm
> cleanly integrates with Linux, thus can easily be scripted. If you plan
> to set up some test farm, you may also want to have a look at
> kvm-autotest (currently under merge into autotest).

Thank you for your answers !

Peter

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

[Johan Visser]

Jan Kiszka schreef:
> Sebastian Smolorz wrote:
>   
>> Peter Soetens wrote:
>>     
>>> I'm looking for a more agile way to run my unit tests (and build farm)
>>> on a Xenomai system, without running them directly my development
>>> system (nor rebooting to a Xenomai patched kernel). I was hoping that
>>> a virtualisation solution would do the trick. Does anyone have
>>> experience with running a Xenomai patched kernel + applicaiton in
>>> vmware or another virtualisation package ?
>>>
>>>       
>> Xenomai runs perfectly inside qemu, without real-time guarantees, of course.
>>
>>     
>
> Most of the time we are developing on and for Xenomai inside qemu-kvm,
> often using '-smp 2' (or more) and an SMP host so that the more
> interesting races are triggered. In contrast to other hypervisors, this
> offers the chance to do source-level kernel debugging, also when the
> target hopelessly locked up deep inside I-pipe - situations that are
> almost undebugable on real x86 hardware.
>
> For sure, you don't get reasonable latencies this way (though evaluating
> kvm under -rt /wrt soft-rt is on my to-do list for the next weeks), but
> a lot of testing does not require this anyway. Moreover, qemu/kvm
> cleanly integrates with Linux, thus can easily be scripted. If you plan
> to set up some test farm, you may also want to have a look at
> kvm-autotest (currently under merge into autotest).
>
> Jan
>
>   
Just the last few days we were trying to do the same with our XENOMAI 
system and application.

According the package info I can not use KVM because the processor of my 
laptop does not have hardware virtualisation support.
Virtualbox failed on a standard PC , it took 5 minutes to boot my guest 
and then after that froze.
VMware runs, but gives heavy CPU load ( about 38 % ) instead of 6-8 % on 
a real system.
The application runs, but of course it is not realtime.

The system i am using on my laptop is a standard Ubuntu system.

I was wondering if the kernel running on my host system is of importance 
too.
Now it schedules at 250 HZ. I tried to use a -rt kernel fom the ubuntu 
repository ( 1000 Hz ) but this will not work on my system some how.

-- 
Ing. Johan Visser
Stork Plastics Machinery B.V.
Tel. : +31 742405113
Mob. : +31 653731518

----------------------------------------------------
Stork Plastics Machinery B.V. Alfred Marshallstraat 2, 7559 SE Hengelo, the Netherlands.
Supplies and executions to the conditions and stipulations filed with the Chamber of Commerce (Trade register Enschede nr. 06041991) except as otherwise provided in writing.
DISCLAIMER:
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or taking any action in reliance of the contents of this information is strictly prohibited and may be unlawful. Stork Plastics Machinery is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. 

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

[Jan Kiszka]

Johan Visser wrote:
> Jan Kiszka schreef:
>> Sebastian Smolorz wrote:
>>  
>>> Peter Soetens wrote:
>>>    
>>>> I'm looking for a more agile way to run my unit tests (and build farm)
>>>> on a Xenomai system, without running them directly my development
>>>> system (nor rebooting to a Xenomai patched kernel). I was hoping that
>>>> a virtualisation solution would do the trick. Does anyone have
>>>> experience with running a Xenomai patched kernel + applicaiton in
>>>> vmware or another virtualisation package ?
>>>>
>>>>       
>>> Xenomai runs perfectly inside qemu, without real-time guarantees, of
>>> course.
>>>
>>>     
>>
>> Most of the time we are developing on and for Xenomai inside qemu-kvm,
>> often using '-smp 2' (or more) and an SMP host so that the more
>> interesting races are triggered. In contrast to other hypervisors, this
>> offers the chance to do source-level kernel debugging, also when the
>> target hopelessly locked up deep inside I-pipe - situations that are
>> almost undebugable on real x86 hardware.
>>
>> For sure, you don't get reasonable latencies this way (though evaluating
>> kvm under -rt /wrt soft-rt is on my to-do list for the next weeks), but
>> a lot of testing does not require this anyway. Moreover, qemu/kvm
>> cleanly integrates with Linux, thus can easily be scripted. If you plan
>> to set up some test farm, you may also want to have a look at
>> kvm-autotest (currently under merge into autotest).
>>
>> Jan
>>
>>   
> Just the last few days we were trying to do the same with our XENOMAI
> system and application.
> 
> According the package info I can not use KVM because the processor of my
> laptop does not have hardware virtualisation support.

If /proc/cpuinfo lacks vmx (intel) or svm (amd) *and* there is no magic
switch in your notebook's bios to enable virtualization, then you are
out of luck /wrt accelerated qemu(-kvm) use. You could still use qemu in
emulation mode, but that is 10..40 times slower than native (but still
better than nothing if you have to debug the guest kernel - I've done
this before kvm arrived).

> Virtualbox failed on a standard PC , it took 5 minutes to boot my guest
> and then after that froze.
> VMware runs, but gives heavy CPU load ( about 38 % ) instead of 6-8 % on
> a real system.

That's expected if your CPU actually lacks hardware virtualization.

> The application runs, but of course it is not realtime.
> 
> The system i am using on my laptop is a standard Ubuntu system.
> 
> I was wondering if the kernel running on my host system is of importance
> too.
> Now it schedules at 250 HZ. I tried to use a -rt kernel fom the ubuntu
> repository ( 1000 Hz ) but this will not work on my system some how.

All modern distros have high-resolution timers enabled, so the kernel's
scheduler tick doesn't really matter anymore (unless the hypervisor
screws it up...). I can watch best-case 'latency' results under kvm that
are in the order of some ten microseconds. But the worst case is more
about some ten ms on a normal distro kernel (CONFIG_PREEMPT_VOLUNTARY
here, still need to try PREEMPT_RT). But even with -RT, there will
remain critical code paths in the hypervisor that go through RT-unsuited
host kernel subsystems, so you will get a better average, but no guarantees.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Jan Kiszka]

Jan Kiszka wrote:
> ... You could still use qemu in
> emulation mode, but that is 10..40 times slower than native (but still
> better than nothing if you have to debug the guest kernel - I've done
> this before kvm arrived).

BTW, another advantage of qemu is that you could write a model of your
possibly non-standard I/O hardware and even run your drivers in qemu
against this model. That works both with and without kvm support.

And as we are at it: qemu (in emulation mode) is also capable of
providing a host for ARM, PPC, MIPS, etc. targets. An example: I'm able
to run the unmodified Linux firmware of my ARM-based webradio inside
qemu, and it works as in real life (it just boots faster in qemu than on
real silicon ;)).

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Johan Visser]

Jan Kiszka schreef:
> Jan Kiszka wrote:
>   
>> ... You could still use qemu in
>> emulation mode, but that is 10..40 times slower than native (but still
>> better than nothing if you have to debug the guest kernel - I've done
>> this before kvm arrived).
>>     
>
> BTW, another advantage of qemu is that you could write a model of your
> possibly non-standard I/O hardware and even run your drivers in qemu
> against this model. That works both with and without kvm support.
>   
The IO is driven by ethernet :-)        so if it were real time....
We are now simulating real time ( on a live system ) on  a functional basis,
My guest system programs the int0 to go at 1000 Hz, that is why I wonder 
if the used host system config matters.

> And as we are at it: qemu (in emulation mode) is also capable of
> providing a host for ARM, PPC, MIPS, etc. targets. An example: I'm able
> to run the unmodified Linux firmware of my ARM-based webradio inside
> qemu, and it works as in real life (it just boots faster in qemu than on
> real silicon ;)).
>   
by real-life system nowadays is an ATOM based cpu board...
> Jan
>
>   

-- 
Ing. Johan Visser
Stork Plastics Machinery B.V.
Tel. : +31 742405113
Mob. : +31 653731518

----------------------------------------------------
Stork Plastics Machinery B.V. Alfred Marshallstraat 2, 7559 SE Hengelo, the Netherlands.
Supplies and executions to the conditions and stipulations filed with the Chamber of Commerce (Trade register Enschede nr. 06041991) except as otherwise provided in writing.
DISCLAIMER:
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or taking any action in reliance of the contents of this information is strictly prohibited and may be unlawful. Stork Plastics Machinery is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. 

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

[ROSSIER Daniel]

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

If you're interested to contribute, simply tell us through the mailing list (embeddedxen-devel@domain.hid)

Daniel

> -----Original Message-----
> From: xenomai-help-bounces@domain.hid [mailto:xenomai-help-
> bounces@domain.hid] On Behalf Of Johan Visser
> Sent: vendredi, 12. juin 2009 16:34
> To: Jan Kiszka
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Running Xenomai in a virtual machine
> 
> Jan Kiszka schreef:
> > Jan Kiszka wrote:
> >
> >> ... You could still use qemu in
> >> emulation mode, but that is 10..40 times slower than native (but
> still
> >> better than nothing if you have to debug the guest kernel - I've
> done
> >> this before kvm arrived).
> >>
> >
> > BTW, another advantage of qemu is that you could write a model of
> your
> > possibly non-standard I/O hardware and even run your drivers in qemu
> > against this model. That works both with and without kvm support.
> >
> The IO is driven by ethernet :-)        so if it were real time....
> We are now simulating real time ( on a live system ) on  a functional
> basis,
> My guest system programs the int0 to go at 1000 Hz, that is why I
> wonder
> if the used host system config matters.
> 
> > And as we are at it: qemu (in emulation mode) is also capable of
> > providing a host for ARM, PPC, MIPS, etc. targets. An example: I'm
> able
> > to run the unmodified Linux firmware of my ARM-based webradio inside
> > qemu, and it works as in real life (it just boots faster in qemu than
> on
> > real silicon ;)).
> >
> by real-life system nowadays is an ATOM based cpu board...
> > Jan
> >
> >
> 
> --
> Ing. Johan Visser
> Stork Plastics Machinery B.V.
> Tel. : +31 742405113
> Mob. : +31 653731518
> 
> ----------------------------------------------------
> Stork Plastics Machinery B.V. Alfred Marshallstraat 2, 7559 SE Hengelo,
> the Netherlands.
> Supplies and executions to the conditions and stipulations filed with
> the Chamber of Commerce (Trade register Enschede nr. 06041991) except
> as otherwise provided in writing.
> DISCLAIMER:
> The information contained in this communication is confidential and may
> be legally privileged. It is intended solely for the use of the
> individual or entity to whom it is addressed and others authorized to
> receive it. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or taking any
> action in reliance of the contents of this information is strictly
> prohibited and may be unlawful. Stork Plastics Machinery is neither
> liable for the proper and complete transmission of the information
> contained in this communication nor for any delay in its receipt.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

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

[Jan Kiszka]

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?

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?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[ROSSIER Daniel]

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

Daniel


> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux

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

[Gilles Chanteperdrix]

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?

-- 
                                          Gilles

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

[ROSSIER Daniel]

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


Daniel

> 
> --
>                                           Gilles

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

[Gilles Chanteperdrix]

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

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

[ROSSIER Daniel]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: lundi, 22. juin 2009 17:17
> 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: 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.
> 

Yeap. It will definitively not be obvious to manage. Thanks anyway for raising up the issue. 
Any idea is welcome....
> --
>                                           Gilles

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

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Johan Visser wrote:
>> VMware runs, but gives heavy CPU load ( about 38 % ) instead of 6-8 % on
>> a real system.
> 
> That's expected if your CPU actually lacks hardware virtualization.

An idle guest used to consume almost nothing on a vmware host. Only
MS-DOS needed a special TSR to have its idle mode not consume 100%. On
the other hand, the last time I used vmware was 5 years ago...

-- 
                                          Gilles

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

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Johan Visser wrote:
>>> VMware runs, but gives heavy CPU load ( about 38 % ) instead of 6-8 % on
>>> a real system.
>> That's expected if your CPU actually lacks hardware virtualization.
> 
> An idle guest used to consume almost nothing on a vmware host. Only
> MS-DOS needed a special TSR to have its idle mode not consume 100%. On
> the other hand, the last time I used vmware was 5 years ago...

I meant the scale is expected: If basically the same system runs with
some non-zero load on real hw, the load that this machine inside a
code-translating hypervisor like vmware causes to its host will be
noticeably larger. But even the idle load can be noteworthy if I/O
emulation causes a lot of host activities, even with HVM.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

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

[Johan Visser]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

Jan Kiszka schreef:
> Gilles Chanteperdrix wrote:
>   
>> Jan Kiszka wrote:
>>     
>>> Johan Visser wrote:
>>>       
>>>> VMware runs, but gives heavy CPU load ( about 38 % ) instead of 6-8 % on
>>>> a real system.
>>>>         
>>> That's expected if your CPU actually lacks hardware virtualization.
>>>       
>> An idle guest used to consume almost nothing on a vmware host. Only
>> MS-DOS needed a special TSR to have its idle mode not consume 100%. On
>> the other hand, the last time I used vmware was 5 years ago...
>>     
>
> I meant the scale is expected: If basically the same system runs with
> some non-zero load on real hw, the load that this machine inside a
> code-translating hypervisor like vmware causes to its host will be
> noticeably larger. But even the idle load can be noteworthy if I/O
> emulation causes a lot of host activities, even with HVM.
>
> Jan
>
>   
Tested QEMU as well, boots and runs completely.
it seems to be more jumpy in CPU load and has about 10% more load then 
VMware , after a short time ( minutes ) our application crashes because 
of a userspace watchdog we have implemented. this detects a lack of 
taskswitches in userspace.
( i use a dualcore 2x2.0Ghz centrino CPU. A real celeron @ 400MHz gives 
me12% CPU load in real-time :)
Also the idle task gives max CPU load at first. but after some 
user-interface actions (mouse clicks ) this reduces to 0%.
I will have to investigate more, but have a lack of time now.
cheers




----------------------------------------------------
Stork Plastics Machinery B.V. Alfred Marshallstraat 2, 7559 SE Hengelo, the Netherlands.
Supplies and executions to the conditions and stipulations filed with the Chamber of Commerce (Trade register Enschede nr. 06041991) except as otherwise provided in writing.
DISCLAIMER:
The information contained in this communication is confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or taking any action in reliance of the contents of this information is strictly prohibited and may be unlawful. Stork Plastics Machinery is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. 

[-- Attachment #2: Type: text/html, Size: 3188 bytes --]