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
exit.
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.
