Re: [PATCH v2] KVM: x86: Exempt in-kernel PIC from "disappearing" interrupt warning

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 25, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> [ ... ]
> > @@ -10857,7 +10857,9 @@ 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)) {
> > +			WARN_ON_ONCE(irq == -1 && !pic_in_kernel(vcpu->kvm));
> 
> [Severity: Medium]
> Does this inadvertently suppress the warning for APIC bugs in the default
> full-irqchip mode?
> 
> Since pic_in_kernel() evaluates to true when the in-kernel PIC is present,
> checking !pic_in_kernel() disables the warning entirely for all interrupt
> sources in that configuration. This appears to contradict the commit message
> intent of preserving the warning for other sources like the APIC.
> 
> [Severity: High]
> This is a pre-existing issue, but can a malicious guest still trigger this
> warning when KVM is configured with a split irqchip and Xen emulation is
> enabled?

Argh, yes.  

> If a guest concurrently toggles its evtchn_upcall_pending flag in memory
> while the host executes the event injection loop, it seems this path is
> directly reachable. 

Even more coarsely, userspace could disable Xen event stuff entirely via
KVM_XEN_HVM_CONFIG.  The easiest fix would be to condition the WARN on
!IS_ENABLED(CONFIG_KVM_XEN).  We could track if the VM has ever used Xen
emulation, but I don't think that's worth doing given that many deployments can
and should disable Xen emulation.

The other annoying issue is that vmx_check_nested_events() has the same flaw.
And I definitely don't want to toss that WARN either, because it recently found
a real bug that actually matters.

I'll send a v2 in the near-ish future to weed out CONFIG_KVM_XEN, and fix the
nVMX case as well, hopefully without having to duplicate too much code.