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