Commit 9b44423b authored by Wanpeng Li's avatar Wanpeng Li Committed by Paolo Bonzini
Browse files

KVM: VMX: Dont' send posted IRQ if vCPU == this vCPU and vCPU is IN_GUEST_MODE 



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 fdba608f, "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 379a3c8e ("KVM: VMX: Optimize posted-interrupt
delivery for timer fastpath") and 26efe2fd ("KVM: VMX: Handle
preemption timer fastpath").

Thanks Sean for better comments.

Suggested-by: default avatarChao Gao <chao.gao@intel.com>
Reviewed-by: default avatarSean Christopherson <seanjc@google.com>
Signed-off-by: default avatarWanpeng Li <wanpengli@tencent.com>
Message-Id: <1643111979-36447-1-git-send-email-wanpengli@tencent.com>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
parent 23e5092b

arch/x86/kvm/vmx/vmx.c

+21 −19
Original line number Diff line number Diff line
@@ -3937,30 +3937,32 @@ 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.

		 */



		if (vcpu != kvm_get_running_vcpu())

			apic->send_IPI_mask(get_cpu_mask(vcpu->cpu), pi_vec);

		return;

	}