Re: [PATCH v5 1/3] KVM: x86: Refactor suppress EOI broadcast logic

[Sean Christopherson <seanjc@google.com>]

On Fri, Jan 16, 2026, Khushit Shah wrote:
> > On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > 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.

Oh, I 100% agree there were bugs aplenty on both sides, but that's exactly why I
don't want to add support for the in-kernel I/O APIC without a strong reason for
doing so.

> You are describing 
> 0bcc3fb95b97 ("KVM: lapic: stop advertising DIRECTED_EOI when in-kernel IOAPIC is in use”)
> Since then I guess this issue should have been fixed?!  As
> c806a6ad35bf ("KVM: x86: call irq notifiers with directed EOI”)  was much earlier.
> 
> > On 16 Jan 2026, at 2:31 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > 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?
> 
> I think neither DISABLE or ENABLE is a new feature at least for split
> IRQCHIP.  It’s just giving a way to user-space to fix a bug in a way they
> like, because that’s how it should have been from the beginning.

Ya.  I don't see ENABLE (for split IRQCHIP) as a new feature, because it's the
only way for userspace to fix its setups without changing the virtual CPU model
exposed to the guest.

For better or worse, the aforementioned commit 0bcc3fb95b97 ("KVM: lapic: stop
advertising DIRECTED_EOI when in-kernel IOAPIC is in use”) already clobbered the
virtual model when using an in-kernel I/O APIC.  Even though KVM (AFAIK) got away
with the switcheroo then, I am strongly opposed to _KVM_ changing the virtual CPU
model.  I.e. I want to give userspace the ability to choose how to address the
issue, because only userspace (or rather, the platform owner) knows whether or
not its I/O APIC implementation plays nice with ENABLE, whether it's risker to
continue with QUIRK vs. DISABLE, etc.