[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: Fri, 1 Jun 2007 10:57:10 +0800
  • Delivery-date: Thu, 31 May 2007 19:55:27 -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

Two more minor comments:
        - For polarity-switching approach, now I'm inclined to applaud if it 
can help handle 'boot interrupt' issue as fuse of ioapic_ack_new. That 
brings more value than simple assist on virtual wire de-assertion.

        - For ->end() in VIOAPIC code, I think that's not ugly since similar 
to pirq_guest_eoi used in do_physdev_op which also comes from end() 
method of pirq_type in dom0.


>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

Xen-devel mailing list



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