xen-devel
RE: [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>
|
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, (continued)
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d,
Tian, Kevin <=
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- Re: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Keir Fraser
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Tian, Kevin
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Kay, Allen M
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Guy Zana
- RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d, Kay, Allen M
|
|
|