Received: from trent.utfs.org (trent.utfs.org [94.185.90.103]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 0F883781B99 for ; Tue, 29 Oct 2019 10:23:41 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by trent.utfs.org (Postfix) with ESMTPS id 2637F5FB27; Tue, 29 Oct 2019 11:23:40 +0100 (CET) Date: Tue, 29 Oct 2019 03:23:40 -0700 (PDT) From: Christian Kujau To: Chris Brannon cc: alpine-user@lists.alpinelinux.org Subject: Re: Syslinux & Xen & microcode updates In-Reply-To: <875zkit0k1.fsf@cmbmachine.messageid.invalid> Message-ID: References: <87r236t8cl.fsf@cmbmachine.messageid.invalid> <875zkit0k1.fsf@cmbmachine.messageid.invalid> User-Agent: Alpine 2.21.99999 (DEB 352 2019-06-22) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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