Re: [Xen-devel] Real-time support

["Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>]

>>> On Fri, May 11, 2007 at  3:43 AM, in message
<c3c918090705110043l157d31b7wf94a2c6c63386e0a@xxxxxxxxxxxxxx>, "Geoffrey
Lefebvre" <geoffrey@xxxxxxxxx> wrote: 
>>  The pin/unpin operations are certainly by far the longest running
>> operations in Xen, and it's been on the to- do list to make them
>> preemptable for a long time. This should be very simple as we can exit
>> the hypervisor leaving the EIP on the hypercall, and next time the guest
>> calls in we'll pick up where we left off.
> 
> Hi,
> 
> I have thought about real- time support in the past and depending on
> the type of real- time guest you want to run, I believe the problem
> might be more complicated than it first seems but could be wrong. Feel
> free to enlighten me if  my comments below don't make sense :)
> 
> I think if all you want to do is preempt one guest to be able to run a
> different guest then the solution as stated above will work.  Things
> get more complicated if you want to be able to deliver an event to a
> guest while that same guest is trapped in the hypervisor.  You
> potentially want this feature to avoid a scenario such as a low
> priority thread that invoked a long hypercall delaying a high priority
> thread waiting for an event (such as a timer). The problem is that
> once you allow this upcall into the guest, there is no guarantee that
> the next hypercall will be the re- execution of the hypercall you
> preempted.
> 
> If the real- time guest you are running is quite simple (a la mini- os)
> then you can avoid this kind of scenario but the problem gets harder
> to avoid (i think) if you are running something like Linux + preempt
> RT as a guest.

We are interested in a predictable system that has (a) bounded dispatch latency 
and (b) does not suffer from priority inversion problems. With a dead-line 
scheduling policy and admission control we can address the dispatch latency 
issues provided we can guarantee that the non-preemtable execution in the 
hypervisor is bounded and is "reasonably" small. 
One way to deal with the problem you mention here is to have the guest OS have 
the smarts to (a) check for preemption conditions that may arise because a 
higher priority thread in the guest is runnable and (b) re-issue the hypercall 
that was only partially completed.

Regards,

K. Y 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel