]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commitdiff
KVM: VMX: Dont' send posted IRQ if vCPU == this vCPU and vCPU is IN_GUEST_MODE
authorWanpeng Li <wanpengli@tencent.com>
Tue, 25 Jan 2022 11:59:39 +0000 (03:59 -0800)
committerPaolo Bonzini <pbonzini@redhat.com>
Thu, 10 Feb 2022 18:50:30 +0000 (13:50 -0500)
When delivering a virtual interrupt, don't actually send a posted interrupt
if the target vCPU is also the currently running vCPU and is IN_GUEST_MODE,
in which case the interrupt is being sent from a VM-Exit fastpath and the
core run loop in vcpu_enter_guest() will manually move the interrupt from
the PIR to vmcs.GUEST_RVI.  IRQs are disabled while IN_GUEST_MODE, thus
there's no possibility of the virtual interrupt being sent from anything
other than KVM, i.e. KVM won't suppress a wake event from an IRQ handler
(see commit fdba608f15e2, "KVM: VMX: Wake vCPU when delivering posted IRQ
even if vCPU == this vCPU").

Eliding the posted interrupt restores the performance provided by the
combination of commits 379a3c8ee444 ("KVM: VMX: Optimize posted-interrupt
delivery for timer fastpath") and 26efe2fd92e5 ("KVM: VMX: Handle
preemption timer fastpath").

Thanks Sean for better comments.

Suggested-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Message-Id: <1643111979-36447-1-git-send-email-wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
arch/x86/kvm/vmx/vmx.c

index cb54342c8ec23934923d5c7cffa4267339b2facb..a40130e5b55d1c9c67931a77cccaf2a86a1307c7 100644 (file)
@@ -3937,31 +3937,33 @@ static inline void kvm_vcpu_trigger_posted_interrupt(struct kvm_vcpu *vcpu,
 #ifdef CONFIG_SMP
        if (vcpu->mode == IN_GUEST_MODE) {
                /*
-                * The vector of interrupt to be delivered to vcpu had
-                * been set in PIR before this function.
+                * The vector of the virtual has already been set in the PIR.
+                * Send a notification event to deliver the virtual interrupt
+                * unless the vCPU is the currently running vCPU, i.e. the
+                * event is being sent from a fastpath VM-Exit handler, in
+                * which case the PIR will be synced to the vIRR before
+                * re-entering the guest.
                 *
-                * Following cases will be reached in this block, and
-                * we always send a notification event in all cases as
-                * explained below.
+                * When the target is not the running vCPU, the following
+                * possibilities emerge:
                 *
-                * Case 1: vcpu keeps in non-root mode. Sending a
-                * notification event posts the interrupt to vcpu.
+                * Case 1: vCPU stays in non-root mode. Sending a notification
+                * event posts the interrupt to the vCPU.
                 *
-                * Case 2: vcpu exits to root mode and is still
-                * runnable. PIR will be synced to vIRR before the
-                * next vcpu entry. Sending a notification event in
-                * this case has no effect, as vcpu is not in root
-                * mode.
+                * Case 2: vCPU exits to root mode and is still runnable. The
+                * PIR will be synced to the vIRR before re-entering the guest.
+                * Sending a notification event is ok as the host IRQ handler
+                * will ignore the spurious event.
                 *
-                * Case 3: vcpu exits to root mode and is blocked.
-                * vcpu_block() has already synced PIR to vIRR and
-                * never blocks vcpu if vIRR is not cleared. Therefore,
-                * a blocked vcpu here does not wait for any requested
-                * interrupts in PIR, and sending a notification event
-                * which has no effect is safe here.
+                * Case 3: vCPU exits to root mode and is blocked. vcpu_block()
+                * has already synced PIR to vIRR and never blocks the vCPU if
+                * the vIRR is not empty. Therefore, a blocked vCPU here does
+                * not wait for any requested interrupts in PIR, and sending a
+                * notification event also results in a benign, spurious event.
                 */
 
-               apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), pi_vec);
+               if (vcpu != kvm_get_running_vcpu())
+                       apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), pi_vec);
                return;
        }
 #endif