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

Re: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing(HVM/Dom0)


  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Guy Zana <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 10 Aug 2007 09:52:47 +0100
  • Cc: Alex Novik <alex@xxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Aug 2007 01:53:23 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfarSF45lhECFFTQSiE3oBAG7IKmQAbyytWAAAcBIUAADDsMAAA8Q6JAAAVuSAAAUjAmQAAbvFwAADVwU0=
  • Thread-topic: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing(HVM/Dom0)

On 10/8/07 09:41, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> Okay, yes, the driver-unloaded case at least needs to be handled. But it
>> seems to me that the timeout here could be in the hundreds of
>> milliseconds,
>> minimum. It should be an extremely occasional event that the timeout is
>> needed.
> 
> I can agree with 'occasional' but not 'extremely occasional'. :-) HVM, if
> in head of the list, may be in block state waiting Qemu to respond, while
> at same time Qemu may wait for driver (like disk r/w) and driver may
> wait for interrupt. In such condition, 1st injection into HVM will cause
> timeout anyway and only next injection can get handled after dom0 gets
> its interrupt. Just think that such inter-domain-dependency may make
> the case worse...

Oh, I see. That's another separate case to deal with. We'd attempt delivery
to HVM, time out to dom0, then we would see interrupt is still asserted
and... I guess we'd re-set the timeout on the HVM guest a few times, perhaps
with some backoff. This case is a bit of a pain. :-(

 -- Keir


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


 


Rackspace

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