Notes for making the sysutils/cpupdate port, testing, review etc
The manual page is currently only as this draft page, as I still have to format it using pod2man, as Eugene suggested.
microcode libraries to be used:
The paths for the are #defined in cpupdate.h.
They are currently set to
/usr/local/share/cpupdate/CPUMicrocodes/primary
--> gets searched first.
Intention: Place newest manufacturer's files there.
and
/usr/local/share/cpupdate/CPUMicrocodes/secondary
--> gets searched if no matching update found in the first directory
Intention: Place converted platomavs' files into.
The paths above get appended by the manufacturer names, currently defined as
#define VENDORNAME_INTEL ("Intel")
#define VENDORNAME_AMD ("AMD")
#define VENDORNAME_VIA ("VIA")
in cpupdate.h.
So the files downloadable from Intel here in the intel-ucode subdirectory of microcode-20180312.tgz could be placed in
/usr/local/share/cpupdate/CPUMicrocodes/primary/Intel
The platomav files converted to ready-to-use Intel multi-blobbed format (using cpupdate -C) could then be placed in
/usr/local/share/cpupdate/CPUMicrocodes/secondary/Intel
They are contained in the cpupdate github repo in plato_r62_intel.tar.bz2.
Spamminess and other issues:
When re-evaluating the CPU flags (in /usr/src/sys/dev/cpuctl/cpuctl.c, using function cpuctl_do_eval_cpu_features(), things get really spammy, because currently this function needs to be called once for every core.
So it easily can spam 500+ lines of repeated CPU stats output onto the console.
For this reason I was thinking about modifying cpuctl.c, so that all cores get reevaluated in one run, and displaying the result at the end once.
Ideally this could be combined when fixing up the issue discussed in this bugzilla thread: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487
Another potential problem with FreeBSD cpu detection:
However, this leads me to a potential issue with FreeBSD cpu identification: Think of a multiprocessor system, with processors of "same" type, but with different microcode versions and thus different processor features/flags.
At bootup, there seems to be displayed exactly *one* processor statistics, directly after the "FreeBSD clang version ..." line.
I am not sure whether this is good. Because, what if, say, core 0..11 have no IBRS etc, and cores 12..23 have it built-in in the ROM?
Will this be displayed correctly at bootup?
This is why I redesigned my CPU microcode display code (cpupdate -i) which executes in intel.c, function intel_getCoresInfo() which calls intel_getCoreInfo() for each core, storing its stats separately, and displaying them in blocks of identical cores (see the loop in intel_printcpustats()) to make it less spammy.
I have not yet looked into the bootup code whether it handles different cpu flags this way, or just takes one random core (#0?) to display?
Other notes:
cpucommon.h has been eliminated. The tabs are currently set to 4 spaces (I can change to 8 if needed).
I'd appreciate if you could review the code and make suggestions what to improve in coding, formatting etc.
If there is interest to use cpupdate as OS microcode updater for the base system, I would of course add AMD and VIA support.
Final Intel microcode fix release still to be released
Intel suggests in their latest microcode update guidance that (dated March 6) that the microcode update work is almost finished per March 6.
However, in their Mar 12 microcode release, there seem missing a lot of those updated microcodes (including the 06-2c-02 for Westmere processors which I am using).
I'll yet have to ask Intel support when these will be made available for download.
Until the complete set of microcodes that are discussed in the microcode update guidance are publicly available, one cannot say Intel has finished the task of providing complete meltdown/spectre fixing it reportedly was committed to.
At this opportunity I'll also ask Intel for their stance about microcode updates being included/distributed by OSes.
Installing microcode updates at early bootstrap stage?
As there are a number of microcode updates that actually remove processor features instead of adding them, it could be good to update the processors at early bootstrap stage, like Linux does (if microcode updating option is set).
In particular this regards buggy TSX being disabled on various processors (Broadwell, Haswell etc), on which it turned out that it was unfixable by microcode change.
So it could possibly be worth thinking about microcode update in early bootstrap, as there is no guarantee that history does not repeat in the sense that CPU functionality gets removed by microcode uploading, potentially crashing the OS already depending upon this functionality?
microcode libraries to be used:
The paths for the are #defined in cpupdate.h.
They are currently set to
/usr/local/share/cpupdate/CPUMicrocodes/primary
--> gets searched first.
Intention: Place newest manufacturer's files there.
and
/usr/local/share/cpupdate/CPUMicrocodes/secondary
--> gets searched if no matching update found in the first directory
Intention: Place converted platomavs' files into.
The paths above get appended by the manufacturer names, currently defined as
#define VENDORNAME_INTEL ("Intel")
#define VENDORNAME_AMD ("AMD")
#define VENDORNAME_VIA ("VIA")
in cpupdate.h.
So the files downloadable from Intel here in the intel-ucode subdirectory of microcode-20180312.tgz could be placed in
/usr/local/share/cpupdate/CPUMicrocodes/primary/Intel
The platomav files converted to ready-to-use Intel multi-blobbed format (using cpupdate -C) could then be placed in
/usr/local/share/cpupdate/CPUMicrocodes/secondary/Intel
They are contained in the cpupdate github repo in plato_r62_intel.tar.bz2.
Spamminess and other issues:
When re-evaluating the CPU flags (in /usr/src/sys/dev/cpuctl/cpuctl.c, using function cpuctl_do_eval_cpu_features(), things get really spammy, because currently this function needs to be called once for every core.
So it easily can spam 500+ lines of repeated CPU stats output onto the console.
For this reason I was thinking about modifying cpuctl.c, so that all cores get reevaluated in one run, and displaying the result at the end once.
Ideally this could be combined when fixing up the issue discussed in this bugzilla thread: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192487
Another potential problem with FreeBSD cpu detection:
However, this leads me to a potential issue with FreeBSD cpu identification: Think of a multiprocessor system, with processors of "same" type, but with different microcode versions and thus different processor features/flags.
At bootup, there seems to be displayed exactly *one* processor statistics, directly after the "FreeBSD clang version ..." line.
I am not sure whether this is good. Because, what if, say, core 0..11 have no IBRS etc, and cores 12..23 have it built-in in the ROM?
Will this be displayed correctly at bootup?
This is why I redesigned my CPU microcode display code (cpupdate -i) which executes in intel.c, function intel_getCoresInfo() which calls intel_getCoreInfo() for each core, storing its stats separately, and displaying them in blocks of identical cores (see the loop in intel_printcpustats()) to make it less spammy.
I have not yet looked into the bootup code whether it handles different cpu flags this way, or just takes one random core (#0?) to display?
Other notes:
cpucommon.h has been eliminated. The tabs are currently set to 4 spaces (I can change to 8 if needed).
I'd appreciate if you could review the code and make suggestions what to improve in coding, formatting etc.
If there is interest to use cpupdate as OS microcode updater for the base system, I would of course add AMD and VIA support.
Final Intel microcode fix release still to be released
Intel suggests in their latest microcode update guidance that (dated March 6) that the microcode update work is almost finished per March 6.
However, in their Mar 12 microcode release, there seem missing a lot of those updated microcodes (including the 06-2c-02 for Westmere processors which I am using).
I'll yet have to ask Intel support when these will be made available for download.
Until the complete set of microcodes that are discussed in the microcode update guidance are publicly available, one cannot say Intel has finished the task of providing complete meltdown/spectre fixing it reportedly was committed to.
At this opportunity I'll also ask Intel for their stance about microcode updates being included/distributed by OSes.
Installing microcode updates at early bootstrap stage?
As there are a number of microcode updates that actually remove processor features instead of adding them, it could be good to update the processors at early bootstrap stage, like Linux does (if microcode updating option is set).
In particular this regards buggy TSX being disabled on various processors (Broadwell, Haswell etc), on which it turned out that it was unfixable by microcode change.
So it could possibly be worth thinking about microcode update in early bootstrap, as there is no guarantee that history does not repeat in the sense that CPU functionality gets removed by microcode uploading, potentially crashing the OS already depending upon this functionality?
good way
AntwortenLöschen