[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



>From: Tian, Kevin
>Sent: 2007年5月31日 23:59
>
>>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
>>physical
>>> interrupts.
>>
>>One thing is that the polarity-switching approach is a slightly better fit
>>with the HVM interrupt logic. Currently interrupt sources and VIOAPIC
>>are
>>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
>>VIOAPIC code
>>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
>>supported,
>>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?
>
>Thanks,
>Kevin

Oh, forgive my ignorance. That can be done in ->ack() by 
changing polarity and then EOI as what you said before. :-)

Thanks,
Kevin

_______________________________________________
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®.