Re: [Qemu-devel] [PATCH v4 00/16] IOMMU: Enable interrupt remapping for Intel IOMMU

[Radim Krčmář]

2016-04-28 13:27+0800, Peter Xu:
> On Wed, Apr 27, 2016 at 04:31:13PM +0200, Radim Krčmář wrote:
> 
> [...]
> 
>> >> > I am still looking into guest part codes. Although the above patch
>> >> > should solve the issue, there are still issues in guest codes when
>> >> > IR is enabled:
>> >> > 
>> >> > - mismatched "vector" in IOAPIC entry and IRTE entry (this is
>> >> >   required in vt-d spec 5.1.5.1, and required to correctly deliver
>> >> >   EOI broadcast I guess). See intel_irq_remapping_prepare_irte():
>> >> 
>> >> "required" is a way of saying that the opposite is undefined.
>> >> No need to think about it in IOMMU.
>> > 
>> > Why? Without correct vector information, IOAPIC will not be able to
>> > know which entry to clear the Remote IRR bit (please check
>> > ioapic_eoi_broadcast())?
>> 
>> IOAPIC won't get correct EOI and Intel made it into an OS bug, because
>> there was no good action that the hardware could take.  (We have a lot
>> more freedom, but I think that partially fixing something that doesn't
>> work on real hardware is a wasted effort.)
> 
> To make sure I understand this correctly... Do you mean that real
> IOAPIC hardware will not handle this EOI broadcast correctly even if
> we fill in matched vector in the IOAPIC entry with IRTE one (when IR
> is enabled)?

No, if the OS configures same vector in IR and IOAPIC, then EOI
broadcast will work just fine.

My point was that the OS *must* do it that way.  If the OS doesn't, then
hardware's behavior is undefined = everything that happens is correct.
QEMU/KVM just shouldn't bug.  I think that QEMU even behaves pretty much
like real hardware here, so doing nothing now is the best choice.

> I'd appreciate if there is any link or anything that can provide me
> more background on this matter.. TIA.

Hm, I only read the specs ...

LAPIC EOI broadcast doesn't distinguish whether IOAPIC or IR injected
the interrupt and notifies IOAPICs with the vector in ISR.  The vector
doesn't provide enough information for a unique mapping between IOAPIC
and IR entries, so IOAPIC just clears Remote IRR bits of the vector.
There is no nice solution if you allow different vectors, so the
hardware doesn't.

>> Or did you mean that mismatched vector is a possible source of the fixed
>> bug?  (I originally dismissed it, because real hardware works.)
> 
> Nop. The above patch fixes the hack for "explicit IOAPIC EOI", and I
> suppose mismatched vector issue will cause "EOI broadcast" problem.
> But IIUC from your above comment, we can temporarily skip this
> "issue" for now, if it won't work even on real hardwares and even
> vectors are matched.
> 
> Anyway, as long as the explicit EOI works, we can survive. And this
> gives me the reason to send v5 first.

Yep.  EOI broadcast has to work in some cases, though, I'm sorry if I
said the opposite.