diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-07-24 10:34:25 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2026-07-27 12:44:00 -0700 |
| commit | 4f05a3337d7b27cd0c2da15b5f14a119613ce6bb (patch) | |
| tree | 9dc89389aea17222ebb6ebaad1d3e2754679dd64 | |
| parent | 681fb81a41711f1237899a2e24001d9b5d5efae4 (diff) | |
| download | linux-next-4f05a3337d7b27cd0c2da15b5f14a119613ce6bb.tar.gz linux-next-4f05a3337d7b27cd0c2da15b5f14a119613ce6bb.zip | |
KVM: x86: Don't WARN if IRQ disappears when Xen emulation is enabled.
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
Link: https://patch.msgid.link/20260724173425.278753-3-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
| -rw-r--r-- | arch/x86/kvm/irq.h | 6 |
1 files changed, 5 insertions, 1 deletions
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); |