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: "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: Thu, 31 May 2007 23:51:27 +0800
Delivery-date: Thu, 31 May 2007 08:49:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C284AAE4.FCB7%keir@xxxxxxxxxxxxx>
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+WeAABwdLMABRnVWAADaM8MAADBqQEAAAbqrAAAuWvEQAADOZgAABXPZsAAAfH8AAA3FxvAAAN5JA=
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:40
>
>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


Oh, I'm not the author of VT-d patches which is the credit of Allen and
Xiaohui. :-) I just had the concrete thought along with the discussion 
with you, and will talk to them for confirmation tomorrow. I guess 
"ioapic_ack=new" should be just some manual bug since one NIC 
assignment shouldn't result shared interrupt case yet.

Thanks,
Kevin

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

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