Xen PVOPS CPU microcode update support
Xen has support for updating the CPU microcode on Linux through two mechanisms, the early boot time CPU microcode patching mechanism and live run time updating. The preferred and recommended mechanism is to do use the early boot time CPU microcode patching unless there are mechanisms in place to ensure updates to the CPU microcode get propagated to userspace properly. At times there may also be reasons why microcode cannot be updated at runtime, one example would be the HSW disabling patch for Intel which can only be installed late if userspace has not used TSX instructions yet. Cases that require systems to not reboot for long periods of time may receive special attention and care to ensure live boot updates are possible but special care must be taken to ensure this will room smoothly. What each distribution chooses to support varies, for now Xen does not support run time microcode updates and some feature developments are required on the hypervisor before this is completed, detail are documented below.
Early boot time CPU microcode patching
Early boot time CPU microcode patching got initial support via the Xen 4.2 release with the addition of the 'ucode=<digit>' boot loader command line parameter which can be passed on to Xen which enabled support for specific microcode files to be used from a list of specified grub modules. Refer to the Xen 4.2 command line documentation for more details. Xen was later enhanced through the 4.5 release with 'ucode=scan' support which makes use of the new Linux early microcode format, for details refer to the Xen 4.5 command line documentation, Xen commit 155587481e392e4261038364e2761aab27f597ed, and Linux documentation Documentation/x86/early-microcode.txt. Folks can use latest version of dracut with --early-microcode parameter for this, for example.
Run time microcode updates
Run time updates can be supported by using the xenmicrocode (never merged upstream) tool (respinned later by Luis Rodriguez with initial guest pausing support). Some distributions have historically used a sysfs rescan mechanism:
echo 1 > /sys/devices/system/cpu/microcode/reload
to enable automatic run time updates but this is known to only be enabled now on Debian only. The sysfs entry will only be present on non-Xen kernels as when Xen is used the microcode module will not be loaded and thus the sysfs interface not exposed. Distributions wishing to use the sysfs interface should check for the existance of the sysfs file entry before trying to echo anything into it.
In the future in order to make use of run time microcode updates userspace for a distribution can be updated to use the proposed xenmicrocode tool instead of the sysfs interface when Xen is detected. In order for this tool to be completed the Andrew Cooper has recommended that the actions Xen needs to take are:
* Copy the buffer into Xen * Scan the buffer for the correct patch * Rendezvous all online cpus in an IPI to apply the patch, and keep the processors in until all have completed the patch.
The IPI itself probably wants common rendezvous code, and a system specific call for application. The system specific call will need to adhere to the requirements in the relevant manual. Care will have to be taken to avoid deadlocking with the time calibration rendezvous, and facilities such as the watchdog might temporally need pausing.
The last discussion:
SUSE / OpenSUSE Xen microcode updates
OpenSUSE / SUSE provides support for early boot time microcode patching, on Intel HSW run time updates are not supported, for details refer to bnc896736. All other run time updates should be supported.
Fedora Xen microcode updates
Fedora provides support for early boot time microcode patching.
Debian Xen microcode updates
Debian is known to handle run time updates on Debian stable by whitelisting known well working microcode files. Debian unstable does not allow any run time updates as black listing is a reactive process. Distributions should take care to only enable live updates of CPU microcode on special circumstances.