Load Microcode updates in an early initrd

[omkhar]

Current microcode update occurs as part of the "normal" boot process through systemd. Most distributions load the microcode as part of an early initrd in order to ensure that microcode errata is applied as as possible in the boot process. Please revise this in the Clear Linux kernel.

[ahkok]

We avoid making an initrd for all scenarios and only use them when they are strictly needed. For this reason we're applying microcode later.

[miguelinux]

We load microdode by placing the binary inside the kernel as show in

https://github.com/clearlinux-pkgs/linux/blob/master/config#L1570

[ahkok]

So is this invalid?

[miguelinux]

We are following the 3rd method from
https://github.com/torvalds/linux/blob/master/Documentation/x86/microcode.txt#L107

And there said that

so that the build system can find those files and integrate them into
the final kernel image. The early loader finds them and applies them.

[omkhar]

I am advocated method 1) which:

"1. Early load microcode

The kernel can update microcode very early during boot. Loading
microcode early can fix CPU issues before they are observed during kernel boot time."

Earlier in bring up the better, I believe. The other methods apply the microcode update later in the boot process.

[ahkok]

@miguelinux I don't understand whether that means that this bug is invalid, because we're loading microcode early enough to be effective, or not. That is the essence of my question.

[nesiusra]

We're going to stick with our current strategy until we receive real-world reports of it causing a problem.

[omkhar]

Couple of points:

1. The kernel module advises to load the microcode earlier (per dmesg):
   [ 1.395651] microcode: updated to revision 0x2a, date = 2018-01-18
   [ 1.397378] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
   [ 1.397379] x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.
2. The advantages of the "Early load microcode" are documented clearly here : https://github.com/torvalds/linux/blob/master/Documentation/x86/microcode.txt#L13 The fact that this method applies the microcode during BSP is clearly described.
3. Unfortunately, Intel does not provide extensive documentation of all the errata contained in the microcode update. If Intel is happy to state there is no advantage to loading this later in the kernel vs. during BSP, I'm happy to stand down. Can you confirm this is the case?

[bryteise]

I'll leave that decision to @miguelinux

[omkhar]

further suggestions of loading the microcode in initrd from dmesg:

[    0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x25 (or later)
[    0.394405] microcode: sig=0x306d4, pf=0x40, revision=0xa
[    0.394465] microcode: Microcode Update Driver: v2.2.
[    1.728056] microcode: updated to revision 0x2a, date = 2018-01-18
[    1.729825] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
[    1.729826] x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.

[omkhar]

Sorry why was this closed? I still see the following error in dmesg:

[ 1.516135] x86/CPU: CPU features have changed after loading microcode, but might not take effect.
[ 1.516137] x86/CPU: Please consider either early loading through initrd/built-in or a potential BIOS update.

[nesiusra]

The real solution is to keep your BIOS up to date, and we're not changing Clear's boot strategy at this time to use an initrd.

[omkhar]

I guess someone changes their mind?

[ 0.000000] microcode: microcode updated early to revision 0x2d, date = 2019-03-07
[ 0.000000] Linux version 5.1.15-791.native (mockbuild@kojibld02) (gcc version 9.1.1 20190626 gcc-9-branch@272664 (Clear Linux OS for Intel Architecture)) #1 SMP Wed Jun 26 09:17:59 UTC 2019
[ 0.000000] Command line: initrd=\EFI\org.clearlinux\freestanding-00-intel-ucode.cpio initrd=\EFI\org.clearlinux\freestanding-i915-firmware.cpio.xz root=PARTUUID=51eac487-e0e9-430b-ac2c-b9f39ff5c5ab quiet console=tty0 console=ttyS0,115200n8 init=/usr/bin/initra-desktop initcall_debug tsc=reliable no_timer_check noreplace-smp kvm-intel.nested=1 rootfstype=ext4,btrfs,xfs intel_iommu=igfx_off cryptomgr.notests rcupdate.rcu_expedited=1 rcu_nocbs=0-64 rw log_buf_len=4M

I'm happy