Re: Xen Developer Summit BoF Notes : Seeding a Xen + Android / Embedded ecosystem BoF

[Dario Faggioli <dario.faggioli@citrix.com>]

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

On gio, 2013-11-21 at 13:45 +0000, Lars Kurth wrote:
> Dario,
> I added a few things where there was an open question. Also pointing 
> back to the original mail at 
> http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg03004.html ...
> 
Ok.

> On 21/11/2013 09:52, Dario Faggioli wrote:
> >> == Pieces missing for Embedded (non-Android) ==
> >> # Soft-Real-time support - note that this was in the original Xen ARM
> >> port - see [[Xen_ARM_(PV)]]. But it didn't make it across to the Xen on
> >> ARM support.
> >>
> > Was it? Didn't know that, and I don't see much about it in the archived
> > Wiki page. It's not that important as the project has been archived, but
> > it'd be nice to see what was there, and what and why it didn't survive,
> > I think.
> I may be wrong on this - there was certainly some research (see 
> http://www.computer.org/csdl/trans/tm/preprint/06583914-abs.html, 
> http://www.slideshare.net/xen_com_mgr/real-time-support-for-xen). I 
> added See-Hwan Yoo to this thread who has done the original work. Maybe 
> he can correct me and shed light on what was done.
> 
Well, I know there was ongoing research about real-time in
virtualization, mostly because, at that time (before joining Citrix), I
was among the ones doing it! :-)

> However, it may make sense to have a solution that works on x86 and ARM. 
> Not sure whether this is a pipe dream though.
> 
Sure. According to my experience, we can go pretty far in enabling
real-time performances, without architecture specific trick. I mean,
there are for sure low-level stuff, but the most of it needs to happen
in common code.

As, for example, you can see here (still from a research point of view):
http://bugs.xenproject.org/xen/mid/%3CCAPqOm-pz8jW3Dd2k9RWu3FFZi7rJTJpAbb6mACRWUXuY7eiFKQ@mail.gmail.com%3E

We need real-time capable schedulers in Xen, a real-time aware driver
model (which means Dom0 and the backends), etc, and that's all doable in
such a way that all supported archs will benefit from it.

> > I thought about something similar (having a dedicated list) when
> > starting the thread about real-time and embedded too. Personally, I like
> > everything happening in xen-devel, but, if the main purpose is
> > bootstrapping, and if that, for instance, would buy us people that
> > wouldn't subscribe to xen-devel anyway (because of the amount of
> > traffic), well, I'd seriously consider having the list.
> I am not sure I would want a dedicated new list which lasts for a year 
> only. This is what we used to have: there is a long history of one-off 
> lists such as ova-devel, xci-devel, xen-ia64-devel, ... to name just a 
> few. But maybe a list for researchy, longer term stuff may work that we 
> can direct people to that are scared by the amount of xen-devel traffic. 
> We can use the list whenever bigger and new ideas come along that still 
> need to be formed and take some time to form. We still have xen-research 
> (archived), that we could resurrect, but maybe the name isn't quite right.
> 
Right. Well, my point here is: at this stage, we need to be able to
reach out to as many as possible of the people interested and active in
this area, and have all of us share thoughts and collaborate. Whatever
(well, almost :-P) it is required to make this happen, I'm all for 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