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

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


  • To: Guy Zana <guy@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Fri, 10 Aug 2007 14:18:14 +0100
  • Cc: Alex Novik <alex@xxxxxxxxxxxx>
  • Delivery-date: Fri, 10 Aug 2007 06:18:50 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfarSF45lhECFFTQSiE3oBAG7IKmQAbyytWAAAcBIUABr4MgAACO0OdAAAC82AABA4yXQ==
  • Thread-topic: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)

On 10/8/07 12:50, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:

>> It would cycle through the priority list, moving frontmost to
>> back at each stage, until the line is deasserted.
> 
> 1. When will you deassert the HVM vline?

I would turn vline assertions into pulses: the line would be asserted only
instantaneously, to get latched by the VPIC/VIOAPIC. Actually I think this
question is quite separate from whatever method we use for interrupt
sharing: when would you deassert the vline when the interrupt is *not*
shared? Whatever method we choose should be extendable to the shared case,
and applied to whichever HVM guest we are currently choosing to deliver the
interrupt to. So, whether the interrupt is shared or not, I see no value in
modelling the state of the level-triggered vline.

> 2. How do you avoid HVM spurious interrupts?

I avoid most of them by the fact that a HVM guest that is not handling
interrupts will get pushed down the priority list. Of course this won't get
rid of all spurious interrupts, but I'd expect it to get rid of enough
(e.g., at least 50% even in some worst cases I can think of). So the
question is: how sensitive is Windows to spurious interrupts? I know that
Linux needs something like 99% of interrupts to be spurious for it to
generate a warning. If Windows is similar then my approach would work just
fine.

 -- Keir

> Will you raise the line again?
> It is still getting complicated, and doesn't handle all cases.
> 
>> 
>>> Btw, with the method we proposed you could add PV domains to the
>>> interdomain ISR chain, but it may not contain more than one HVM.
>> 
>> Well, that kind of sucks doesn't it. And yet your method is
>> significantly more complicated than my approach, at least as
>> described in your email.
>> Simple and more general wins the day, unless your approach
>> handles more cases or has better performance?
>> 
> 
> I'm really here to find the best method.
> 
> In your method, you just don't avoid HVM spurious interrupts, I think this is
> a _must_.
> The priority list is a good addition, for PV guests. If you want to avoid
> spurious interrupts in the HVM, the HVM must be the last in the list, which is
> what we did, but started simple (with dom0 and a single hvm).
> 
> If you'll tell me that HVM spurious interrupts is not that important I'll
> agree to go with your method.


_______________________________________________
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®.