Re: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late

[Ingo Molnar <mingo@kernel.org>]

* Dave Hansen <dave.hansen@intel.com> wrote:

> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > This is for the case where we need to set feature flags late, like, for
> > example, after late microcode patch has been loaded which has enabled
> > new CPUID bits.
> > 
> > This has no effect on alternatives patching.
> 
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
> 
> I'll also profess some microcode ignorance here.  Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?

So would it be really unreasonable to say that if a microcode update changes CPU 
flags an initrd rebuild and a reboot is required? It's not like microcode updates 
are _that_ frequent - in fact they tend to be much _less_ frequent in a system's 
life time than kernel updates.

So all of this 'late loading' and CPU flag splitting complexity seems unnecessary 
to me: we should be glad we do early microcode loading now, and should embrace it.

Changing CPU features way after the CPU has booted up is possible, and we could in 
theory extend code patching to work 'late' as well, but given how infrequent all 
this is bound to be in practice I fear it's all going to be a big, seldom tested, 
often broken mess, with no real benefit to users.

Thanks,

	Ingo