lkml.org 
[lkml]   [2018]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch RFC 1/5] x86/CPU: Sync CPU feature flags late
* 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

\
 
 \ /
  Last update: 2018-01-14 23:20    [W:0.139 / U:1.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site