On Mon, Feb 04, 2019 at 12:46:30PM -0800, Dave Hansen wrote: > 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.
Yap, makes sense. I've heard that argumentation before, btw. > 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_. Yap. > 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". So my only issue with this is the user having to type this in in order to get the feature. VS automatically enabling it during boot in early_init_intel() or so. No need for any user intervention. It'll be just like a forgotten CPUID bit and we've done those before. The disable chicken bits you have for all those features which are enumerated in CPUID anyway so there'll be no difference. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.