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: <7c35e9e79c62803e3cb61be9cd013daf1e5aa4d1.camel@infradead.org>
Date: Tue, 02 Dec 2025 16:04:06 +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 07:42 -0800, Sean Christopherson wrote:
> 
> The issue is that KVM "enables" SUPPRESS_EOI_BROADCAST in that the feature is
> exposed to the guest and can be enabled in local APICs, and that's one of the
> behaviors/configurations I want to preserve so that guests don't observe a feature
> change.  Having an on/off switch doesn't work because KVM isn't fully disabling
> the feature, nor is KVM fully enabling the feature.  It's a weird, half-baked
> state, hence the QUIRK.
> 
> More importantly, we can't use ENABLE bits because I want to preserve existing
> behavior exactly as-is.  I.e. userspace needs to opt-in to disabling
> SUPPRESS_EOI_BROADCAST and/or to disabling IGNORE_SUPPRESS_EOI_BROADCAST_QUIRK.

To respond to that part directly...

The legacy behaviour we need to preserve is neither fully enabled, nor
fully disabled. I agree that the default needs to remain this weird
half-baked quirk.

But now we are giving userspace a chance to explicitly choose either a
proper ENABLE or a proper DISABLE, and isn't that what those flags
should be called?

You have ENABLE, you have DISABLE, and you have a warning that you
probably ought to choose one of them because the default you get
otherwise is weirdly broken (but there for legacy compatibility).



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