WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Guy Zana" <guy@xxxxxxxxxxxx>, "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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 1 Jun 2007 00:03:59 +0800
Delivery-date: Thu, 31 May 2007 09:02:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B1EB8@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-index: Acei7YJ0pr6pL1ntT2Wzdmq3YT+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQAADOZgAABXPZsAAAfH8AAA3FxvAABuaw8AAA06YAAAUFYQ
Thread-topic: [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. :-)

Thanks,
Kevin

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

<Prev in Thread] Current Thread [Next in Thread>