Xen project Mailing List

Dear Faggioli and Lars,

Thanks for putting me into the thread, I am eager to join here.

I've had a great time in Edinburgh, meeting friends that are working on the subject that is closely related with me.

(Xen-arm and rt-scheduling issues)

My thought about real-time things are becoming clear, and here are some.

1. Simply running a real-time OS is definitely not enough for guaranteeing deadline under virtualization.

2. To support hard real-time over Xen, we need the followings:

a. WCET analysis for time-critical Xen services (hypcalls).

Based upon this WCET, RTOS and apps (tasks) can calculate WCET, accordingly.

b. Hierarchical scheduling theory buys you a real-time guarantee, and what we want here is

an interface and algorithm for finding VM (or vcpu) scheduling parameters for rt schedulers (such as EDF or RM).

Of course we need a scheduler implementation (I think ARINC/SEDF provides a basic format).

c. a, and b would provide us real-time guarantee for cpu-bound real-time tasks.

d. Maximum latency guarantee for aperiodic/sporadic tasks (such as I/O tasks) are difficult because

We have to address scheduling model under split drivers. If inter-VM scheduling latency is introduced,

then the latency goes up to tens of milliseconds, which is definitely not what we want. A possible simplification is

prioritize the driver domain, however note that the driver domain should run a real-time OS, instead of Linux.

In addition, we should implement backend drivers (and physical drivers) as real-time tasks.

3. To support soft real-time over Xen, there are several studies out there.

However, most of them do not make code contribution. That is one of key huddles.

4. To concurrently support both real-time and non-real-time guest OSs, the scheduler framework has to be

hierarchically structured.

I am specifically interested in bigLITTLE cpus as a means of supporting soft real-time applications. However, I don't have time schedules or written codes; so I just want to looking up when it begins to get started.

If you have another idea, please tell me.

I am observing the lists, and would be glad if I can help it to make progress.

Best regards,

Seehwan Yoo Ph.D.

On Fri, Nov 22, 2013 at 4:08 PM, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:

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@xxxxxxxxxxxxxx%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)

Re: [Xen-devel] Xen Developer Summit BoF Notes : Seeding a Xen + Android / Embedded ecosystem BoF