You are not logged in.
I have an Arch system running as a VM Host based on Xen 4.4.1
It is yet unclear to me why the VMHost (Dom0) cannot update the CPU microcode of the AMD Opteron 3365.
The following errors appear.
[ 9.664531] microcode: CPU0: patch_level=0x0600081c
[ 9.664548] microcode: CPU1: patch_level=0x0600081c
[ 9.664566] microcode: CPU2: patch_level=0x0600081c
[ 9.664580] microcode: CPU3: patch_level=0x0600081c
[ 9.664593] microcode: CPU4: patch_level=0x0600081c
[ 9.664607] microcode: CPU5: patch_level=0x0600081c
[ 9.664624] microcode: CPU6: patch_level=0x0600081c
[ 9.664639] microcode: CPU7: patch_level=0x0600081c
[ 9.664723] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 18.344286] microcode: CPU0: update failed for patch_level=0x06000832
[ 18.345579] microcode: CPU1: update failed for patch_level=0x06000832
[ 18.346899] microcode: CPU2: update failed for patch_level=0x06000832
[ 18.348202] microcode: CPU3: update failed for patch_level=0x06000832
[ 18.349488] microcode: CPU4: update failed for patch_level=0x06000832
[ 18.350776] microcode: CPU5: update failed for patch_level=0x06000832
[ 18.352063] microcode: CPU6: update failed for patch_level=0x06000832
[ 18.353352] microcode: CPU7: update failed for patch_level=0x06000832
I am aware that Xen can do some early loading of microcodes, since I have found clues in the Xen git logs.
But I guess Xen does not update the microcode, since the OS in Dom0 believes it is necessary to update the microcode.
Does anybody have a clue why updating the CPU microcode from within Dom0 fails?
Last edited by ArthurBorsboom (2015-01-10 12:45:29)
Offline
So your message is from the host? Then why would this be Xen-related?
Offline
I am not sure if this is Xen related, but I believe it is worth mentioning it.
Xen is a type 1 hypervisor, which is loaded before the Linux kernel.
After Xen is loaded, it will load the Linux kernel in Dom0.
The error messages are from Dom0, which is loosely translated the VM Host.
Offline
Does the live cd / stick environment also have these issues or does it work there? That might indicate whether this is hardware or software related
Offline
That might be a good test to perform. It is a bit risky, since the server is in Germany and I access it remotely from The Netherlands.
But I will try to boot the regular Linux kernel, without Xen to see if the microcode update does succeed and report back.
Offline
After a reboot without Xen, so with the regular Arch kernel, the microcode does get applied.
[arthur@orion1695 ~]$ dmesg | grep microcode
[ 0.900044] microcode: CPU0: patch_level=0x0600081c
[ 0.900056] microcode: CPU1: patch_level=0x0600081c
[ 0.900069] microcode: CPU2: patch_level=0x0600081c
[ 0.900079] microcode: CPU3: patch_level=0x0600081c
[ 0.900090] microcode: CPU4: patch_level=0x0600081c
[ 0.900101] microcode: CPU5: patch_level=0x0600081c
[ 0.900112] microcode: CPU6: patch_level=0x0600081c
[ 0.900123] microcode: CPU7: patch_level=0x0600081c
[ 0.900226] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 10.032208] microcode: CPU0: new patch_level=0x06000832
[ 10.046910] microcode: CPU2: new patch_level=0x06000832
[ 10.065461] microcode: CPU4: new patch_level=0x06000832
[ 10.084018] microcode: CPU6: new patch_level=0x06000832
So it is likely that the issue is caused by Xen
.
Anybody have suggestions how to get the microcode applied *with* Xen running?
Offline
I have solved the issue by using the Xen early microcode loading with the following changes.
Copy the correct microcode binary to the boot folder.
sudo cp /lib/firmware/amd-ucode/microcode_amd_fam15h.bin /boot
Edit the Xen command line in /etc/xen/grub.conf from
XEN_HYPERVISOR_CMDLINE="dom0_mem=1024M,max:1024M xsave=1"
to
XEN_HYPERVISOR_CMDLINE="dom0_mem=1024M,max:1024M xsave=1 ucode=-1"
Hardcode the /etc/grub.d/09_xen configuration file to load the binary.
From
menuentry "Xen ${XEN_VERSION} / Arch Linux ${_KERNEL_PKG_} kernel" ${CLASS} {
$(save_default_entry)
if [ x\$feature_all_video_module = xy ]; then
insmod all_video
fi
set gfxpayload=keep
insmod ${BOOT_PART_FS}
if [ x\$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root ${BOOT_PART_HINTS_STRING} ${BOOT_PART_FS_UUID}
else
search --no-floppy --fs-uuid --set=root ${BOOT_PART_FS_UUID}
fi
echo '$(printf "Loading Xen %s ..." ${XEN_VERSION})'
multiboot ${REAL_DIR}/${XEN_BASENAME} ${REAL_DIR}/${XEN_BASENAME} ${XEN_HYPERVISOR_CMDLINE}
echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel ...'
module ${REAL_DIR}/${_KERNEL_FILE_} ${REAL_DIR}/${_KERNEL_FILE_} root=${GRUB_LINUX_ROOT_DEVICE} rw ${GRUB_LINUX_PARAMS}
echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel initramfs ...'
module ${REAL_DIR}/${_INITRAMFS_}
}
To
menuentry "Xen ${XEN_VERSION} / Arch Linux ${_KERNEL_PKG_} kernel" ${CLASS} {
$(save_default_entry)
if [ x\$feature_all_video_module = xy ]; then
insmod all_video
fi
set gfxpayload=keep
insmod ${BOOT_PART_FS}
if [ x\$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root ${BOOT_PART_HINTS_STRING} ${BOOT_PART_FS_UUID}
else
search --no-floppy --fs-uuid --set=root ${BOOT_PART_FS_UUID}
fi
echo '$(printf "Loading Xen %s ..." ${XEN_VERSION})'
multiboot ${REAL_DIR}/${XEN_BASENAME} ${REAL_DIR}/${XEN_BASENAME} ${XEN_HYPERVISOR_CMDLINE}
echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel ...'
module ${REAL_DIR}/${_KERNEL_FILE_} ${REAL_DIR}/${_KERNEL_FILE_} root=${GRUB_LINUX_ROOT_DEVICE} rw ${GRUB_LINUX_PARAMS}
echo 'Loading Arch Linux ${_KERNEL_PKG_} kernel initramfs ...'
module ${REAL_DIR}/${_INITRAMFS_}
echo 'Loading AMD Microcode'
module ${REAL_DIR}/microcode_amd_fam15h.bin
}
Rebuild the grub configuration file
sudo grub-mkconfig -o /boot/grub/grub.cfg
And reboot
Check with the following command that Xen is running
dmesg | grep xen
Check with the following command that the microcode has the correct version
[arthur@orion1695 ~]$ dmesg | grep microcode
[ 9.379631] microcode: CPU0: patch_level=0x06000832
[ 9.379645] microcode: CPU1: patch_level=0x06000832
[ 9.379662] microcode: CPU2: patch_level=0x06000832
[ 9.379676] microcode: CPU3: patch_level=0x06000832
[ 9.379692] microcode: CPU4: patch_level=0x06000832
[ 9.379710] microcode: CPU5: patch_level=0x06000832
[ 9.379724] microcode: CPU6: patch_level=0x06000832
[ 9.379738] microcode: CPU7: patch_level=0x06000832
[ 9.379823] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[arthur@orion1695 ~]$
And as you see in this example, there is no attempt to update the microcode anymore, since it is already up-to-date.
I hope this helps other people facing this issue.
Offline