[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日 21:37 > >On 31/5/07 14:20, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > >> 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. > >This is absolutely fine. The virtual wire status will remain HIGH in this >case, which is correct since the 'runt' LOW pulse on the physical wire >can >be ignored. What we are looking for is to track the physical wire status in >the long run; pulses one way or the other do not matter. > >Remember we are talking about *level-triggered* interrupt lines, not >edge-triggered. This polarity-change trick would not be used, and would >not >be necessary, for edge-triggered interrupts. We would EOI the physical >APIC >early, before running the ISR, just as usual for edge-triggered interrupts. > >Because we are talking about level-triggered interrupts, if the line >continues to be HIGH after the ISR runs then of course we'll just deliver >another interrupt straight to the relevant VCPU. That's how >level-triggered >interrupts work. :-) > > -- Keir Ha, you're exactly right. I forgot the virtual wire status which will anyway result a new virtual interrupt if no new hardware interrupt occurs as a de-assert signal. 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: - 1st interrupt is injected and polarity is inverted - HVM finishes handle and write EOI to vIOAPIC - 1st is deasserted - 2nd instance happens - that EOI is converted into an invocation to end() method - either EOI or unmask RTE is issued to physical IOAPIC - No physical interrupt triggered due to inversed polarity - a new virtual interrupt is injected at next resume to HVM - HVM finishes handle and write EOI to vIOAPIC - 2nd instance is deasserted - EOI to vIOAPIC gears to end() again Then it's Xen to decide whether to allow one more end(), does it? I think this part may need some change for this 'change polarity' Approach, like check on pirq_mask. :-) BTW, how about the alternative to take guest EOI to vIOAPIC as the deassertion hint for assigned device? Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |