Re: [PATCH v2 1/4] x86/split_lock: Enumerate #AC exception for split locked access feature

[Dave Hansen]

On 07/10/2018 12:47 PM, Thomas Gleixner wrote:
> And please tell your hardware people that they should stop creating
> features which are not enumerated in one way or the other. That's just a
> pain all over the place. Boot code, kernel, virt, tools ....

Assuming it's too late to get CPUID or MSR enumeration... (I haven't
given up on this yet, btw)

How about we #define a Linux-defined X86_FEATURE_SPLIT_LOCK_AC (or
whatever) for now.  When the hardware that has this bit for real shows
up, we move the #define to the "correct" place, like if it is a part of
an existing cpufeature leaf.

We also do a new setcpuid= boot option that behaves like the existing
clearcpuid=.  That option is used by the obscure, specialized split lock
detectino users to set the software cpufeature bit.

That way, we can merged this code *with* CPUID detection, and the only
thing we have to do in the future is move the X86_FEATURE_SPLIT_LOCK_AC
define to a better place.

It might be nice to make the setcpuid= thing use strings instead of
numbers that _can_ change from kernel-to-kernel, but that's kinda an
implementation detail.  If we have strings, maybe we can start using
clearcpuid=pku instead of our endless list of (new) boot parameters like
nopku, nosmap, nosmep, etc...