AMD CPUs Are Safe For Late-Loading Microcode, Will No Longer Taint The Linux Kernel

[phoronix]

Phoronix: AMD CPUs Are Safe For Late-Loading Microcode, Will No Longer Taint The Linux Kernel

Intel processors should have any CPU microcode updates loaded early during the Linux boot process to avoid various known issues. When "late loading" CPU microcode after the system is up and running, various issues can happen on Intel processors that led them to mark the Linux kernel as tainted under such conditions. Tainting the kernel also happened when late-loading microcode on AMD CPUs but now that's been deemed unnecessary and late-loading CPU microcode on AMD processors is reportedly safe...

https://www.phoronix.com/news/AMD-Late-Loading-Microcode

[kn00tcn]

Tainting the kernel also happened when late-loading microcode on AMD CPUs but now that's been deemed unnecessary and late-loading CPU microcode on AMD processors is reportedly safe.

famous last words

[Vorpal]

famous last words

They could always just change it again if it turns out they were wrong, or if it changes in a future generation.

[kn00tcn]

They could always just change it again if it turns out they were wrong, or if it changes in a future generation.

i was debating putting in a smiley because the sentence was a perfect set up for the joke (and "famous last words" is rarely used as serious)

[jabl]

Now if only AMD would push microcode updates to the linux-firmware repo so we could actually make use of this new capability..

[Michael]

Now if only AMD would push microcode updates to the linux-firmware repo so we could actually make use of this new capability..

They do...

[jabl]

They do...

Only occasionally. See e.g. the git log for fam17h https://git.kernel.org/pub/scm/linux...amd_fam17h.bin

For some unfathomable reason they want users to get their microcode updates via AGESA instead, which is much less likely to be applied.

[oiaohm]

For some unfathomable reason they want users to get their microcode updates via AGESA instead, which is much less likely to be applied.

https://www.tomshardware.com/news/amd-firmware-disables-cores-7600x

There is a most likely reason and its not a nice one that can be guess from the number of faults the AGESA microcode has had vs the number of faults the microcode from Linux firmware has had. The one uploaded to Linux firmware is the conservative one. AGESA is the one that may be OPPS I don't work right. The firmware you want some field testing before you put firmware on production servers and you don't want massive number installs doing that. AGESA currently looks to be used for the field testing role.

Jabl yes different in quality and delivery rate.

[Peter Fodrek]

What about varios microcodes for different loads and differnt CPU Rings for Zen 5 if task scheduller will change microcode?