Christian Kujau <lists@nerdbynature.de> writes:

> That didn't work, as vmlinuz-vanilla now tried to find its initrd in 
> intel-ucode.img, but that did not contain a rootfs and it panicked with 
> this infamous "Kernel panic - not syncing: VFS: Unable to mount root 
> fs..." message.

I'm sorry, I gave you the wrong order, and I forgot that order is
very important here.  The order
--- initramfs-vanilla --- intel-ucode.bin
would have worked, if you need to keep them un-concatenated for some reason.

> So, while "intel-ucode.img --- initramfs-vanilla" did not work (tested 
> just now), I fiddled around some more (boy, was it late last night) and 
> although I dismissed it first, the concatenation of the microcode and the 
> initrd[0] did indeed work, although I am missing the usual "microcode" 
> messages in dmesg, something like:
>
>   microcode: sig=0x806e9, pf=0x80, revision=0xb4
>   microcode: Microcode Update Driver: v2.2.

I would expect this, because the microcode is now loaded by Xen before
Linux boots.  Linux sees the processor with up-to-date microcode.

Try `sudo xl dmesg |grep -i microcode` to verify that Xen is loading it.

You can also get the revision number for your processor's microcode from
/proc/cpuinfo: `grep -i microcode /proc/cpuinfo`.

If you have a copy of the GenuineIntel.bin file extracted from
intel-ucode.img, you could compare the revision number from
/proc/cpuinfo against the output of a command like:
iucode_tool  --list GenuineIntel.bin |grep -E 'sig 0x000806e9'
Look for "rev 0x" and some hex digits.  iucode_tool's output pads with
0s, /proc/cpuinfo doesn't.

Probably Alpine's update-extlinux needs some support added for the combo
of Xen and microcode.

-- Chris

Sorry for the late response, I only was able to do more tests today.

On Mon, 21 Oct 2019, Chris Brannon wrote:
> I'm sorry, I gave you the wrong order, and I forgot that order is
> very important here.  The order
> --- initramfs-vanilla --- intel-ucode.bin
> would have worked, if you need to keep them un-concatenated for some reason.

Yes, that did indeed work. And un-concatenated is nice, because both 
initramfs-vanilla (and sometimes maybe intel-ucode.bin) will get updated 
by OS updates, so the manual contatenation can be omitted. The only thing 
now left to do is to convince update-extlinux to append "--- 
intel-ucode.bin" to extlinux.conf, but that's just cosmetics :-)

> > initrd[0] did indeed work, although I am missing the usual "microcode" 
> > messages in dmesg, something like:
> >
> >   microcode: sig=0x806e9, pf=0x80, revision=0xb4
> >   microcode: Microcode Update Driver: v2.2.
> 
> I would expect this, because the microcode is now loaded by Xen before
> Linux boots.  Linux sees the processor with up-to-date microcode.

Yes, of course I meant to say "xl dmesg", but it's not visible there 
either. Both "xl dmesg" and "dmesg" are a little bit different of course, 
but the usual "microcode:" line is nowhere to be seen.

> You can also get the revision number for your processor's microcode from
> /proc/cpuinfo: `grep -i microcode /proc/cpuinfo`.

Indeed, that and some Xen hardware features are different when 
intel-ucode.bin is loaded.

Thanks again for your help!
Christian.


--- xl_dmesg_nofw
+++ xl_dmesg_fw
-(XEN) Command line: dom0_mem=512M,max:1024M
+(XEN) Command line: dom0_mem=512M,max:1024M ucode=scan
-(XEN)   Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD
+(XEN)   Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD MD_CLEAR
-(XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD-, Other: IBPB L1D_FLUSH
+(XEN)   Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD-, Other: IBPB L1D_FLUSH VERW
-(XEN)   Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU
-(XEN)   Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU
+(XEN)   Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU MD_CLEAR
+(XEN)   Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU MD_CLEAR
+(XEN) Multiple initrd candidates, picking module #1

-- 
BOFH excuse #436:

Daemon escaped from pentagram