This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/D

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)
From: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Fri, 10 Aug 2007 07:50:09 -0400
Cc: Alex Novik <alex@xxxxxxxxxxxx>
Delivery-date: Fri, 10 Aug 2007 04:56:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2E208DB.13FD1%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfarSF45lhECFFTQSiE3oBAG7IKmQAbyytWAAAcBIUABr4MgAACO0OdAAAC82A=
Thread-topic: [Xen-devel] [RFC] Pass-through Interdomain Interrupts Sharing (HVM/Dom0)

> -----Original Message-----
> From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] 
> Sent: Friday, August 10, 2007 2:22 PM
> To: Guy Zana; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Alex Novik
> Subject: Re: [Xen-devel] [RFC] Pass-through Interdomain 
> Interrupts Sharing (HVM/Dom0)
> On 10/8/07 11:22, "Guy Zana" <guy@xxxxxxxxxxxx> wrote:
> >> My thought here is a simple priority list with move-to-back of the 
> >> frontmost domain when we deliver him the interrupt but he does not 
> >> deassert the line either in reasonable time or by the time he EOIs 
> >> the interrupt. This is simple generic logic needing no PV guest 
> >> changes.
> > 
> > Even if the HVM handled the interrupt successfully, it doesn't mean 
> > that the pline will be deasserted (if another device assigned to 
> > another domain asserted it while the HVM processed the 
> interrupt).You 
> > can't tell whether the HVM handled the interrupt 
> successfully or not. How this method overcome this?
> 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?
2. How do you avoid HVM spurious interrupts?

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

>  -- Keir

Xen-devel mailing list