On 06/11/2017 14:53, Nikita Leshchenko wrote:
>
>> On 6 Nov 2017, at 4:00, Wanpeng Li <kernellwp@xxxxxxxxx> wrote:
>>
>> 2017-11-05 21:52 GMT+08:00 Nikita Leshenko <nikita.leshchenko@xxxxxxxxxx>:
>>> KVM uses ioapic_handled_vectors to track vectors that need to notify the
>>> IOAPIC on EOI. The problem is that IOAPIC can be reconfigured while an
>>> interrupt with old configuration is pending or running and
>>> ioapic_handled_vectors only remembers the newest configuration;
>>> thus EOI from the old interrupt is not delievered to the IOAPIC.
>>>
>>> A previous commit db2bdcbbbd32
>>> ("KVM: x86: fix edge EOI and IOAPIC reconfig race")
>>> addressed this issue by adding pending edge-triggered interrupts to
>>> ioapic_handled_vectors, fixing this race for edge-triggered interrupts.
>>> The commit explicitly ignored level-triggered interrupts,
>>> but this race applies to them as well:
>>>
>>> 1) IOAPIC sends a level triggered interrupt vector to VCPU0
>>> 2) VCPU0's handler deasserts the irq line and reconfigures the IOAPIC
>>> to route the vector to VCPU1. The reconfiguration rewrites only the
>>> upper 32 bits of the IOREDTBLn register. (Causes KVM to update
>>> ioapic_handled_vectors for VCPU0 and it no longer includes the vector.)
>>
>> Refer to __ioapic_write_entry() in linux guest kernel codes, both
>> upper 32 bits and lower 32 bits are written to IOREDTBLx, so when the
>> scenario which you mentioned will occur?
>
> You’re correct regarding Linux, but other operating systems may update
> the redirection entry partially.
>
> For example, ESXi 5.5 has a kernel function IOAPICSteerVector that
> modifies the Destination Field in the upper bits without affecting the
> lower bits of IOREDTBLx. We have observed that without this patch ESXi
> would loose network connectivity because it would get stuck with the
> Remote IRR bit set forever.
Thanks, this is helpful.
Can you write testcases for kvm-unit-tests for some or all of these
scenarios?
Thanks,
Paolo
