Re: [v2 1/3] x86/microcode/intel: Check microcode revision before updating sibling threads

[Henrique de Moraes Holschuh]

On Thu, 22 Feb 2018, Raj, Ashok wrote:
> On Thu, Feb 22, 2018 at 01:15:06PM +0100, Borislav Petkov wrote:
> > On Thu, Feb 22, 2018 at 03:55:54AM -0800, Raj, Ashok wrote:
> > > The current code wasn't trying to enforce checking the loaded microcode revision on a thread
> > > before attempting to load the microcode. While you comeback from resume, if C0T0 already
> > > is up, and we loaded the early microcode, then when handling C0T1 there is no need to 
> > > do a wrmsrl to reapply microcode since its already loaded as part of C0T0. 
> > 
> > And I'm asking exactly this: is it simply "we don't need to do WRMSR" or
> > "we should not"?
> > 
> > Because avoiding the WRMSR costs more than simply doing it and letting
> > the HT thread ignore the supplied microcode.
> 
> This isn't a simple WRMSR like others. Microcode engine needs to do 
> a bunch of validation.
> 
> > 
> > If it is "we don't need to but there's nothing wrong when we do it" then
> > we don't need this patch. And I'm pretty sure "nothing wrong when we do
> > it" would be the answer. Otherwise we have bigger problems.
> 
> In the past the only guidance was to not load microcode at the same time to the 
> thread siblings of a core. We now have new guidance that the sibling must be 
> spinning and not doing other things that can introduce instability around loading 
> microcode.

Document that properly in the Intel SDM, *please*.

While at it, please verify with the microcode teams that the requirement
for 16-byte alignment of the microcode update as present in the Intel
SDM still stands.  Linux does not enforce it on the early microcode
update loader when using an initramfs (but userspace can work around
that, and iucode_tool --early-fw does so).  If that 16-byte alignment is
important, I could dust off some patches that fix it.

-- 
  Henrique Holschuh