[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |