Intel Microcode
General
This is some general information on Intel microcode and the iucode-tool. The latest microcode package can be found here:
https://downloadcenter.intel.com/search?keyword=Linux+Processor+Microcode+Data+File
The following link contains some good information on what exactly is in the microcode file:
http://inertiawar.com/microcode/
The file is actually a text file that has to be decoded by a tool and turned into a binary format that can be fed to a driver in Linux or Xen that can then load the appropriate microcode update for the CPUs (using an MSR specifically for doing this). The iucode-tool can be used on this file to list and to generate various file formats for different loading methods. On Debian you can install the tool with this package:
$ sudo apt-get install iucode-tool
This is an example of a snippet of the listing for the 7/14/2016 microcode file:
$ sudo iucode-tool -l microcode.dat
...
147: sig 0x000306f2, pf mask 0x6f, 2016-03-28, rev 0x0038, size 32768
148: sig 0x000306f4, pf mask 0x80, 2016-06-07, rev 0x000d, size 15360
149: sig 0x00040651, pf mask 0x72, 2016-04-01, rev 0x001f, size 20480
150: sig 0x00040661, pf mask 0x32, 2016-04-01, rev 0x0016, size 24576
151: sig 0x00040671, pf mask 0x22, 2016-04-29, rev 0x0016, size 11264
...
What is shown is the processor signature, processor flags mask, date and microcode revision for each update the package contains. From a serial output capture from Xen, note these lines (e.g. on my Dell E7440):
(XEN) microcode: collect_cpu_info : sig=0x40651, pf=0x40, rev=0x1c
(XEN) microcode: collect_cpu_info : sig=0x40651, pf=0x40, rev=0x1c
Looking at entry 149, the logic for applying a microcode update is the signatures match, the pf mask ANDed with the pf is non-zero and the update revision is greater than the current revision. In this case all the criteria are true so the microcode update will be applied.
Loading with Xen
The old method for loading microcode was to use the microcode_ctl tool in user space to decode and load the microcode via a kernel driver (or in OpenXT's case via a kernel driver that used a hypercall to get Xen to do it). Intel stopped supporting microcode_ctl in 2008 and this method and package are considered obsolete. Xen has the ability to load the microcode and apply it via GRUB modules and a command line argument. First the iucode-tool must be used to decode and convert the microcode into a binary format that is consumable by a Linux kernel and Xen (note Xen actually contains the Linux code to update Intel microcode). Do the following:
$ sudo iucode-tool -w intel-microcode.bin microcode.dat
Copy the .bin file to the /boot or similar directory on the target system running Xen (may or may not be OpenXT). Add a module line to the grub.conf:
module /boot/intel-microcode.bin
Finally update the Xen command line to include:
ucode=<index>
The index is a zero based index indicating the location of the microcode file in the list. Negative numbers mean start from the end of the list and count backwards (e.g. -1 is the last module). See the Xen command line documentation for more details. On a reboot, the microcode will be loaded by Xen (e.g. on the Dell E7440 above as was expected):
(XEN) microcode: collect_cpu_info : sig=0x40651, pf=0x40, rev=0x1c
(XEN) microcode: CPU2 found a matching microcode update with version 0x1f (current=0x1c)
(XEN) microcode: CPU2 updated from revision 0x1c to 0x1f, date = 2016-04-01
Note that in newer versions of Xen, many of the microcode messages are no longer traced out. So even though the microcode package is being loaded, if there is not microcode match for the system, nothing will be shown.