Xen for real-time/embedded/automotive

Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2521 bytes --]

Hello everyone,

So, looking at the last Xen Developer Summit, other co-located and
previous conferences, as well as here on the list, there appears to be a
booming interest in running Xen on embedded systems of various kind.

This mail to say that:
 * we're ready to take up the challenge! :-)
 * in doing that, we really are interested in everyone's collaboration
   or, at very least, feedback.

So, if you work in embedded/automotive/aerospace/..., what are you
requirements? How can we improve Xen (on ARM) for your use case?

Personally, I'm mostly interested on the scheduling, latency and, in
general, real-time angle. So whether it is on and Android phone/tablet,
an in-car infotinement system, an audio workstation or a rocket that you
want to run Xen, tell me/us what you need in terms of increased
determinism and decreased latencies!

For instance, I think it would be nice to start with some measurements:
http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
That would basically mean running some latency oriented benchmarks both
in Dom0 and in a guest(s), and compare the result with bare metal.
It would be similar to what Open Source Automation Development Lab
(OSADL) people do on "latency QA farm". Actually, how could would it be
to be able to get in touch with them and have Xen run in there? (They
already do something virt-related, but it's very limited).

https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html

Here they are some (more) links:

 - Presentations (from Lovene and Artem) of Xen on some typical embedded
   systems (Android tablet and in-car infotinement)
  * http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
    http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
  * http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
    http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be

 - The Real-Time Xen project Sisu is working on:
  * https://sites.google.com/site/realtimexen/

Looking forward to hearing from you!

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1.1: Type: text/plain, Size: 4412 bytes --]

Hi Dario,

>From my limited development here I would say the following:

1.- The embedded systems I work on have just a flat memory space, no MMU 
or anything like that, so the Mini-OS example is total overkill. I am 
writing a real minimalist PV guest based on that but it's amazing how 
time consuming it's being. I'll be returning this to the project when 
I'm happy with it, as long as you want it.

2.- As far as I am concerned there are 2 metrics that I will be 
analysing once I have my little PV guest running: latency and jitter. As 
far as I am concerned, jitter can be worst that latency. In some systems 
you can compensate for latency, however jitter is much more difficult to 
handle.

3.- At the moment I am assuming that I will access a PCI NIC directly 
from the PV guest. Would be nice to have a deterministic network access 
via Dom0 drivers so I can carry on playing in virtual land. This can be 
generalised to other hardware too.

I'm sure I'll have more comments when I get further.

Regards.


------ Original Message ------
From: "Dario Faggioli" <dario.faggioli@citrix.com>
To: "xen-devel" <xen-devel@lists.xen.org>
Cc: "Roland Heusser" <heusserr@mail.gvsu.edu>; "Joshua Whitehead" 
<whitehej@mail.gvsu.edu>; "Drek Darkover" <wackerei@gmail.com>; "Nate 
Studer" <nate.studer@dornerworks.com>; "Lovene Bhatia" 
<lbhatia@samsung.com>; "Stefano Panella" <stefano.panella@citrix.com>; 
"Sisu Xi" <xisisu@gmail.com>; "Lars Kurth" <lars.kurth@citrix.com>; 
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>; "George Dunlap" 
<George.Dunlap@eu.citrix.com>; "Artem Mygaiev" 
<artem.mygaiev@globallogic.com>; "Simon Martin" <smartin@milliways.cl>; 
mdavis@planetaryresources.com
Sent: 18/11/2013 16:14:10
Subject: Xen for real-time/embedded/automotive

