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

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

  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Guy Zana" <guy@xxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Thu, 31 May 2007 23:59:04 +0800
  • Delivery-date: Thu, 31 May 2007 08:57:38 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

>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
>> interrupts.
>One thing is that the polarity-switching approach is a slightly better fit
>with the HVM interrupt logic. Currently interrupt sources and VIOAPIC
>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
>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
>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?


Xen-devel mailing list



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