* Dave Hansen <dave.han...@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