>Hello everyone,
>
>So, looking at the last Xen Developer Summit, other co-located and
>previous conferences, as well as here on the list, there appears to be 
>a
>booming interest in running Xen on embedded systems of various kind.
>
>This mail to say that:
>  * we're ready to take up the challenge!
>  * in doing that, we really are interested in everyone's collaboration
>    or, at very least, feedback.
>
>So, if you work in embedded/automotive/aerospace/..., what are you
>requirements? How can we improve Xen (on ARM) for your use case?
>
>Personally, I'm mostly interested on the scheduling, latency and, in
>general, real-time angle. So whether it is on and Android phone/tablet,
>an in-car infotinement system, an audio workstation or a rocket that 
>you
>want to run Xen, tell me/us what you need in terms of increased
>determinism and decreased latencies!
>
>For instance, I think it would be nice to start with some measurements:
>http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
>That would basically mean running some latency oriented benchmarks both
>in Dom0 and in a guest(s), and compare the result with bare metal.
>It would be similar to what Open Source Automation Development Lab
>(OSADL) people do on "latency QA farm". Actually, how could would it be
>to be able to get in touch with them and have Xen run in there? (They
>already do something virt-related, but it's very limited).
>
>https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
>https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html
>
>Here they are some (more) links:
>
>  - Presentations (from Lovene and Artem) of Xen on some typical 
>embedded
>    systems (Android tablet and in-car infotinement)
>   * 
>http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
>     http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
>   * 
>http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
>     http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
>
>  - The Real-Time Xen project Sisu is working on:
>   * https://sites.google.com/site/realtimexen/
>
>Looking forward to hearing from you!
>
>Thanks and Regards,
>Dario
>
>--
><<This happens because I choose it to happen!>> (Raistlin Majere)
>-----------------------------------------------------------------
>Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>

[-- Attachment #1.1.2: Type: text/html, Size: 7816 bytes --]

[-- Attachment #1.2: Type: image/png, Size: 685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Sisu Xi]

[-- Attachment #1.1: Type: text/plain, Size: 5915 bytes --]

Hi, Dario:

Thanks for starting this topic. I have limited experience with industry, so
I'll provide some input from the academia side. Please correct me if I am
wrong.

1. A real-time CPU scheduler would be great. That's actually the motivation
that we started the RT-Xen project.

The scheduling in a virtualized environments maps to a two-level scheduling
hierarchy in real-time systems. We can use the hierarchical scheduling
theories to provide formal analysis for it. One key assumption of these
theories is a formally defined 'server' to represent the VCPUs. We
implemented and compared different servers in RT-Xen. and published at:

S. Xi, J. Wilson, C. Lu and C.D. Gill, RT-Xen: Towards Real-time Hypervisor
Scheduling in Xen, ACM International Conference on Embedded Software
(EMSOFT'11), October 2011.

J. Lee, S. Xi, S. Chen, L.T.X. Phan, C. Gill, I. Lee, C. Lu and O.
Sokolsky, Realizing Compositional Scheduling through Virtualization, IEEE
Real-Time and Embedded Technology and Applications Symposium (RTAS'12),
April 2012.

They can be found at RT-Xen website:
https://sites.google.com/site/realtimexen/publications

2. An appropriate cache management scheme would be great.
Current CPU architecture have both dedicated cache (usually L1 and L2) and
shared cache (L3).

a) For the dedicated cache, existing credit1 use partitioned scheduling
with load-balancing; while credit2 use modified global scheduling with
migration resistant/compensation. I think if the user runs cache-sensitive
application, partitioned scheduler seems to be a better choice.

b) For the shared cache, the 'noisy neighbor' problem where one guest OS
just runs a cache-busy application and everybody hurts can happen. I have
seen several papers try to solve it, but don't know whether they will be
integrated into Xen or not.
<1> If there are multiple LLC, each shared by a subset of PCPUs, a dynamic
cluster scheme is proposed in this paper:
Min Lee, Karsten Schwan. "Region Scheduling: Efficiently Using the Cache
Architectures via Page-level Affinity." ASPLOS 2012, London, UK, March 3-7,
2012.
<2> If there is one large shared LLC, cache partition by domain seems a
solution. These two papers have explored it:
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5207888&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5207888
http://link.springer.com/article/10.1007%2Fs11704-012-2099-6

3. An deterministic network latency through Domain-0 would be great.
Currently Xen does not support packet prioritization. Users can achieve
similar function by using the Linux Traffic Control Tool in Domain-0, but
priority-inversion can still happen.

We did some work on prioritizing inter-domain communication on Xen, and
published at:
S. Xi, C. Li, C. Lu and C. Gill, Prioritizing Local Inter-Domain
Communication in Xen, ACM/IEEE International Symposium on Quality of
Service (IWQoS'13), June 2013.

We are working on the actual network traffic through NIC now.

Thanks and I'd love to hear any feedback/comments/suggestions on RT-Xen.

Sisu




On Mon, Nov 18, 2013 at 1:14 PM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> Hello everyone,
>
> So, looking at the last Xen Developer Summit, other co-located and
> previous conferences, as well as here on the list, there appears to be a
> booming interest in running Xen on embedded systems of various kind.
>
> This mail to say that:
>  * we're ready to take up the challenge! :-)
>  * in doing that, we really are interested in everyone's collaboration
>    or, at very least, feedback.
>
> So, if you work in embedded/automotive/aerospace/..., what are you
> requirements? How can we improve Xen (on ARM) for your use case?
>
> Personally, I'm mostly interested on the scheduling, latency and, in
> general, real-time angle. So whether it is on and Android phone/tablet,
> an in-car infotinement system, an audio workstation or a rocket that you
> want to run Xen, tell me/us what you need in terms of increased
> determinism and decreased latencies!
>
> For instance, I think it would be nice to start with some measurements:
>
> http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
> That would basically mean running some latency oriented benchmarks both
> in Dom0 and in a guest(s), and compare the result with bare metal.
> It would be similar to what Open Source Automation Development Lab
> (OSADL) people do on "latency QA farm". Actually, how could would it be
> to be able to get in touch with them and have Xen run in there? (They
> already do something virt-related, but it's very limited).
>
> https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
>
> https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html
>
> Here they are some (more) links:
>
>  - Presentations (from Lovene and Artem) of Xen on some typical embedded
>    systems (Android tablet and in-car infotinement)
>   *
> http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
>     http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
>   *
> http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
>     http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
>
>  - The Real-Time Xen project Sisu is working on:
>   * https://sites.google.com/site/realtimexen/
>
> Looking forward to hearing from you!
>
> Thanks and Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>


-- 
Sisu Xi, PhD Candidate

http://www.cse.wustl.edu/~xis/
Department of Computer Science and Engineering
Campus Box 1045
Washington University in St. Louis
One Brookings Drive
St. Louis, MO 63130

[-- Attachment #1.2: Type: text/html, Size: 8369 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Lars Kurth]

Hi Martin, (adding Anil)

On 19/11/2013 01:27, Simon Martin wrote:
> Hi Dario,
> From my limited development here I would say the following:
> 1.- The embedded systems I work on have just a flat memory space, no 
> MMU or anything like that, so the Mini-OS example is total overkill. 
> I am writing a real minimalist PV guest based on that but it's amazing 
> how time consuming it's being. I'll be returning this to the project 
> when I'm happy with it, as long as you want it.
I am wondering whether there is some prior art that the Mirage OS 
(http://xenproject.org/developers/teams/mirage-os.html, 
https://github.com/mirage ) team has done, which you could build 
upon/re-use/look at. Obviously you wouldn't need any of the higher level 
OCaml language stuff. I will let Anil respond, whether there is anything 
that you could use.

Best Regards
Lars

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1: Type: text/plain, Size: 678 bytes --]

>I am wondering whether there is some prior art that the Mirage OS 
>(http://xenproject.org/developers/teams/mirage-os.html, 
>https://github.com/mirage ) team has done, which you could build 
>upon/re-use/look at. Obviously you wouldn't need any of the higher 
>level OCaml language stuff. I will let Anil respond, whether there is 
>anything that you could use.

Thanks Lars,

I started off looking at the mirage-os, but got totally frightened off 
by the OCaml :-). That learning curve was way too much, learn the 
language to then learn the system. I didn't realize there was enough low 
level C to be interesting. I'll go back and have a look at it.

Regards.

[-- Attachment #1.2: Type: text/html, Size: 1971 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 1330 bytes --]

Ø  I didn't realize there was enough low level C to be interesting. I'll go back and have a look at it.
I don’t know whether this is in fact the case. I CC’ed Anil from Mirage. He should know. Wait to hear from him before you do anything
Lars

From: Simon Martin [mailto:smartin@milliways.cl]
Sent: 20 November 2013 14:23
To: lars.kurth@xen.org; Dario Faggioli; xen-devel
Cc: Lars Kurth; Roland Heusser; Artem Mygaiev; Lovene Bhatia; Sisu Xi; Stefano Stabellini; George Dunlap; Joshua Whitehead; Drek Darkover; Stefano Panella; Nate Studer; mdavis@planetaryresources.com; Anil Madhavapeddy
Subject: Re[2]: [Xen-devel] Xen for real-time/embedded/automotive

I am wondering whether there is some prior art that the Mirage OS (http://xenproject.org/developers/teams/mirage-os.html, https://github.com/mirage ) team has done, which you could build upon/re-use/look at. Obviously you wouldn't need any of the higher level OCaml language stuff. I will let Anil respond, whether there is anything that you could use.

Thanks Lars,

I started off looking at the mirage-os, but got totally frightened off by the OCaml :-). That learning curve was way too much, learn the language to then learn the system. I didn't realize there was enough low level C to be interesting. I'll go back and have a look at it.

Regards.

[-- Attachment #1.2: Type: text/html, Size: 8683 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Lars Kurth]

[-- Attachment #1.1: Type: text/plain, Size: 6647 bytes --]

Adding a couple of off xen-devel people to the distribution list of this 
thread on request
Lars

On 20/11/2013 04:50, Sisu Xi wrote:
> Hi, Dario:
>
> Thanks for starting this topic. I have limited experience with 
> industry, so I'll provide some input from the academia side. Please 
> correct me if I am wrong.
>
> 1. A real-time CPU scheduler would be great. That's actually the 
> motivation that we started the RT-Xen project.
>
> The scheduling in a virtualized environments maps to a two-level 
> scheduling hierarchy in real-time systems. We can use the hierarchical 
> scheduling theories to provide formal analysis for it. One key 
> assumption of these theories is a formally defined 'server' to 
> represent the VCPUs. We implemented and compared different servers in 
> RT-Xen. and published at:
>
> S. Xi, J. Wilson, C. Lu and C.D. Gill, RT-Xen: Towards Real-time 
> Hypervisor Scheduling in Xen, ACM International Conference on Embedded 
> Software (EMSOFT'11), October 2011.
>
> J. Lee, S. Xi, S. Chen, L.T.X. Phan, C. Gill, I. Lee, C. Lu and O. 
> Sokolsky, Realizing Compositional Scheduling through Virtualization, 
> IEEE Real-Time and Embedded Technology and Applications Symposium 
> (RTAS'12), April 2012.
>
> They can be found at RT-Xen website: 
> https://sites.google.com/site/realtimexen/publications
>
> 2. An appropriate cache management scheme would be great.
> Current CPU architecture have both dedicated cache (usually L1 and L2) 
> and shared cache (L3).
>
> a) For the dedicated cache, existing credit1 use partitioned 
> scheduling with load-balancing; while credit2 use modified global 
> scheduling with migration resistant/compensation. I think if the user 
> runs cache-sensitive application, partitioned scheduler seems to be a 
> better choice.
>
> b) For the shared cache, the 'noisy neighbor' problem where one guest 
> OS just runs a cache-busy application and everybody hurts can happen. 
> I have seen several papers try to solve it, but don't know whether 
> they will be integrated into Xen or not.
> <1> If there are multiple LLC, each shared by a subset of PCPUs, a 
> dynamic cluster scheme is proposed in this paper:
> Min Lee, Karsten Schwan. "Region Scheduling: Efficiently Using the 
> Cache Architectures via Page-level Affinity." ASPLOS 2012, London, UK, 
> March 3-7, 2012.
> <2> If there is one large shared LLC, cache partition by domain seems 
> a solution. These two papers have explored it:
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5207888&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5207888
> http://link.springer.com/article/10.1007%2Fs11704-012-2099-6
>
> 3. An deterministic network latency through Domain-0 would be great.
> Currently Xen does not support packet prioritization. Users can 
> achieve similar function by using the Linux Traffic Control Tool in 
> Domain-0, but priority-inversion can still happen.
>
> We did some work on prioritizing inter-domain communication on Xen, 
> and published at:
> S. Xi, C. Li, C. Lu and C. Gill, Prioritizing Local Inter-Domain 
> Communication in Xen, ACM/IEEE International Symposium on Quality of 
> Service (IWQoS'13), June 2013.
>
> We are working on the actual network traffic through NIC now.
>
> Thanks and I'd love to hear any feedback/comments/suggestions on RT-Xen.
>
> Sisu
>
>
>
>
> On Mon, Nov 18, 2013 at 1:14 PM, Dario Faggioli 
> <dario.faggioli@citrix.com <mailto:dario.faggioli@citrix.com>> wrote:
>
>     Hello everyone,
>
>     So, looking at the last Xen Developer Summit, other co-located and
>     previous conferences, as well as here on the list, there appears
>     to be a
>     booming interest in running Xen on embedded systems of various kind.
>
>     This mail to say that:
>      * we're ready to take up the challenge! :-)
>      * in doing that, we really are interested in everyone's collaboration
>        or, at very least, feedback.
>
>     So, if you work in embedded/automotive/aerospace/..., what are you
>     requirements? How can we improve Xen (on ARM) for your use case?
>
>     Personally, I'm mostly interested on the scheduling, latency and, in
>     general, real-time angle. So whether it is on and Android
>     phone/tablet,
>     an in-car infotinement system, an audio workstation or a rocket
>     that you
>     want to run Xen, tell me/us what you need in terms of increased
>     determinism and decreased latencies!
>
>     For instance, I think it would be nice to start with some
>     measurements:
>     http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
>     That would basically mean running some latency oriented benchmarks
>     both
>     in Dom0 and in a guest(s), and compare the result with bare metal.
>     It would be similar to what Open Source Automation Development Lab
>     (OSADL) people do on "latency QA farm". Actually, how could would
>     it be
>     to be able to get in touch with them and have Xen run in there? (They
>     already do something virt-related, but it's very limited).
>
>     https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
>     https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html
>
>     Here they are some (more) links:
>
>      - Presentations (from Lovene and Artem) of Xen on some typical
>     embedded
>        systems (Android tablet and in-car infotinement)
>       *
>     http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
>     http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
>       *
>     http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
>     http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
>
>      - The Real-Time Xen project Sisu is working on:
>       * https://sites.google.com/site/realtimexen/
>
>     Looking forward to hearing from you!
>
>     Thanks and Regards,
>     Dario
>
>     --
>     <<This happens because I choose it to happen!>> (Raistlin Majere)
>     -----------------------------------------------------------------
>     Dario Faggioli, Ph.D, http://about.me/dario.faggioli
>     Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
>
>
> -- 
> Sisu Xi, PhD Candidate
>
> http://www.cse.wustl.edu/~xis/ <http://www.cse.wustl.edu/%7Exis/>
> Department of Computer Science and Engineering
> Campus Box 1045
> Washington University in St. Louis
> One Brookings Drive
> St. Louis, MO 63130
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


[-- Attachment #1.2: Type: text/html, Size: 11800 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Anil Madhavapeddy]

On 20 Nov 2013, at 14:23, Simon Martin <smartin@milliways.cl> wrote:

>> I am wondering whether there is some prior art that the Mirage OS (http://xenproject.org/developers/teams/mirage-os.html, https://github.com/mirage ) team has done, which you could build upon/re-use/look at. Obviously you wouldn't need any of the higher level OCaml language stuff. I will let Anil respond, whether there is anything that you could use.
>  
> Thanks Lars,
>  
> I started off looking at the mirage-os, but got totally frightened off by the OCaml :-). That learning curve was way too much, learn the language to then learn the system. I didn't realize there was enough low level C to be interesting. I'll go back and have a look at it.

You don't need to worry about any of the OCaml stuff, but we're based off a very stripped down version of MiniOS. What aspect of MiniOS was too complex for your needs?

We've stripped out all of the device drivers from MiniOS such as Xenstore, Blk/Netfront, Fbfront, and just use it as a boot substrate (since MirageOS implements all the device drivers in OCaml).  I am planning to re-merge with the upstream MiniOS soon, since we can just #ifdef out all the drivers.

We've also chatted to the HalVM folk about breaking out the boot libraries we both need into separate repositories, to make code sharing easier.  I'd like to see a "XenBoot" library with support for PV, HVM and x86/ARM support, for example, and several of the MirageOS early adopters also want a KVM and VMWare Fusion backend to make development easier (with Xen being used for production, but is less convenient for laptop-based development at present).

-anil

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1.1: Type: text/plain, Size: 1085 bytes --]


>>>  I am wondering whether there is some prior art that the Mirage OS 
>>>(http://xenproject.org/developers/teams/mirage-os.html, 
>>>https://github.com/mirage ) team has done, which you could build 
>>>upon/re-use/look at. Obviously you wouldn't need any of the higher 
>>>level OCaml language stuff. I will let Anil respond, whether there is 
>>>anything that you could use.
>>
>>  Thanks Lars,
>>
>>  I started off looking at the mirage-os, but got totally frightened 
>>off by the OCaml . That learning curve was way too much, learn the 
>>language to then learn the system. I didn't realize there was enough 
>>low level C to be interesting. I'll go back and have a look at it.
>
>You don't need to worry about any of the OCaml stuff, but we're based 
>off a very stripped down version of MiniOS. What aspect of MiniOS was 
>too complex for your needs?
I've stripped out the devices like you, but also mm as I have a 
fixed/flat memory space. At the moment I only need console, clock, 
events and traps. The OS I am porting provides all the rest.

Regards.

[-- Attachment #1.1.2: Type: text/html, Size: 2241 bytes --]

[-- Attachment #1.2: Type: image/png, Size: 685 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Anil Madhavapeddy]

On 20 Nov 2013, at 17:59, Simon Martin <smartin@milliways.cl> wrote:

>  
>>>>  I am wondering whether there is some prior art that the Mirage OS (http://xenproject.org/developers/teams/mirage-os.html, https://github.com/mirage ) team has done, which you could build upon/re-use/look at. Obviously you wouldn't need any of the higher level OCaml language stuff. I will let Anil respond, whether there is anything that you could use.
>>>   
>>>  Thanks Lars,
>>>   
>>>  I started off looking at the mirage-os, but got totally frightened off by the OCaml <Mail Attachment.png>. That learning curve was way too much, learn the language to then learn the system. I didn't realize there was enough low level C to be interesting. I'll go back and have a look at it.
>>  
>> You don't need to worry about any of the OCaml stuff, but we're based off a very stripped down version of MiniOS. What aspect of MiniOS was too complex for your needs?
> I've stripped out the devices like you, but also mm as I have a fixed/flat memory space. At the moment I only need console, clock, events and traps. The OS I am porting provides all the rest.

That's actually exactly what Mirage needs too -- we don't ever switch address spaces.  I'd be interested in supporting any (Micro?)OS for Xen/ARM that you come up with.   We already have an ARMv7 native code backend for the OCaml compiler which outputs a self-contained object file that will link straight into any such boot loader.

-anil

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1: Type: text/plain, Size: 437 bytes --]


>That's actually exactly what Mirage needs too -- we don't ever switch 
>address spaces. I'd be interested in supporting any (Micro?)OS for 
>Xen/ARM that you come up with. We already have an ARMv7 native code 
>backend for the OCaml compiler which outputs a self-contained object 
>file that will link straight into any such boot loader.
>
>-anil
I'll keep you posted. Hopefully it won't take me too much longer...

Regards

[-- Attachment #1.2: Type: text/html, Size: 1333 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 462 bytes --]

On mer, 2013-11-20 at 15:25 +0000, Lars Kurth wrote:
> Adding a couple of off xen-devel people to the distribution list of
> this thread on request
>
Well, welcome then! :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 8195 bytes --]

On mer, 2013-11-20 at 15:25 +0000, Lars Kurth wrote:
> Adding a couple of off xen-devel people to the distribution list of
> this thread on request
> Lars
> 
And I'm doing the same with Thomas.

Dario

> On 20/11/2013 04:50, Sisu Xi wrote:
> 
> > Hi, Dario: 
> > 
> > 
> > Thanks for starting this topic. I have limited experience with
> > industry, so I'll provide some input from the academia side. Please
> > correct me if I am wrong.
> > 
> > 
> > 1. A real-time CPU scheduler would be great. That's actually the
> > motivation that we started the RT-Xen project.
> > 
> > 
> > The scheduling in a virtualized environments maps to a two-level
> > scheduling hierarchy in real-time systems. We can use the
> > hierarchical scheduling theories to provide formal analysis for it.
> > One key assumption of these theories is a formally defined 'server'
> > to represent the VCPUs. We implemented and compared different
> > servers in RT-Xen. and published at:
> > 
> > 
> > S. Xi, J. Wilson, C. Lu and C.D. Gill, RT-Xen: Towards Real-time
> > Hypervisor Scheduling in Xen, ACM International Conference on
> > Embedded Software (EMSOFT'11), October 2011.
> > 
> > 
> > 
> > J. Lee, S. Xi, S. Chen, L.T.X. Phan, C. Gill, I. Lee, C. Lu and O.
> > Sokolsky, Realizing Compositional Scheduling through Virtualization,
> > IEEE Real-Time and Embedded Technology and Applications Symposium
> > (RTAS'12), April 2012.
> > 
> > 
> > They can be found at RT-Xen
> > website: https://sites.google.com/site/realtimexen/publications
> > 
> > 
> > 2. An appropriate cache management scheme would be great.
> > Current CPU architecture have both dedicated cache (usually L1 and
> > L2) and shared cache (L3).
> > 
> > 
> > a) For the dedicated cache, existing credit1 use partitioned
> > scheduling with load-balancing; while credit2 use modified global
> > scheduling with migration resistant/compensation. I think if the
> > user runs cache-sensitive application, partitioned scheduler seems
> > to be a better choice.
> > 
> > 
> > b) For the shared cache, the 'noisy neighbor' problem where one
> > guest OS just runs a cache-busy application and everybody hurts can
> > happen. I have seen several papers try to solve it, but don't know
> > whether they will be integrated into Xen or not. 
> > <1> If there are multiple LLC, each shared by a subset of PCPUs, a
> > dynamic cluster scheme is proposed in this paper:
> > Min Lee, Karsten Schwan. "Region Scheduling: Efficiently Using the
> > Cache Architectures via Page-level Affinity." ASPLOS 2012, London,
> > UK, March 3-7, 2012. 
> > <2> If there is one large shared LLC, cache partition by domain
> > seems a solution. These two papers have explored it:
> > http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5207888&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5207888
> > 
> > http://link.springer.com/article/10.1007%2Fs11704-012-2099-6
> > 
> > 
> > 
> > 3. An deterministic network latency through Domain-0 would be great.
> > Currently Xen does not support packet prioritization. Users can
> > achieve similar function by using the Linux Traffic Control Tool in
> > Domain-0, but priority-inversion can still happen.
> > 
> > 
> > We did some work on prioritizing inter-domain communication on Xen,
> > and published at:
> > S. Xi, C. Li, C. Lu and C. Gill, Prioritizing Local Inter-Domain
> > Communication in Xen, ACM/IEEE International Symposium on Quality of
> > Service (IWQoS'13), June 2013. 
> > 
> > 
> > We are working on the actual network traffic through NIC now.
> > 
> > 
> > Thanks and I'd love to hear any feedback/comments/suggestions on
> > RT-Xen.
> > 
> > 
> > Sisu
> > 
> > 
> > 
> > 
> > 
> > 
> > On Mon, Nov 18, 2013 at 1:14 PM, Dario Faggioli
> > <dario.faggioli@citrix.com> wrote:
> >         Hello everyone,
> >         
> >         So, looking at the last Xen Developer Summit, other
> >         co-located and
> >         previous conferences, as well as here on the list, there
> >         appears to be a
> >         booming interest in running Xen on embedded systems of
> >         various kind.
> >         
> >         This mail to say that:
> >          * we're ready to take up the challenge! :-)
> >          * in doing that, we really are interested in everyone's
> >         collaboration
> >            or, at very least, feedback.
> >         
> >         So, if you work in embedded/automotive/aerospace/..., what
> >         are you
> >         requirements? How can we improve Xen (on ARM) for your use
> >         case?
> >         
> >         Personally, I'm mostly interested on the scheduling, latency
> >         and, in
> >         general, real-time angle. So whether it is on and Android
> >         phone/tablet,
> >         an in-car infotinement system, an audio workstation or a
> >         rocket that you
> >         want to run Xen, tell me/us what you need in terms of
> >         increased
> >         determinism and decreased latencies!
> >         
> >         For instance, I think it would be nice to start with some
> >         measurements:
> >         http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
> >         That would basically mean running some latency oriented
> >         benchmarks both
> >         in Dom0 and in a guest(s), and compare the result with bare
> >         metal.
> >         It would be similar to what Open Source Automation
> >         Development Lab
> >         (OSADL) people do on "latency QA farm". Actually, how could
> >         would it be
> >         to be able to get in touch with them and have Xen run in
> >         there? (They
> >         already do something virt-related, but it's very limited).
> >         
> >         https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
> >         https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html
> >         
> >         Here they are some (more) links:
> >         
> >          - Presentations (from Lovene and Artem) of Xen on some
> >         typical embedded
> >            systems (Android tablet and in-car infotinement)
> >           *
> >         http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
> >         
> >         http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
> >           *
> >         http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
> >         
> >         http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
> >         
> >          - The Real-Time Xen project Sisu is working on:
> >           * https://sites.google.com/site/realtimexen/
> >         
> >         Looking forward to hearing from you!
> >         
> >         Thanks and Regards,
> >         Dario
> >         
> >         --
> >         <<This happens because I choose it to happen!>> (Raistlin
> >         Majere)
> >         -----------------------------------------------------------------
> >         Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> >         Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge
> >         (UK)
> >         
> > 
> > 
> > 
> > 
> > -- 
> > Sisu Xi, PhD Candidate
> > 
> > http://www.cse.wustl.edu/~xis/
> > Department of Computer Science and Engineering
> > Campus Box 1045
> > Washington University in St. Louis
> > One Brookings Drive
> > St. Louis, MO 63130 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 3123 bytes --]

BTW, there's another thread going on, related to this topic here:

http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg03004.html

(Lars started it by sharing his notes from the "Seeding a Xen +
Android / Embedded ecosystem" BoF session we had at the Xen Developer
Summit in Edinburgh)

On lun, 2013-11-18 at 20:14 +0100, Dario Faggioli wrote:
> Hello everyone,
> 
> So, looking at the last Xen Developer Summit, other co-located and
> previous conferences, as well as here on the list, there appears to be a
> booming interest in running Xen on embedded systems of various kind.
> 
> This mail to say that:
>  * we're ready to take up the challenge! :-)
>  * in doing that, we really are interested in everyone's collaboration
>    or, at very least, feedback.
> 
> So, if you work in embedded/automotive/aerospace/..., what are you
> requirements? How can we improve Xen (on ARM) for your use case?
> 
> Personally, I'm mostly interested on the scheduling, latency and, in
> general, real-time angle. So whether it is on and Android phone/tablet,
> an in-car infotinement system, an audio workstation or a rocket that you
> want to run Xen, tell me/us what you need in terms of increased
> determinism and decreased latencies!
> 
> For instance, I think it would be nice to start with some measurements:
> http://wiki.xenproject.org/wiki/Xen_Development_Projects#Is_Xen_ready_for_the_Real-Time.2FEmbedded_World.3F
> That would basically mean running some latency oriented benchmarks both
> in Dom0 and in a guest(s), and compare the result with bare metal.
> It would be similar to what Open Source Automation Development Lab
> (OSADL) people do on "latency QA farm". Actually, how could would it be
> to be able to get in touch with them and have Xen run in there? (They
> already do something virt-related, but it's very limited).
> 
> https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html
> https://www.osadl.org/Real-time-host-and-kvm-virtualization.qa-farm-rt-host-and-kvm.0.html
> 
> Here they are some (more) links:
> 
>  - Presentations (from Lovene and Artem) of Xen on some typical embedded
>    systems (Android tablet and in-car infotinement)
>   * http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
>     http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
>   * http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
>     http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
> 
>  - The Real-Time Xen project Sisu is working on:
>   * https://sites.google.com/site/realtimexen/
> 
> Looking forward to hearing from you!
> 
> Thanks and Regards,
> Dario
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1122 bytes --]

On lun, 2013-11-18 at 20:14 +0100, Dario Faggioli wrote:
> Here they are some (more) links:
> 
>  - Presentations (from Lovene and Artem) of Xen on some typical embedded
>    systems (Android tablet and in-car infotinement)
>   * http://www.slideshare.net/xen_com_mgr/sruk-xen-presentation2013v7dualandroid
>     http://www.youtube.com/watch?v=Km6gBnIqaWo&feature=youtu.be
>   * http://www.slideshare.net/xen_com_mgr/xen-in-oss-based-in-vehicle-infotainment-systems
>     http://www.youtube.com/watch?v=po1IeElg8tg&feature=youtu.be
> 
>  - The Real-Time Xen project Sisu is working on:
>   * https://sites.google.com/site/realtimexen/
> 
And here's an update on the Real-Time Xen project, coming directly from
our blog!

http://blog.xen.org/index.php/2013/11/27/rt-xen-real-time-virtualization-in-xen/

Thanks Sisu. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2743 bytes --]

On mar, 2013-11-19 at 01:27 +0000, Simon Martin wrote:
> From my limited development here I would say the following:
>  
> 1.- The embedded systems I work on have just a flat memory space, no
> MMU or anything like that, so the Mini-OS example is total overkill.
> I am writing a real minimalist PV guest based on that but it's amazing
> how time consuming it's being. I'll be returning this to the project
> when I'm happy with it, as long as you want it.
>
I totally see what you mean! I'm glad that you find, also thanks to this
thread, some nice similarities with MirageOS, and some chance for
possible collaborations that were even beyond the original purpose of
this very thread... That's why Open Source is so awesome, isn't it?

> 2.- As far as I am concerned there are 2 metrics that I will be
> analysing once I have my little PV guest running: latency and jitter.
> As far as I am concerned, jitter can be worst that latency. In some
> systems you can compensate for latency, however jitter is much more
> difficult to handle.
>
These indeed are very important aspects of a truly real-time enabling
platform. As I said in the e-mail starting this, I'm committed to start
monitoring these, to at least assess where we stand.

I'll keep this thread informed about that, of course.

For now, for the benefits of all the people in this thread, let me use
his mail to direct you to the code of the "minimalistic" PV guest port
that Simon is working on, and that he kindly published here:

 "A Xen Micro Paravirtualized Guest to load a small independent OS"
  https://github.com/FurryFuttock/micro-pv

Thanks a lot Simon for doing and releasing this, I'm _sure_ it'll be
helpful for others, and for the prosecution of this discussion/activity.

BTW, I do realise only know that I probably never asked that... What is
(if you feel like saying it here) your specific usecase / final goal of
this work?

> 3.- At the moment I am assuming that I will access a PCI NIC directly
> from the PV guest. Would be nice to have a deterministic network
> access via Dom0 drivers so I can carry on playing in virtual land.
> This can be generalised to other hardware too.
>
That's another interesting piece of work Sisu was also referring too
(saying that they're doing some research on it, which is always fine).

Like it usually happens, we don't risk to get in short of things to do
that soon, do we? :-P

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1: Type: text/plain, Size: 1107 bytes --]


>BTW, I do realise only know that I probably never asked that... What is
>(if you feel like saying it here) your specific usecase / final goal of
>this work?
>
I am porting an motion control system to Xen. The OS and hardware is 
developed in house. I originally wrote the OS about 20 years ago on a TI 
DSP processor with 32 k words of RAM and it has been evolving since 
then, migrating to different processors (MIPS/ARM) and an ever 
increasing amount of memory (we moved from SRAM to DRAM when we went on 
to the MIPS platform, and the smallest DRAM chips you could get at the 
time were 1 MB).

Looking at the Real-Time Xen project, it is built around millisecond 
resolution. That was fine for motion control about 20 years ago, but 
nowadays everyone is working sub-millisecond. Our existing systems can 
close the control loop every 125 µs doing full interpolation on 8 axes 
with 64 bit resolution on an ARM11 platform. Worst than that, jitter on 
the control loop gives you at best jerky movement and at worst shuts 
down the drives so that must be controlled.

Regards.


[-- Attachment #1.2: Type: text/html, Size: 2365 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 2480 bytes --]

On gio, 2013-11-28 at 11:39 +0000, Simon Martin wrote:
>  
> > BTW, I do realise only know that I probably never asked that... What
> > is 
> > (if you feel like saying it here) your specific usecase / final goal
> > of 
> > this work? 
> >  
> I am porting an motion control system to Xen. The OS and hardware is
> developed in house. I originally wrote the OS about 20 years ago on a
> TI DSP processor with 32 k words of RAM and it has been evolving since
> then, migrating to different processors (MIPS/ARM) and an ever
> increasing amount of memory (we moved from SRAM to DRAM when we went
> on to the MIPS platform, and the smallest DRAM chips you could get at
> the time were 1 MB).
>
That's very cool! You know, at some point, probably when you/we would
have a bit more of this in place, I'll probably ask if you want to write
a post on our blog (http://blog.xen.org/) about it! :-D
 
> Looking at the Real-Time Xen project, it is built around millisecond
> resolution. That was fine for motion control about 20 years ago, but
> nowadays everyone is working sub-millisecond. 
>
Yeah, well, let's investigate what the limit is and try to push harder
on it then. From my previous experience with real-time on Linux, it's
possiblee to go sub-milliseconds, although not without some tricks.
Personally, I think it's both possible and worthwhile to try to figure
out what are the tricks required for us to get as near as possible to
that!

> Our existing systems can close the control loop every 125 µs doing
> full interpolation on 8 axes with 64 bit resolution on an ARM11
> platform. Worst than that, jitter on the control loop gives you at
> best jerky movement and at worst shuts down the drives so that must be
> controlled.
>  
HeHe... It's about Linux, but I just can't resist:

<<Controlling a laser with Linux is crazy, but everyone in this room is
crazy in his own way. So if you want to use Linux to control an
industrial welding laser, I have no problem with your using
PREEMPT_RT.>> Torvalds, Linus (2007)

Of course, substitute 'Linux' with 'Xen', and PREEMPT_RT with either
RT-Xen, or whatever we could come up with in the long run! :-P :-P

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Simon Martin]

[-- Attachment #1.1.1: Type: text/plain, Size: 1405 bytes --]


>That's very cool! You know, at some point, probably when you/we would
>have a bit more of this in place, I'll probably ask if you want to 
>write
>a post on our blog (http://blog.xen.org/) about it!
I'll have to clear it with my manager, but I can't see any problems with 
it. Have to get it running first though.

>>  Looking at the Real-Time Xen project, it is built around millisecond
>>  resolution. That was fine for motion control about 20 years ago, but
>>  nowadays everyone is working sub-millisecond.
>>
>Yeah, well, let's investigate what the limit is and try to push harder
>on it then. From my previous experience with real-time on Linux, it's
>possiblee to go sub-milliseconds, although not without some tricks.
>Personally, I think it's both possible and worthwhile to try to figure
>out what are the tricks required for us to get as near as possible to
>that!
That is exactly the response I was  hoping for.

>
>HeHe... It's about Linux, but I just can't resist:
>
><<Controlling a laser with Linux is crazy, but everyone in this room is
>crazy in his own way. So if you want to use Linux to control an
>industrial welding laser, I have no problem with your using
>PREEMPT_RT.>> Torvalds, Linus (2007)
>
>Of course, substitute 'Linux' with 'Xen', and PREEMPT_RT with either
>RT-Xen, or whatever we could come up with in the long run!
Sounds perfect to me.

[-- Attachment #1.1.2: Type: text/html, Size: 2965 bytes --]

[-- Attachment #1.2: Type: image/png, Size: 652 bytes --]

[-- Attachment #1.3: Type: image/png, Size: 680 bytes --]

[-- Attachment #1.4: Type: image/png, Size: 680 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 726 bytes --]

On gio, 2013-11-28 at 12:39 +0000, Simon Martin wrote:
>  
> > That's very cool! You know, at some point, probably when you/we
> > would 
> > have a bit more of this in place, I'll probably ask if you want to
> > write 
> > a post on our blog (http://blog.xen.org/) about it! :-D
> I'll have to clear it with my manager,
>
Sure.

> Have to get it running first though.
>  
Yeah, definitely! Looking forward to it. :-)

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Jeremiah Foster]

[-- Attachment #1.1: Type: text/plain, Size: 409 bytes --]

Hello,

I'm pinging this thread again with a "scoping paper" that came out of work
done in GENIVI, the Open Source automotive alliance. Please find it
attached.

The paper describes what virtualization companies defined as an automotive
scope for GENIVI's OS. It is a couple years old but still should give a
decent idea of what direction and needs automotive virtualization has. I

Regards,

Jeremiah



>
>

[-- Attachment #1.2: Type: text/html, Size: 836 bytes --]

[-- Attachment #2: System Virtualization Scoping (Green Hills Software) - GENIVI - GENIVI Wiki.pdf --]
[-- Type: application/pdf, Size: 148113 bytes --]

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 981 bytes --]

On gio, 2013-12-12 at 09:05 +0100, Jeremiah Foster wrote:
> Hello,
> 
Hi Jeremiah,

> I'm pinging this thread again with a "scoping paper" that came out of
> work done in GENIVI, the Open Source automotive alliance. Please find
> it attached. 
> 
Wow... I gave it a glance right now, and it's really really interesting.

More thorough reading happening soon. I'll also link this from our Wiki,
in the 'Xen on Embedded' category.

> The paper describes what virtualization companies defined as an
> automotive scope for GENIVI's OS. It is a couple years old but still
> should give a decent idea of what direction and needs automotive
> virtualization has.
>
Indeed it does... Thanks again,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Lars Kurth]

Jeremiah,
thanks for sharing

> More thorough reading happening soon. I'll also link this from our Wiki, in the 'Xen on Embedded' category
It seems the document is restricted to members of Genivi only

Lars
________________________________________
From: Dario Faggioli [dario.faggioli@citrix.com]
Sent: 12 December 2013 08:12
To: Jeremiah Foster
Cc: Lars Kurth; Sisu Xi; Lars Kurth; Roland Heusser; Artem Mygaiev; Lovene Bhatia; Stefano Stabellini; George Dunlap; Joshua Whitehead; xen-devel; Drek Darkover; Stefano Panella; Simon Martin; Nate Studer; mdavis@planetaryresources.com; Andersson, Gunnar ()
Subject: Re: [Xen-devel] Xen for real-time/embedded/automotive

On gio, 2013-12-12 at 09:05 +0100, Jeremiah Foster wrote:
> Hello,
>
Hi Jeremiah,

> I'm pinging this thread again with a "scoping paper" that came out of
> work done in GENIVI, the Open Source automotive alliance. Please find
> it attached.
>
Wow... I gave it a glance right now, and it's really really interesting.

More thorough reading happening soon. I'll also link this from our Wiki,
in the 'Xen on Embedded' category.

> The paper describes what virtualization companies defined as an
> automotive scope for GENIVI's OS. It is a couple years old but still
> should give a decent idea of what direction and needs automotive
> virtualization has.
>
Indeed it does... Thanks again,
Dario

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Re: Xen for real-time/embedded/automotive

[Jeremiah Foster]

[-- Attachment #1.1: Type: text/plain, Size: 3081 bytes --]

On Thu, Dec 12, 2013 at 10:35 AM, Lars Kurth <lars.kurth@citrix.com> wrote:

> Jeremiah,
> thanks for sharing
>
> > More thorough reading happening soon. I'll also link this from our Wiki,
> in the 'Xen on Embedded' category
> It seems the document is restricted to members of Genivi only
>

Yes, that is the case. However, we've done some due diligence and cleared
the sharing with the Xen folks as a courtesy and in an effort at
transparency. The goal is to help the ecosystem prosper and GENIVI is
prepared to contribute what is considered often as "Intellectual Property"
if it advances the automotive Open Source Community.

Due to the fact that it was just a dump from the wiki to PDF, some of the
member-only artifacts remain. If that has a negative impact on how you guys
use it, let me know and I'll see if I can scrub it.

Cheers,

Jeremiah


>
> Lars
> ________________________________________
> From: Dario Faggioli [dario.faggioli@citrix.com]
> Sent: 12 December 2013 08:12
> To: Jeremiah Foster
> Cc: Lars Kurth; Sisu Xi; Lars Kurth; Roland Heusser; Artem Mygaiev; Lovene
> Bhatia; Stefano Stabellini; George Dunlap; Joshua Whitehead; xen-devel;
> Drek Darkover; Stefano Panella; Simon Martin; Nate Studer;
> mdavis@planetaryresources.com; Andersson, Gunnar ()
> Subject: Re: [Xen-devel] Xen for real-time/embedded/automotive
>
> On gio, 2013-12-12 at 09:05 +0100, Jeremiah Foster wrote:
> > Hello,
> >
> Hi Jeremiah,
>
> > I'm pinging this thread again with a "scoping paper" that came out of
> > work done in GENIVI, the Open Source automotive alliance. Please find
> > it attached.
> >
> Wow... I gave it a glance right now, and it's really really interesting.
>
> More thorough reading happening soon. I'll also link this from our Wiki,
> in the 'Xen on Embedded' category.
>
> > The paper describes what virtualization companies defined as an
> > automotive scope for GENIVI's OS. It is a couple years old but still
> > should give a decent idea of what direction and needs automotive
> > virtualization has.
> >
> Indeed it does... Thanks again,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>


-- 
=============================================
Jeremiah C. Foster   エレミア フォスター
Open Source Technologist and
GENIVI Community Manager
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)730 93 0506
E-Mail: jeremiah.foster@pelagicore.com
=============================================

=== NOTE ===
The information contained in this E-mail message is
intended only for use of the individual or entity
named above. If the reader of this message  is not
the intended recipient, or the employee or agent
responsible to deliver it to the intended recipient,
you are hereby notified that any dissemination,
distribution or copying of this communication is
strictly prohibited.
=============

[-- Attachment #1.2: Type: text/html, Size: 4262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Xen for real-time/embedded/automotive

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1833 bytes --]

On gio, 2013-12-12 at 10:39 +0100, Jeremiah Foster wrote:


> On Thu, Dec 12, 2013 at 10:35 AM, Lars Kurth <lars.kurth@citrix.com>
> wrote:
>         Jeremiah,
>         thanks for sharing
>         
>         > More thorough reading happening soon. I'll also link this
>         from our Wiki, in the 'Xen on Embedded' category
>         
>         It seems the document is restricted to members of Genivi only
> 
> 
> Yes, that is the case. However, we've done some due diligence and
> cleared the sharing with the Xen folks as a courtesy and in an effort
> at transparency. 
>
Wow... That is really great.. Even better than I thought in the first
place. :-)

I think that has been something fair and wise to do before posting it on
xen-devel as, Wiki or not, the mailing list already is a public place
(due to the public archives). :-P

> The goal is to help the ecosystem prosper and GENIVI is prepared to
> contribute what is considered often as "Intellectual Property" if it
> advances the automotive Open Source Community.
> 
Very, very good to know.

> Due to the fact that it was just a dump from the wiki to PDF, some of
> the member-only artifacts remain. If that has a negative impact on how
> you guys use it, let me know and I'll see if I can scrub it.
> 
Well, if it's not a big deal, or a huge amount of work, please do. I
think it would help avoid confusion and misunderstandings, and it would
make it even more clear your purpose and your attitude toward the Open
Source community.

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel