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
