To throw some extra fun mixture into this discussion: As of 5.19 Linux will no longer allow late microcode loading: ref: https://www.phoronix.com/news/Linux-5.19-Late-ucode-Loading There has been numerous “discussions” in certain circles that no longer make sense, and require early loading only (from BIOS updates). Given the cadence of such updates in the past, they were far and few between then, whereas they are much more frequent now. A solution may be something like a blob that gets loaded before the kernel is loaded and jumped to… or something where we -ensure- the microcode is loaded first and maintain system integrity. Intel will, of course, continue to provided updated microcode. Any thoughts on the best approach to this? (boot? EFI?) ~b -- William J. Coldwell @Cryo Cyber:@BlueCat Pres:@NetBSD Sui Generis Technomage PGP:0xF97CC215 ARIN:WC25/AS7769 "Put on 3D glasses, otherwise you only see in 1½D.” [self opinion]; > On Mar 2, 2023, at 3:25 PM, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: > > Date: Fri, 03 Mar 2023 09:25:29 +1100 > From: matthew green <mrg%eterna.com.au@localhost> > Message-ID: <14071.1677795929%splode.eterna.com.au@localhost> > > | we should do this as well, it should fairly simple. we already > | display the relevant info in "cpuctl identify 0" eg: > > Yes, identify shows all of the relevant info (including ucode version) > so all of this can certainly be done - it was just more than I wanted > to do to just suppress the annoying error messages... > > | hmm, someone seems to have broken this recently? > > Now you point it out, I am seeing that too. > > | that's odd, but we should handle it saner. > > My processor is odd - but it is very fast (in some of the cores anyway). > > | this seems odd to me. verbose should print additional info > | but it shouldn't change the actual behaviour here. > > When -v is given, the code is intended to operate exactly as it did > before (it will execute a few more instructions, but the effect should > be identical). > > | eg, if i were to use this with -v on your CPU, i'd want to > | have it show it working on cpu0 and cpu4, and EEXIST for > | the rest, and this appears that it will exit after cpu1. > > That is what it has always done. It exits after cpu0 as well. > And every other cpu - it only gets asked to update one cpu at a time. > In the Intel case, cpuctl is run on each cpu separately, not to attempt > to update all of them in one run (I'm not even sure that is possible, > or not with the code as it is now). > > It has never printed anything (with or without -v) for a > successful microcode update - before my change, the -v flag > appears to do nothing at all, so I wasn't too worried about > borrowing it. The kernel logs successful ucode updates however. > > All the change does, is ignore the EEXIST (and exit 0, not that the > exit status seems to matter to anything, at least as used in rc.d) > when -v is not given (which rc.d does not do), rather than printing > an error and doing exit(1). > > I don't have an AMD processor, where things are done differently, > to test this change on though. > > kre
Attachment:
signature.asc
Description: Message signed with OpenPGP