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)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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) >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
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
>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Ø 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
>>> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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
>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. > >-anilI''ll keep you posted. Hopefully it won''t take me too much longer... Regards _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Jeremiah, thanks for sharing> More thorough reading happening soon. I''ll also link this from our Wiki, in the ''Xen on Embedded'' categoryIt 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)
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. ============ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel