Re: Late MCU, was: proposed cpuctl modification

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 3 Mar 2023 21:46:22 -0800
    From:        "William 'Cryo' Coldwell" <billc%NetBSD.org@localhost>
    Message-ID:  <7CE92F54-3746-4106-BD63-16E5E4CBCDBF%NetBSD.org@localhost>

  | 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

I suspect this message was not really aimed at me, but at tech-kern
my only specific knowledge about any of this is that I dislike spurious
(seeming) error messages during the boot sequence - and so intend to
make them go away (as there has been no objection, I will commit that
change soon).

But:
  | Any thoughts on the best approach to this? (boot? EFI?)

Best?  No idea.   But one approach might be to only start cpu0 in the
kernel during bootstrap, and then have the rest started by an rc.d
script, which could update microcode on them (if needed) first.

By moving cpuctl from /usr/sbin to /sbin and placing the firmware in
/libdata instead of /usr/pkg that could be made to happen very early
in the boot sequence (perhaps even before the fsck of / and rw mount).

I'm not sure how that would work wrt other things that have to happen
(like arranging interrupt routing) - as clearly the microcode needs to
be read from the filesystem (whether that's by the kernel, as now, or
by cpuctl, then passing a memory image of it to the kernel doesn't seem
as if it would make a lot of difference).

Longer term this could be coupled with more userland control of the
cpu configuration - all being done at once as part of the startup
sequence, but from userland code.

Whatever the issues really are (according to the Linux people) with
doing the microcode update as we now do it, even assuming that is more
or less the same as they do it, this should be safe, as code running
on a CPU has to do it, I don't see it can make any real difference
whether than is bios code, boot code, or early kernel code.

I don't much like the idea of extra magic blobs, or more hackery in
the boot code however.

kre