Message ID | 20240720000138.3027780-1-seanjc@google.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Fri, Jul 19, 2024 at 05:01:32PM -0700, Sean Christopherson wrote: >Fix a bug where KVM injects L2's nested posted interrupt into L1 as a >nested VM-Exit instead of triggering PI processing. The actual bug is >technically a generic nested posted interrupts problem, but due to the >way that KVM handles interrupt delivery, I'm 99.9% certain the issue is >limited to IPI virtualization being enabled. Theoretically VT-d posted interrupt can also trigger this issue. The fix looks good to me. For the whole series: Reviewed-by: Chao Gao <chao.gao@intel.com>
On Mon, Jul 22, 2024, Chao Gao wrote: > On Fri, Jul 19, 2024 at 05:01:32PM -0700, Sean Christopherson wrote: > >Fix a bug where KVM injects L2's nested posted interrupt into L1 as a > >nested VM-Exit instead of triggering PI processing. The actual bug is > >technically a generic nested posted interrupts problem, but due to the > >way that KVM handles interrupt delivery, I'm 99.9% certain the issue is > >limited to IPI virtualization being enabled. > > Theoretically VT-d posted interrupt can also trigger this issue. Hmm, yeah, I think you're right. L1 could program an assigned device to _post_ an interrupt to L2's vector, via L1's PID.PIR. Which would let the interrupt into vIRR without KVM checking vmcs12's NV. It seems unlikely L1 would do that, but it definitely seems possible. Unless I'm missing something (else), I'll update the changelog and Fixes: to make it clear that IPI virtualization just makes the bug easier to hit, but that the issue exists with nested assigned devices, too.
On Fri, 19 Jul 2024 17:01:32 -0700, Sean Christopherson wrote: > Fix a bug where KVM injects L2's nested posted interrupt into L1 as a > nested VM-Exit instead of triggering PI processing. The actual bug is > technically a generic nested posted interrupts problem, but due to the > way that KVM handles interrupt delivery, I'm 99.9% certain the issue is > limited to IPI virtualization being enabled. > > Found by the nested posted interrupt KUT test on SPR. > > [...] Applied to kvm-x86 vmx, with a massaged changelog to clarify that this bug could be hit even without IPI virtualization. [1/6] KVM: nVMX: Get to-be-acknowledge IRQ for nested VM-Exit at injection site https://github.com/kvm-x86/linux/commit/6f373f4d941b [2/6] KVM: nVMX: Suppress external interrupt VM-Exit injection if there's no IRQ https://github.com/kvm-x86/linux/commit/cb14e454add0 [3/6] KVM: x86: Don't move VMX's nested PI notification vector from IRR to ISR https://github.com/kvm-x86/linux/commit/f729851189d5 [4/6] KVM: nVMX: Track nested_vmx.posted_intr_nv as a signed int https://github.com/kvm-x86/linux/commit/ab9cbe044f83 [5/6] KVM: nVMX: Explicitly invalidate posted_intr_nv if PI is disabled at VM-Enter https://github.com/kvm-x86/linux/commit/be02aa1e52d2 [6/6] KVM: nVMX: Detect nested posted interrupt NV at nested VM-Exit injection https://github.com/kvm-x86/linux/commit/44518120c4ca -- https://github.com/kvm-x86/linux/tree/next
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c index f7dde74ff565..b07805daedf5 100644 --- a/arch/x86/kvm/vmx/nested.c +++ b/arch/x86/kvm/vmx/nested.c @@ -4288,6 +4288,15 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu) return -EBUSY; if (!nested_exit_on_intr(vcpu)) goto no_vmexit; + + if (nested_cpu_has_posted_intr(get_vmcs12(vcpu)) && + kvm_apic_has_interrupt(vcpu) == vmx->nested.posted_intr_nv) { + vmx->nested.pi_pending = true; + kvm_apic_clear_irr(vcpu, vmx->nested.posted_intr_nv); + goto no_vmexit; + } + nested_vmx_vmexit(vcpu, EXIT_REASON_EXTERNAL_INTERRUPT, 0, 0); return 0; }