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

[David Woodhouse]

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?

Attachment: smime.p7s
Description: S/MIME cryptographic signature