This message is about a proposed userland modification, but it seems
more kernelish to me, hence I am asking here on tech-kern, rather than
on tech-userlevel
When my system boots (intel cpu) it runs the intel-microcode (from pkgsrc)
microcode update.
Since it is an Intel cpu, that means running the ioctl to perform the
microcode update on every core. The cpu has hyperthreading, and while
I sometimes am inclined to turn that off, I haven't so far.
Naturally, as they're really the same core, while the base core ucode
update works fine, the hyperthread companion always fails, as there the
microcode is already up to the expected version (surprise surprise, since
we just did that). I guess we could look and skip the update on
the hyperthread companion cores (pseudo-cores) but that's not what I am
proposing, partly because I'd have to work out how to do that, but also
because that by itself would only solve half the problem.
My processor also has 8 cores, with no hyperthreading, where it looks as
if internally, there's just 2 sets of ucode, one for the first 4, and one
for the second 4. Updates of the other 3 of each group find the ucode
version already installed, and error out.
So, what I am proposing is to have cpuctl simply ignore EEXIST errors from
the update the microcode" ioctl. unless the -v option (which already exists)
is given.
Note that this isn't fixing any real problem - everything works as it is now,
and everything (from what I can tell) gets updated correctly. The issue is
more cosmetic - the ucode update currently issues error messages for more than
half of my (apparent) cores, which looks ugly during the boot process, and
could lead to people wondering if there is a problem.
When I first installed the package from pgksrc to make this happen (a while
ago now) I immediately disabled it (in rc.conf) so it ran no more, as the
microcode version offered by the package was what my CPU came equipped with,
and every core complained about the version not actually being updated.
pkgsrc was updated to a newer version, with newer microcode, I installed
that, and enabled it again - and now I'm stuck with the ugly errors.
Perhaps someone has a better solution than this, perhaps checking which
microcode version is installed on each core, and not attemmpting to install
the update if it is the same version, but that's beyond my knowledge.
It also seems likely to me that it is simpler to just install anyway, and
ignore the "already there" error if it happens. Probably.
My proposed patch is appended - it builds, installs, and seems to work
just fine (not too much of a surprise, it is a trivial change).
Opinions?
kre
Index: cpuctl.8
===================================================================
RCS file: /cvsroot/src/usr.sbin/cpuctl/cpuctl.8,v
retrieving revision 1.20
diff -u -r1.20 cpuctl.8
--- cpuctl.8 17 May 2019 23:51:35 -0000 1.20
+++ cpuctl.8 2 Mar 2023 21:36:06 -0000
@@ -72,6 +72,10 @@
.Op Ar file
.Xc
This applies the microcode patch to CPUs.
+Unless
+.Fl v
+was given, errors indicating that the microcode
+already exists on the CPU in question are ignored.
If
.Ar cpu
is not specified or \-1, all CPUs are updated.
Index: cpuctl.c
===================================================================
RCS file: /cvsroot/src/usr.sbin/cpuctl/cpuctl.c,v
retrieving revision 1.32
diff -u -r1.32 cpuctl.c
--- cpuctl.c 1 Feb 2022 10:45:02 -0000 1.32
+++ cpuctl.c 2 Mar 2023 21:36:06 -0000
@@ -247,7 +247,7 @@
cpuset_destroy(cpuset);
}
error = ioctl(fd, IOC_CPU_UCODE_APPLY, &uc);
- if (error < 0) {
+ if (error < 0 && (verbose || errno != EEXIST)) {
if (uc.fwname[0])
err(EXIT_FAILURE, "%s", uc.fwname);
else
