[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
> -----Original Message----- > From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx] > Sent: Thursday, May 31, 2007 4:21 PM > To: Guy Zana; Keir Fraser; Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: RE: [Xen-devel] [VTD][patch 0/5] HVM device > assignment using vt-d > > It does be a 'cunning' approach, which however seems to only > apply to interrupt instance with both rising edge and falling > edge like: > > _____________ ______________ > ___| 1 |____| 2 |____________ > > Just be curious whether following cases can be addressed, > when one edge is missing. > > [Case one] > Is it possible for one device to keep line 'high' for > two successive instances, like: > _________________________________________ > ___| 1 | 2 ... > > When driver requests device to clear interrupt assertion > at end of handling 1st, it's possible that device keeps > assertion if interrupt condition still matches in 2nd. In > that case, no interrupt will happen any more when EOI is > written to IOAPIC due to polarity inversion. Since the HVM's assertion state is kept "asserted" until the _external_ line 'fall', the HVM itself will keep getting interrupts on VMENTRYs, until the _external_ line is deasserted (by the external device). This reflects the real behavior of the external line. If this behavior of interrupt is treated differently, you'll get redundant interrupts :) > > [Case two] > Similar to case one, two PCI devices share one interrupt pin: > PCI-A > _______ > ___| 1 |_______________________ > PCI-B > _____________________________ > ______________| 2 > PIN > _______ _____________________________ > ___| |___| ^EOI > > If: > - Guest finishes invocation to all irq actions hooked > to that pin before PCI-B does assertion. > - EOI to IOAPIC happens after PCI-B does assertion > > The net effect is that line status keeps 'high' after EOI and > polarity inverse makes no interrupt again. If both devices works in pass-through, it should work, since it is the ORed line that is reflected. We can add functionality for sharing such devices between dom0 and a guest, by changing the way dom0 handles level-triggered interrupts. Thanks, Guy. > > Maybe I didn't get the exact detail of your named 'change polarity' > idea, and if yes, appreciate your elaboration here. :-) > > Thanks, > Kevin > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |