[PATCH v3 0/2] KVM: x86: Suppress false positives on "lost" IRQs

[PATCH v3 0/2] KVM: x86: Suppress false positives on "lost" IRQs

[Sean Christopherson]

Don't WARN on "lost" IRQs if the VM has an in-kernel PIC or Xen emulation is
enabled, as vPIC and Xen emulation have guest-controllable and/or VM-wide IRQs
that can legitimately be consumed/deasserted without holding the vCPU's mutex.

v3:
 - Add a helper to weed out the problematic cases.
 - WARN in the "else" path so that there's only a single conditional branch
   in the happy path.
 - Exempt Xen. [Sashiko]

v2:
 - https://lore.kernel.org/all/86078441-92eb-4461-b823-7d3539ac5859@mail.kernel.org
 - Restrict the warning exemption to the in-kernel PIC case.
 - Remove the pr_err_ratelimited() logging.
 - Preserve the WARN_ON_ONCE() for non-PIC interrupt sources.

v1: https://lore.kernel.org/all/345e9d6c-d7d9-4bab-adb3-d6a7bd27599f@mail.kernel.org

Sean Christopherson (2):
  KVM: x86: Don't WARN if IRQ disappears because it was cleared from the
    PIC
  KVM: x86: Don't WARN if IRQ disappears when Xen emulation is enabled.

 arch/x86/kvm/irq.h        | 20 ++++++++++++++++++++
 arch/x86/kvm/vmx/nested.c |  4 +++-
 arch/x86/kvm/x86.c        |  4 +++-
 3 files changed, 26 insertions(+), 2 deletions(-)


base-commit: a204badd8432f93b7e862e7dac6db0fe3d65f370
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v3 1/2] KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC

[Sean Christopherson]

When getting a to-be-injected IRQ, don't WARN if the IRQ disappeared and
the VM has an in-kernel PIC, as the ExtINT handling that's routed through
KVM's virtual PIC is tracked per-VM, not per-vCPU.  If another vCPU grabs
the IRQ, or deasserts the interrupt (which is level-triggered), then it's
both expected and "fine" for a

Keep the assert for split IRQCHIP VMs to help detect KVM bugs, as userspace
is responsible for routing ExtINT to the intended vCPU, i.e. once an ExtINT
is pending, it can't be cleared without holding the vCPU's mutex, and thus
false positives are impossible.

Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it")
Debugged-by: Alexander Potapenko <glider@google.com>
Reported-by: syzbot+dd769db18693736eee89@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
Closes: https://lore.kernel.org/all/6a360fdf.871e809a.2d6dda.0000.GAE@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/irq.h        | 16 ++++++++++++++++
 arch/x86/kvm/vmx/nested.c |  4 +++-
 arch/x86/kvm/x86.c        |  4 +++-
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 1a84ea31e7fd..eeaf527cecc4 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -118,6 +118,22 @@ int kvm_cpu_has_extint(struct kvm_vcpu *v);
 int kvm_cpu_get_extint(struct kvm_vcpu *v);
 int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
 
+static inline void kvm_warn_on_lost_irq(struct kvm_vcpu *vcpu)
+{
+	/*
+	 * WARN if an IRQ was lost between detecting the IRQ and grabbing the
+	 * IRQ for injection, unless it's possible the lost IRQ was due to one
+	 * of the exceptional cases below.
+	 *
+	 * If the VM has an in-kernel PIC, the ExtINT handling that's routed
+	 * through KVM's virtual PIC is tracked per-VM, not per-vCPU.  If
+	 * another vCPU grabs the IRQ, or deasserts the interrupt (which is
+	 * level-triggered), then it's both expected and "fine" for an IRQ
+	 * seemingly be "lost" from this vCPU's perspective.
+	 */
+	WARN_ON_ONCE(!pic_in_kernel(vcpu->kvm));
+}
+
 void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);
 void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu);
 void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 0635e92471c8..c28a3ec4e4b7 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -4464,8 +4464,10 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu)
 		}
 
 		irq = kvm_apic_has_interrupt(vcpu);
-		if (WARN_ON_ONCE(irq < 0))
+		if (unlikely(irq < 0)) {
+			kvm_warn_on_lost_irq(vcpu);
 			goto no_vmexit;
+		}
 
 		/*
 		 * If the IRQ is L2's PI notification vector, process posted
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0626e835e9eb..e97b76b7794f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7686,10 +7686,12 @@ static int kvm_check_and_inject_events(struct kvm_vcpu *vcpu,
 		if (r) {
 			int irq = kvm_cpu_get_interrupt(vcpu);
 
-			if (!WARN_ON_ONCE(irq == -1)) {
+			if (likely(irq != -1)) {
 				kvm_queue_interrupt(vcpu, irq, false);
 				kvm_x86_call(inject_irq)(vcpu, false);
 				WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu, true) < 0);
+			} else {
+				kvm_warn_on_lost_irq(vcpu);
 			}
 		}
 		if (kvm_cpu_has_injectable_intr(vcpu))
-- 
2.55.0.229.g6434b31f56-goog

[PATCH v3 2/2] KVM: x86: Don't WARN if IRQ disappears when Xen emulation is enabled.

[Sean Christopherson]

When getting a to-be-injected IRQ, don't WARN if the IRQ disappeared and
Xen emulation is supported, as a guest could concurrently toggle its
evtchn_upcall_pending flag in shared memory and deassert the IRQ.  Even
more annoyingly, userspace could disable Xen emulation for the entire VM
KVM_XEN_HVM_CONFIG.  So, suppress WARNs on lost IRQs if Xen emulation is
supported to prevent false positives.

Alternatively, KVM could track if the VM has ever used Xen emulation, but
the added complexity isn't worth carrying given that the vast majority of
deployments can and should disable Xen emulation.

Fixes: bf672720e83c ("KVM: x86: check the kvm_cpu_get_interrupt result before using it")
Reported-by: Sashiko Bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260625212001.3B6561F000E9@smtp.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/irq.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index eeaf527cecc4..a74f03858004 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -130,8 +130,12 @@ static inline void kvm_warn_on_lost_irq(struct kvm_vcpu *vcpu)
 	 * another vCPU grabs the IRQ, or deasserts the interrupt (which is
 	 * level-triggered), then it's both expected and "fine" for an IRQ
 	 * seemingly be "lost" from this vCPU's perspective.
+	 *
+	 * Similarly, Xen's event channel isn't entirely within KVM's control,
+	 * e.g. Xen emulation can be disabled entirely per-VM, or the guest
+	 * can desassert an IRQ by writing to shared memory.
 	 */
-	WARN_ON_ONCE(!pic_in_kernel(vcpu->kvm));
+	WARN_ON_ONCE(!pic_in_kernel(vcpu->kvm) && !IS_ENABLED(CONFIG_KVM_XEN));
 }
 
 void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);
-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH v3 1/2] KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch resolves false-positive WARNs for missing interrupts by suppressing them when an in-kernel PIC is used, but fails to handle Xen event channels, leaving a guest-triggerable WARN for VMs without an in-kernel PIC.
--

--- Patch [1]: [PATCH v3 1/2] KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC ---
commit 6c8d9104c0454cc3f831a546f5333b795c67a6aa
Author: Sean Christopherson <seanjc@google.com>

KVM: x86: Don't WARN if IRQ disappears because it was cleared from the PIC

This patch suppresses a warning when an IRQ disappears during injection for
VMs with an in-kernel PIC, as ExtINT handling tracks this per-VM. It keeps
the assert for split IRQCHIP VMs to help detect KVM bugs.

Closes: https://syzkaller.appspot.com/bug?extid=dd769db18693736eee89
Closes: https://lore.kernel.org/all/6a360fdf.871e809a.2d6dda.0000.GAE@google.com

> diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
> index 1a84ea31e7fd2..eeaf527cecc46 100644
> --- a/arch/x86/kvm/irq.h
> +++ b/arch/x86/kvm/irq.h
> @@ -118,6 +118,22 @@ int kvm_cpu_has_extint(struct kvm_vcpu *v);
>  int kvm_cpu_get_extint(struct kvm_vcpu *v);
>  int kvm_cpu_get_interrupt(struct kvm_vcpu *v);
>  
> +static inline void kvm_warn_on_lost_irq(struct kvm_vcpu *vcpu)
> +{
> +	/*
> +	 * WARN if an IRQ was lost between detecting the IRQ and grabbing the
> +	 * IRQ for injection, unless it's possible the lost IRQ was due to one
> +	 * of the exceptional cases below.
> +	 *
> +	 * If the VM has an in-kernel PIC, the ExtINT handling that's routed
> +	 * through KVM's virtual PIC is tracked per-VM, not per-vCPU.  If
> +	 * another vCPU grabs the IRQ, or deasserts the interrupt (which is
> +	 * level-triggered), then it's both expected and "fine" for an IRQ
> +	 * seemingly be "lost" from this vCPU's perspective.
> +	 */
> +	WARN_ON_ONCE(!pic_in_kernel(vcpu->kvm));

[Severity: High]
This is a pre-existing issue, but does this warning also need to account for
Xen event channels?

If a guest is configured with a split IRQCHIP and Xen emulation, can a
malicious guest concurrently toggle evtchn_upcall_pending in its shared
vcpu_info memory to intentionally trigger this warning?

The guest could create a race condition where kvm_cpu_has_injectable_intr()
returns true, but the guest clears the flag before kvm_cpu_get_interrupt()
is called. This would result in an irq of -1, triggering the warning here
because pic_in_kernel() evaluates to false for split IRQCHIPs.

Could this be used by an unprivileged guest to cause a host denial of
service if panic_on_warn is enabled?

> +}
> +
>  void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724173425.278753-1-seanjc@google.com?part=1