Re: [PATCH 6/6] kvm: x86: do not use KVM_REQ_EVENT for APICv interrupt injection

From: Radim KrÄmÃÅ
Date: Thu Feb 09 2017 - 10:12:57 EST

2017-02-08 17:23+0100, Paolo Bonzini:
> On 07/02/2017 20:58, Radim KrÄmÃÅ wrote:
>>> - local_irq_disable();
>>> + if (kvm_lapic_enabled(vcpu)) {
>>> + /*
>>> + * This handles the case where a posted interrupt was
>>> + * notified with kvm_vcpu_kick.
>>> + */
>>> + if (kvm_x86_ops->sync_pir_to_irr)
>>> + kvm_x86_ops->sync_pir_to_irr(vcpu);
>> Hm, this is not working well when nesting while L1 has assigned devices:
>> if the posted interrupt arrives just before local_irq_disable(), then
>> we'll just enter L2 instead of doing a nested VM exit (in case we have
>> interrupt exiting).
>> And after reading the code a bit, I think we allow posted interrupts in
>> L2 while L1 has assigned devices that use posted interrupts, and that it
>> doesn't work.
> So you mean the interrupt is delivered to L2? The fix would be to wrap
> L2 entry and exit with some subset of pi_pre_block/pi_post_block.

I hope not, as their PI strucutres are separate, so we'd be just
delaying the interrupt injection to L1. The CPU running L2 guest will
notice a posted notification, but its PIR.ON will/might not be set.
L1's PIR.ON will be set, but no-one is going to care until the next VM

I'll add some unit tests to check that I understood the bug correctly.

Changing the notification vector for L2 would be an ok solution.
We'd reserve a new vector in L0 and check L1's interrupts. If it were
targetting a VCPU that is currently in L2 with a notification vector
configured for L2, we'd translate that vector into the notification
vector we set for L2 -- L1 could then post interrupts to L2 without a VM
exit. And "posted" interrupts for L1 while in L2 would trigger a VM
exit, because the notification vector would be different.