On Thu, 1 Jun 2017, Peter Zijlstra wrote: > That commit also states that is avoids a superfluous microcode load. And > we've verified on affected systems (both Thomas and I have a SKL system > with the PRMRR bit set in MTRRCAP) that when we manually load the > microcode image the reported revision number matches the one from the > image. > > [ 0.000000] microcode: microcode updated early to revision 0xba, date = > 2017-04-09 > [ 2.297894] microcode: sig=0x506e3, pf=0x2, revision=0xba > > And: > > # hexdump /lib/firmware/intel-ucode/06-5e-03 | head -1 > 0000000 0001 0000 00ba 0000 2017 0409 06e3 0005 > ^^^^^^^^^ > > So aside from a possible OS re-load of the microcode, the issue doesn't > appear to have any negative effect. > > > The microcode people (Cc'ed) might want to further look into this is > they care about avoiding the superfluous reload, but for the purpose of > this patch all is well.
Avoiding the superflous reload is dangerous. If the BIOS/FIT nonsense gets fixed (however unlikely that is) then we run into an even worse problem because then the kernel will not load version 5 if the CPU says version 4. That's way worse than reloading the same version for nothing. Thanks, tglx