[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Real-time support

  • To: "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>
  • From: "Geoffrey Lefebvre" <geoffrey@xxxxxxxxx>
  • Date: Fri, 11 May 2007 10:53:20 -0700
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 11 May 2007 10:51:49 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZzpAVaj/iyZU2SGAcEJ95yXh2+/x7VTZO+SBb5pC9zS0/G/+gC4g0tsCBT4pCv66I1StzXdrlHMYSGdXop8tC3AaDHcsEWzjOaH4UM0UQ6Q+sZf6ZVkFEJf3FQStUVQkRn3oyiAly2Cd78Bn1+KHBoS2bxQWK7bEA+ygLLdbIQw=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


Yes i agree.  Preempting the hypercall and returning an indication of
forward progress to the guest as is currently done with multicall, etc
should work. I misunderstood Ian Pratt's earlier suggestion. I thought
his idea was to preempt the hypercall and keep preemption state inside
the hypervisor. My mistake :).



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.