Messages in this thread | | | Subject | Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel | From | David Woodhouse <> | Date | Tue, 30 Jan 2018 14:57:27 +0000 |
| |
On Tue, 2018-01-30 at 14:54 +0000, Alan Cox wrote: > The only case I can think of where you'd get a non boot processor that > didn't have the same microcode loaded as the rest on entry to the OS would > be in a system where it was possibly to phyically hot plug processors > post boot. > > There are not many such systems and it may be that all of them do > sufficient deeply unmentionable things in their firmware to cover this.
We've got a patch lurking somewhere to properly collect the return code from microcode loading on all CPUs, because we've seen it *fail* on one CPU. Leaving them inconsistent, and on a kexec after that we really *did* see the boot CPU with IBRS support and a secondary without it.
But really, my point in this patch was not that I expect all this to work nicely, but that I don't want to make things *worse* by using setup_force_cpu_cap() when really I only want to set the bit for *this* CPU.
I'm *all* for ditching the per-CPU bitmasks since they're largely pointless and we've applied alternatives before the secondaries are brought up anyway. It's just a rabbithole I didn't need to go down today.[unhandled content-type:application/x-pkcs7-signature]
| |