linux-kernel - [PATCH] KVM: x86: check PIR even for vCPUs with disabled APICv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211117080744.995111-1-pbonzini@redhat.com>
Date:   Wed, 17 Nov 2021 03:07:44 -0500
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Cc:     seanjc@...gle.com, stable@...r.kernel.org
Subject: [PATCH] KVM: x86: check PIR even for vCPUs with disabled APICv

After fixing the handling of POSTED_INTR_WAKEUP_VECTOR for vCPUs with
disabled APICv, take care of POSTED_INTR_VECTOR.  The IRTE for an assigned
device can trigger a POSTED_INTR_VECTOR even if APICv is disabled on the
vCPU that receives it.  In that case, the interrupt will just cause a
vmexit and leave the ON bit set together with the PIR bit corresponding
to the interrupt.

Right now, the interrupt would not be delivered until APICv is re-enabled.
However, fixing this is just a matter of always doing the PIR->IRR
synchronization, even if the vCPU does not have APICv enabled.

This is not a problem for performance, or if anything it is an
improvement.  static_call_cond will elide the function call if APICv is
not present or disabled, or if (as is the case for AMD hardware) it does
not require a sync_pir_to_irr callback.  And in the common case where
kvm_vcpu_apicv_active(vcpu) is true, one fewer check has to be performed.

Cc: stable@...r.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>
---
 arch/x86/kvm/x86.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dcefb1485362..eda86378dcff 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4445,8 +4445,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
 static int kvm_vcpu_ioctl_get_lapic(struct kvm_vcpu *vcpu,
 				    struct kvm_lapic_state *s)
 {
-	if (kvm_vcpu_apicv_active(vcpu))
-		static_call(kvm_x86_sync_pir_to_irr)(vcpu);
+	static_call_cond(kvm_x86_sync_pir_to_irr)(vcpu);

 	return kvm_apic_get_state(vcpu, s);
 }
@@ -9645,8 +9644,7 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
 	if (irqchip_split(vcpu->kvm))
 		kvm_scan_ioapic_routes(vcpu, vcpu->arch.ioapic_handled_vectors);
 	else {
-		if (kvm_vcpu_apicv_active(vcpu))
-			static_call(kvm_x86_sync_pir_to_irr)(vcpu);
+		static_call_cond(kvm_x86_sync_pir_to_irr)(vcpu);
 		if (ioapic_in_kernel(vcpu->kvm))
 			kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
 	}
@@ -9919,10 +9917,12 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)

 	/*
 	 * This handles the case where a posted interrupt was
-	 * notified with kvm_vcpu_kick.
+	 * notified with kvm_vcpu_kick.  Assigned devices can
+	 * use the POSTED_INTR_VECTOR even if APICv is disabled,
+	 * so do it even if !kvm_vcpu_apicv_active(vcpu).
 	 */
-	if (kvm_lapic_enabled(vcpu) && kvm_vcpu_apicv_active(vcpu))
-		static_call(kvm_x86_sync_pir_to_irr)(vcpu);
+	if (kvm_lapic_enabled(vcpu))
+		static_call_cond(kvm_x86_sync_pir_to_irr)(vcpu);

 	if (kvm_vcpu_exit_request(vcpu)) {
 		vcpu->mode = OUTSIDE_GUEST_MODE;
-- 
2.27.0