Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid

[Dave Hansen]

On 2/4/19 11:57 AM, Borislav Petkov wrote:
> On Mon, Feb 04, 2019 at 11:05:52AM -0800, Dave Hansen wrote:
>> But, we're not being very persuasive because we kinda forgot about the
>> "if and only if" condition that you mentioned.
> But why does it have to be a cmdline parameter instead of
> being an automatic thing which sets the proper bits in
> arch/x86/kernel/cpu/intel.c based on f/m/s or MSR or whatever ?

It doesn't have to be a cmdline parameter.

Intel can obviously add or remove enumeration for a feature after
silicon ships.  But, that eats up microcode "patch" space which is an
even more valuable resource than the microcode "ROM" space.  That patch
space is a very constrained resource when creating things like the
side-channel mitigations.  The way I read this situation is that this
feature fills a bit small of a niche to justify consuming patch space.

So, the compromise we reached in this case is that Intel will fully
document the future silicon architecture, and then write the kernel
implementation to _that_.  Then, for the weirdo deployments where this
feature is not enumerated, we have the setcpuid= to fake the enumeration
in software.

The reason I'm pushing for setcpuid= instead of a one-off is that I
don't expect this to be the last time Intel does this.  I'd rather have
one setcpuid= than a hundred things like "ac_split_lock_disable".

The other alternative is that folks will run custom (non-mainline)
kernels with small patches to override the lack of enumeration.  Doing
setcpuid= keeps folks on mainline.  (BTW, we should probably taint the
kernel on setcpuid=....).