[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: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] >Sent: 2007年5月31日 23:03 > >On 31/5/07 14:59, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > >> But... still one question, seems that current Xen doesn't allow >> multiple end() methods called for one physical interrupt instance, >> while a new physical interrupt will happen only as result of end() >> (EOI for ioapic_new, and unmask RTE for ioapic_old). See below >> case: > >Yeah, well I haven't looked at how the Neocleus patches actually deal >with >this, but I expect they might steal hvm-bound physical irqs completely, >hook >them off early in do_IRQ() and have bespoke code to deal with them. >Possibly >it could be integrated with existing ->ack and ->end methods, actually. >->end() would be no-op while ->ack() would switch polarity in the IOAPIC >and >then EOI the LAPIC. Then the handler function called by do_IRQ() would >toggle virtual HVM wires. > >Anyhow, integrating with existing Xen IRQ handling subsystem clearly >isn't a >rocket-science problem. :-) > Sure. :-) But I'm still thinking the effect to use virtual EOI as de-assertion signal, which doesn't require to change polarity in the line frequently. We can just add a flag per gsi to indicate whether a physical irq is injected on this line. When intercepting HVM EOI, invoke deassert and also jump to ->end() if flag is on. Does it work basically? Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |