mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2026-05-02 02:47:31 -04:00
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 commitfdba608f15, "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 commits379a3c8ee4("KVM: VMX: Optimize posted-interrupt delivery for timer fastpath") and26efe2fd92("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>
This commit is contained in:
committed by
Paolo Bonzini
parent
23e5092b6e
commit
9b44423bf4
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user