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] [VTD][patch 0/5] HVM device assignment using vt-d

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d
From: "Guy Zana" <guy@xxxxxxxxxxxx>
Date: Thu, 31 May 2007 12:07:55 -0400
Delivery-date: Thu, 31 May 2007 09:08:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B1EB9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] 
> Sent: Thursday, May 31, 2007 7:04 PM
> To: Tian, Kevin; Keir Fraser; Guy Zana; Kay, Allen M; 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device 
> assignment using vt-d
> >From: Tian, Kevin
> >Sent: 2007年5月31日 23:59
> >
> >>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx]
> >>Sent: 2007年5月31日 23:52
> >>
> >>On 31/5/07 16:40, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:
> >>
> >>> It'd be interesting to know how these two approaches compare 
> >>> performance-wise. I suppose yours should win, really, due to fewer
> >>physical
> >>> interrupts.
> >>
> >>One thing is that the polarity-switching approach is a 
> slightly better 
> >>fit with the HVM interrupt logic. Currently interrupt sources and 
> >>VIOAPIC are not tightly bound together; they only interact by one 
> >>waggling the virtual intx wires and the other sampling that wire 
> >>periodically (or
> >synchronously
> >>on +ve edges). Your approach requires a 'back channel' from the 
> >>VIOAPIC code back to physical interrupt code to call ->end(). It's 
> >>kind of ugly. On the other hand I suspect the 
> polarity-switching code 
> >>adds more stuff to the phsyical interrupt subsystem, and 
> your approach 
> >>can certainly be supported, probably by adding a bit more 
> state (maybe 
> >>just a single bit) per virtual intx wire. Really we need to look at 
> >>and measure each
> >implementation...
> >>
> >> -- Keir
> >
> >Agree to support both with a common infrastructure. But I doubt that 
> >polarity-switching code should also use such ->end call in 
> virtual EOI 
> >path, since you anyway need an unmask or EOI signal to 
> physical ioapic. 
> >Or else, how to trigger the 2nd interrupt at falling-edge?
> >
> >Thanks,
> >Kevin
> Oh, forgive my ignorance. That can be done in ->ack() by 
> changing polarity and then EOI as what you said before. :-)

We did it by replacing the end() callback of the hw_interrupt_type, the new 
handler performs a change_vector_polarity and then calls the original ->end() 
of the level-triggered hw_interrupt_type, all the rest of the callbacks stays 
the same.

I hope to get the patch ready today, but it will be for c/s 15011.


> Thanks,
> Kevin

Xen-devel mailing list