Re: [PATCH] x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel

[David Woodhouse]

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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature