Re: Late MCU, was: proposed cpuctl modification

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

Hello, all.

On 2023/03/05 11:01, Robert Elz wrote:
>     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

We _SHOULD_ support the early microcode update function in the boot loader
or the very early stage of the kernel initialization.

One of the big reason is that a new microcode may disable a function.
If the kerne use the function, the kernel may work incorrectly.
Such type of change usually can be identified by the correcponding
CPUID bit. It may be possible to reconfigure some kernel functions by
identifying such change, but it may not possible, and it's simpler to use
the early micorocode update function than to write such complicated code.

I tried to implement the early microcode loading stuff in our boot loader
but I couldn't finish the work. NetBSD developers may read my previos mail
I wrote 2018/01/19 subjected with "x86 microcode early update"...

> 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).

We can take two types of early loading.

 a) Update the microcode in the boot loader. Additional code is not required
    in the kerne.

 b) Load the micorocode image in the boot loader and copy it to a memory
    (buffer). Pass the pointer as a new boot argument. The kerne updates
    all CPU's microcode as soon as possible.

Please someone(TM) try to implement......



> 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
> 

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)