RE: [Xen-devel] [VTD][patch 0/5] HVM device assignment using vt-d

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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