Re: [PATCH] x86/its: use Sapphire Rapids+ feature to opt out

[Dave Hansen <dave.hansen@intel.com>]

On 10/20/25 13:40, Pawan Gupta wrote:
>> I can’t speak to other VMMs (e.g. vmw, hyperv, hyperscalers) and how they do
>> it, but I suspect there are similar challenges around post-launch feature/bit
>> additions that require the VM to be completely cold-booted.
> Ok, that makes BUS_LOCK_DETECT a better choice than BHI_CTRL. I think it
> be better to replace BHI_CTRL with BUS_LOCK_DETECT.

Folks, I just think this kind of random feature spaghetti voodoo is a
bad idea. Suppose X86_FEATURE_BUS_LOCK_DETECT is in silicon on an
affected part but normally fused off. But a big customer shows up with a
big checkbook and Intel releases microcode to enumerate
X86_FEATURE_BUS_LOCK_DETECT on an affected part.

What then?

Your only choice is to convince Intel to make architectural the idea
that X86_FEATURE_BUS_LOCK_DETECT is never enumerated on an affected part.

Because even if we go forward with that patch we've *DONE* that in
Linux: we've made it de facto architecture and Intel can never change it.

Can someone try to boil down the problem statement for me again, please?

	VMs are slow because of mitigations for issues to which they are
	not vulnerable when running old kernels on old hypervisors.

Is that it?