Message-ID: <cda9df77baa12272da735e739e132b2ac272cf9d.camel@infradead.org>
Date: Fri, 16 Jan 2026 09:01:06 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>, Khushit Shah
	 <khushit.shah@...anix.com>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>, "kai.huang@...el.com"
 <kai.huang@...el.com>, "mingo@...hat.com" <mingo@...hat.com>,
 "x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
 "hpa@...or.com" <hpa@...or.com>,  "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org"
 <kvm@...r.kernel.org>,  "dave.hansen@...ux.intel.com"
 <dave.hansen@...ux.intel.com>, "tglx@...utronix.de" <tglx@...utronix.de>, 
 Jon Kohler <jon@...anix.com>, Shaju Abraham <shaju.abraham@...anix.com>
Subject: Re: [PATCH v5 1/3] KVM: x86: Refactor suppress EOI broadcast logic

On Tue, 2026-01-13 at 16:10 -0800, Sean Christopherson wrote:
> Except that it needs to work when it's re-enabled in a few patches.  And as per
> commit c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI") and
> https://bugzilla.kernel.org/show_bug.cgi?id=82211, allegedly KVM needs to notify
> listeners in this case.

But KVM *will* notify listeners, surely? When the guest issues the EOI
via the I/O APIC EOIR register.

For that commit to have made any difference, Xen *has* to have been
buggy, enabling directed EOI in the local APIC despite the I/O APIC not
having the required support. Thus interrupts never got EOI'd at all,
and sure, the notifiers didn't get called.

> Given that KVM didn't actually implement Directed EOI in the in-kernel I/O APIC,
> it's certainly debatable as to whether or not that still holds true, i.e. it may
> have been a misdiagnosed root cause.  But I have zero interest in finding out
> the hard way, especially since the in-kernel I/O APIC is slowly being deprecated,
> and _especially_ not in patches that will be Cc'd stable.

Isn't that *exactly* the issue we knew we were resolving properly by
implementing the EOIR in the I/O APIC?

We should test, sure. But I don't think the existence of that commit
should make us throw our hands up in the air and be too scared of just
fixing it properly.

> So while I agree it would be nice to simultaneously enable the in-kernel I/O APIC,
> I want to prioritize landing the fix for split IRQCHIP.  And if we're clever,
> enabling in-kernel I/O APIC support in the future shouldn't require any new uAPI,
> since we can document the limitation and not advertise
> KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST in KVM_CAP_X2APIC_API when run on a VM
> without a split IRQCHIP.  Then if support is ever added broadly, we can drop the
> relevant code that requires irqchip_split() and update the documentation to say
> that userspace need to query KVM_CAP_X2APIC_API on a VM fd to determine whether
> or not the flag is supported for an in-kernel I/O APIC.
> 
> If someone has a strong need and use case for supporting Supress EOI Broadcast for
> an in-kernel I/O APIC, then they can have the honor of proving that things like
> Windows and Xen play nice with KVM's implementation.  And they can do that on top.
> 
> Compile tested only, but this is what I'd like to go with for now (in a single
> patch, because IMO isolating the refactoring isn't a net positive without patch 2/3).

I dislike this. It's just another wart. And it looks like userspace can
still check the cap and set KVM_X2APIC_ENABLE_SUPPRESS_EOI_BROADCAST,
and *then* add the in-kernel I/O APIC afterwards?

If you're concerned about what to backport to stable, then arguably
it's *only* KVM_X2APIC_DISABLE_SUPPRESS_EOI_BROADCAST which should be
backported, as that's the bug, and _ENABLE_ is a new feature?



Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)

Powered by blists - more mailing lists