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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dbca1be3e0e7a1a778b211b2b38e85a16d80d9f9.camel@infradead.org>
Date: Tue, 02 Dec 2025 22:35:48 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Khushit Shah <khushit.shah@...anix.com>, "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>,
 "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v3] KVM: x86: Add x2APIC "features" to control EOI
 broadcast suppression

On Tue, 2025-12-02 at 14:26 -0800, Sean Christopherson wrote:
> 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.

OK, fair enough.

> > 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.

OK.

And the in-kernel I/O APIC still doesn't have directed EOI, so do we
want to prevent userspace from enabling the broadcast suppression? Or
just enable the directed EOI support in the kernel I/O APIC if
broadcast suppression is enabled?

> > {
> > 	/* 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.

I think I meant to type 'kvm_lapic_suppress_eoi_broadcast' that time
anyway, as in *actually* suppress the EOI broadcasting, rather than
merely falsely advertising it.

But sure, I'm not too hung up on precisely how we name these helpers
but I think it is helpful for them to exist. FWIW I think your name
means we have to invert the return value from how I typed it too.

> > {
> > 	/* 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.

I don't think we care; just calling out the finer details so they don't
get missed accidentally.


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