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: bf672720e8 ("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>
This commit is contained in:
Sean Christopherson 2026-07-24 10:34:25 -07:00
parent 681fb81a41
commit 4f05a3337d

View File

@ -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);