[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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Guy Zana <guy@xxxxxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Thu, 31 May 2007 16:40:04 +0100
  • Delivery-date: Thu, 31 May 2007 08:38:28 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acei7YJ0pr6pL1ntT2Wzdmq3YT+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQAADOZgAABXPZsAAAfH8AAA3Fxv
  • Thread-topic: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

On 31/5/07 16:30, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> OK, my rough thought is as below:
> 
> The reason to change polarity, IMO, is to capture the de-assert
> edge in the physical wire and then reflect de-assertion into the virtual
> wire. Then allow the statistics on gsi_assert_count to be updated
> correctly, when shared with virtual devices in Qemu.
> 
> My proposal is to take virtual EOI as the de-assertion hint, without
> any change on physical RTE property like polarity. For example, the
> flow could be following by keeping a saying hw_assert_status array for
> all virtual GSIs: (take vioapic for example)

Ah, okay, so no polarity switching at all. Basically use VIOAPIC EOI as a
hint to tentatively drop the virtual wire to LOW, and only then ->end the
physical interrupt. I guess this is pretty much what you already implement
in your VT-d patches?

It'd be interesting to know how these two approaches compare
performance-wise. I suppose yours should win, really, due to fewer physical
interrupts.

If this is how your current VT-d patches handle interrupts then I don't see
why ioapic_ack=new is not working for you. That's a bit weird. I guess I
could read the patches some more. ;-)

 -- Keir


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


 


Rackspace

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