Re: [PATCH v3] KVM: x86: Add x2APIC "features" to control EOI broadcast suppression

[Sean Christopherson]

On Tue, Dec 02, 2025, David Woodhouse wrote:
> On Tue, 2025-12-02 at 08:36 -0800, Sean Christopherson wrote:
> > 
> > Hmm, I suppose that could work for uAPI.  Having both an ENABLE and a DISABLE
> > is obviously a bit odd, but slowing down the reader might actually be a good
> > thing in this case.  And the documentation should be easy enough to write.
> > 
> > I was worried that having ENABLE and DISABLE controls would lead to confusing code
> > internally, but there's no reason KVM's internal tracking needs to match uAPI.
> > 
> > How about this?
> > 
> > ---
> >  arch/x86/include/asm/kvm_host.h |  7 +++++++
> >  arch/x86/include/uapi/asm/kvm.h |  6 ++++--
> >  arch/x86/kvm/lapic.c            | 16 +++++++++++++++-
> >  arch/x86/kvm/x86.c              | 15 ++++++++++++---
> >  4 files changed, 38 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > index 5a3bfa293e8b..b4c41255f01d 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1226,6 +1226,12 @@ enum kvm_irqchip_mode {
> >  	KVM_IRQCHIP_SPLIT,        /* created with KVM_CAP_SPLIT_IRQCHIP */
> >  };
> >  
> > +enum kvm_suppress_eoi_broadcast_mode {
> > +	KVM_SUPPRESS_EOI_QUIRKED,
> > +	KVM_SUPPRESS_EOI_ENABLED,
> > +	KVM_SUPPRESS_EOI_DISABLED,
> > +};
> > +
> 
> Looks good. I'd probably call it KVM_SUPPRESS_EOI_LEGACY though?

Why legacy?  "Quirk" has specific meaning in KVM: technically broken behavior
that is retained as the default for backwards compatibility.  "Legacy" does not,
outside of a few outliers like HPET crud.

> And just for clarity I wouldn't embed the explicit checks against e.g
> arch.suppress_eoi_broadcast != KVM_SUPPRESS_EOI_LEGACY. I'd make static
> inline functions like

Ya, definitely no objection,
 
> static inline bool kvm_lapic_advertise_directed_eoi(kvm)

s/directed_eoi/suppress_eoi_broadcast.  I want to provide as clear of split as
possible between the local APIC feature and the I/O APIC feature.

> {
> 	/* Legacy behaviour was to advertise this feature but it
> didn't 
> 	 * actually work. */
> 	return kvm->arch.suppress_eoi_broadcast != KVM_SUPPRESS_EOI_DISABLED;
> }
> 
> static inline bool kvm_lapic_suppress_directed_eoi(kvm)

Too close to "suppress EOI broadcast", e.g. it would be easy to read this as
"suppress EOIs" and invert the polarity.  It's wordy, but I think
kvm_lapic_ignore_suppress_eoi_broadcast() is the least awful name.

> {
> 	/* Legacy behaviour advertised this feature but didn't
> actually
> 	 * suppress the EOI. */
> 	return kvm->arch.suppress_eoi_broadcast == KVM_SUPPRESS_EOI_ENABLED;
> }
> 
> Because it keeps the batshittery in one place and clearly documented?
> 
> I note your version did actually suppress the broadcast even in the
> DISABLED case if the guest had managed to set that bit in SPIV, but I
> don't think it *can* so that difference doesn't matter anyway, right?

Right.  If we want to be paranoid, we could WARN_ON_ONCE() in whatever the "ignore
broadcast" accessor is called, because it should only be used if the bit is enabled
in the local APIC.