> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Henning Sprang
> Sent: 18 April 2007 17:06
> To: deepak verghese
> Cc: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] Xen to simulate an RTOS
>
> On 4/17/07, deepak verghese <lildeepak@xxxxxxxxxxx> wrote:
> > Is Xen capable of all this? Is Xen capable of
> > simulating a Real Time OS ?
If by that you mean "Can I host a RTOS on top of Xen", the answer is
that if the RTOS will run on a relatively standard PC, then yes, as a
general answer, but with many caveats. Some of those, I'll discuss
below.
>
> What do mean with "simulating a real time os"?
> Xen is only a hypervisor, and "normally", people run an OS inside it -
> you can look at the "mini-os" in the xen sources to see a minimal OS,
> but without any os as guest, you have no devices, no IO, nothing.
>
> xen has mutliple schedulers, and playing with their options can have
> many effects in terms of "real-time-ness".
One problem in particular is that Xen is not really built for good
real-time performance, e.g. hypercalls may very well block the entire
system for much longer than any real-time programmer would think is OK.
All of course depends on where in the range of "real-time-ness" you
need. I've worked on systems where interrupts come in every few
milliseconds, and the system will fail if the interrupt hasn't been
dealt with in a few hundred microseconds (on a 25MHz processor to make
the challenge "real").
Just to make some comparisons: The default scheduler (credit scheduler)
works on a 30 ms quota, which means that a guest that isn't stalling
will run for 30 ms before it's "out of quota" and some other guest will
be allowed to run. And if two guests are "fighting" to run at the same
processor, one of them will be held waiting while the other runs for
it's quota (or until it falls into a halt position).
Proper real-time OS's will not time-share, they run the highest
process/task until it gets blocked due to some normal blocking condition
(e.g. it waits for something in the system). Some RTOS allows
low-priority tasks to time-share with high-priority tasks being
non-time-shared.
But if real-time is of the order where a few millieseconds is good
enough, and you won't crash the system if some interrupt isn't taken for
several milliseconds, then chances are that Xen would be able to run it.
Pinning the RTOS to a CPU will help a little bit, but it's still going
to rely on the hypervisor and possibly Dom0 for some things, which will
have an effect on the worst case latencies. Latency is much more of a
problem than overall performance in a RTOS, because it's the high
latencies that "kill fast responses", which is often necessary in the
RTOS.
>
> But, if you run an OS inside Xen, you have to configure Xen and the
> guest OS, and maybe the host OS, which hists the drivers, correctly to
> get real time features.
> This can probably be done, but it seems to be more complex than just
> running a Linux modfied/configured for realtime use.
And to fulfill proper real-time behaviour, in the microsecond range,
you'd have to make serious changes to a large chunk of the code that is
in the Xen hypervisor at the moment, starting by making the xen-kernel
more able to take interrupts and schedule a domain wihtout delays -
something that wasn't part of the original design of Xen.
The scheduler will also have to modified to make strict priorities work.
It's most likely easier to start with a RTOS and add a virtualization
module in this case (but beware that the latency of a
VM{LAUNCH,RESUME,RUN}/#VMEXIT pair will be in the range of thousands of
clock-cycles.
--
Mats
>
> Henning
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home