This document describes details about the microcode update (MCU) process on current Intel processors. We do not describe any future enhancements to the microcode update process — just information about recent processors.
This section describes the points when a microcode update may be loaded, listed as they occur chronologically from boot time.
The Firmware Interface Table (FIT) is a data structure located in the platform BIOS SPI flash that may contain pointers to one or more microcode updates. Loading a microcode update from the FIT is the preferred way to load a microcode update in Intel platforms, because it helps ensure all the update components1 are loaded at the earliest point in the boot process. Before executing the first instruction of the BIOS firmware at the Intel® architecture (IA) reset vector, the CPU processes the FIT to locate a microcode update suitable for that particular CPU. If a suitable update is found, the CPU loads the update before the first instruction of the BIOS firmware is fetched. After loading an update from the FIT, the bootstrap processor (BSP) begins fetching and executing the BIOS firmware from the IA reset vector, while the application processors (APs) enter into the Wait-for-SIPI state.
On some processors, a microcode update is loaded from the FIT only on the BSP core, while on other processors, it may be loaded on all cores.
A microcode update is loaded from the FIT after either a warm or cold hardware reset. It does not occur in response to an INIT event.
Where possible, Intel recommends loading new microcode updates from the FIT; for example, through installing a BIOS update.
Early BIOS microcode update is when a microcode update is loaded by BIOS before memory has been initialized.
Early BIOS microcode update may be performed by early BIOS initialization on the BSP. BIOS may skip this microcode update if an update has already been loaded via the FIT. BIOS can determine whether an update was loaded from the FIT by executing the CPUID instruction, and then reading IA32_BIOS_SIGN_ID (MSR 8BH). If IA32_BIOS_SIGN_ID[63:32] is non-zero, then an update was already loaded from the FIT, and the early BIOS microcode update load point may be skipped.
Intel recommends that updates are loaded very early in the BIOS initialization sequence, either via the FIT (preferred), or via early BIOS microcode update load before the BIOS Memory Reference Code is executed and before DRAM is available. This is needed to address issues that may affect the later BIOS code (like the BIOS Memory Reference Code).
When a microcode update is loaded from the FIT, it may be loaded on all processors or only on the BSP. When an update is loaded during early BIOS, it may also be loaded only on the BSP core, since application processor (AP) cores may not be awake at this point in the boot sequence. Therefore, as soon as possible after receiving the Startup Inter-Processor Interrupt (SIPI), BIOS software on the AP cores should load the update if it has not already been loaded from the FIT.
On more recent processors, certain architectural features, such as Intel® Software Guard Extensions (Intel® SGX), require an additional late BIOS microcode update. In order to enable these architectural features, a late BIOS microcode update must be performed on all logical processors, even if the same microcode update has already been loaded from the FIT or during early BIOS. In that case, late BIOS must reload the same update that was loaded earlier. Failure to perform the late BIOS microcode update on all logical processors may prevent these architectural features from being used.
During a late BIOS microcode update, the update may perform certain checks on the memory configuration and/or other settings required to enable these features. To facilitate the system checks, late BIOS load must occur after all of the following are completed:
In a multisocket system, BIOS software must provide synchronization to perform the late BIOS microcode update on all sockets in parallel. During the update sequence, each CPU will attempt to synchronize with CPUs in other sockets. Failure to load the update in parallel across sockets may cause this synchronization to fail, which may prevent certain architectural features from being enabled. This multisocket synchronization is only necessary during the late BIOS microcode update on processors supporting features that specifically require it. It is not required when loading a microcode update from the OS.
The operating system (OS) should check if it has a more recent microcode update (higher update revision) than the version applied by the BIOS. If it does, the OS should load that microcode update shortly after BIOS hands off control to the OS. This microcode update load point is called the early OS microcode update. This can be done by an early boot software layer such as a Unified Extensible Firmware Interface (UEFI) driver, a bootloader, the operating system, or any other software layer provided by the operating system (like early startup scripts). The early OS microcode update should be done on each core as early as possible in the OS boot sequence, before any CPUID feature flags or other enumeration values are cached by the OS software. It is also required to be loaded before any user-space applications or virtual machines are launched. This is necessary so that the update is loaded before the affected microcode is ever used, enabling any relevant mitigations for potential vulnerabilities as early as possible.
If the BIOS does not load the most recent microcode update, Intel recommends loading that update during the early OS microcode update.
Runtime microcode update refers to loading an update while the system is fully operational and running workloads, possibly including user-space applications and virtual machines. Software should ensure that the same update is loaded on all cores. Some microcode updates may introduce new features and may change CPUID feature flags or other enumeration. Software that wishes to use features introduced via a runtime microcode update may need to reevaluate any CPUID feature flags or other enumeration after the update is loaded in order to take advantage of any new capabilities introduced by that microcode update.
Runtime microcode update should be used when a system reset would be problematic (for example, when a system reset would impact server uptime requirements). Where possible, it is preferable to load microcode updates through BIOS or early OS.
A given microcode update may contain multiple individual components. For example, one component is used to add the IA32_SPEC_CTRL MSR and its underlying capabilities, while another component is used to add MD_CLEAR functionality to the VERW instruction. Additional components may also be used to mitigate various errata. Microcode updates are generally cumulative, which means that each update is a superset of all preceding updates for a given Processor Signature (CPUID Family/Model/Stepping) and Platform ID.
Microcode updates may introduce new capabilities. New capabilities are designed to be introduced in ways that will not break existing software that may be unaware of the changes. Software changes may be required to take advantage of the new capabilities. An example of this is the IA32_SPEC_CTRL MSR, which was introduced to existing processors through a microcode update.
Loading a microcode update will generally not remove any existing capabilities that may cause already running software to misbehave. This applies to baseline CPU functionality as well as any capabilities added via previous microcode updates. Exceptions to this will generally be communicated.
The microcode update is generally cleared by a warm reset. However, any state that persists across a warm reset (for example, last branch records or machine check banks) and has been modified by the update will remain modified after the reset.
One exception is that certain microcode update components only take effect after a warm reset (and thus are not cleared by warm reset). For such components, loading the update stages certain changes to take effect on the next warm reset. Since a warm reset generally clears the microcode update content, the processor may be affected only by those components that take effect after a warm reset between when that reset occurs and when the microcode update is later reloaded (at one of the previously discussed locations for microcode updates). A second warm reset (after the update is reloaded) is not needed.
Some microcode update components may only be effective if the update is loaded at or before a specific load point. In particular, some components may not take effect if the update is loaded after the late BIOS microcode update, or outside of the FIT. Any such requirements will be documented. If any component is not effective, it does not prevent other components within the same update from being effective.
Some microcode update components may impact system performance. Since the microcode update load point may determine the effectiveness of certain components, the performance impact of those components may also depend on the load point. Therefore, the same microcode update may have a different performance impact depending on when it is loaded.
Loading an update on one logical processor also loads the same update on all other logical processors in the same core (all of the sibling hyperthreads). For some processors, loading an update on one logical processor may also load the same update on logical processors on other physical cores. This may differ based on different configurations.
If software attempts to load an update with the same update revision as what is currently loaded, the CPU may or may not reload the update. Software can check the revision of the currently loaded update by executing the CPUID instruction and reading IA32_BIOS_SIGN_ID (MSR 8BH) to avoid reloading the same update unnecessarily.
Once loaded, some updates may prevent loading of another update with a lower update revision. If loading an update with a lower revision is allowed, loading the lower revision may not clear all aspects of the previously loaded update with the higher revision.
Loading a microcode update that creates a new software-controllable state will initialize that state to a well-defined setting described in the documentation associated with that particular capability.
Loading a microcode update will not perturb any settings of previously configured software-controllable states (for example, MSR values), even if those states were created by a previously loaded microcode update.
To load an update during runtime, software should synchronize all logical processors within the system (perform a rendezvous) to load the update in a coordinated manner.
Once all logical processors have been synchronized, one logical processor in each core should load the update while sibling logical processors wait in a spin loop of only basic instructions. Some guidelines are:
MWAIT or HLT. PAUSE or LFENCE may be used to throttle the loop.
microcode_update_sync() {
primary_thread_done = 0
check in to MCU_GO barrier
wait for MCU_GO barrier
if (primary_thread_of_core) { // always true if no HT
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id < 0 || update_id > rev_id) {
load_update()
}
primary_thread_done = 1
} else { // other HW threads (if they exist)
while (primary_thread_done == 0) {
pause //lfence is also acceptable
}
cpuid
rev_id = rdmsr(0x8b).edx
if (update_id != rev_id &&
(update_id < 0 || update_id > rev_id)) {
load_update()
}
}
check in to MCU_DONE barrier
wait for MCU_DONE barrier
}
Note:Executing the CPUID instruction will populate IA32_BIOS_SIGN_ID (MSR 8BH) with the current Update Revision regardless of the leaf value specified in EAX.
If the microcode update fails to load, system administrators should consider the following:
$ od -t x4 06-55-04 0000000 00000001 02000065 09052019 00050654Note: In this example, 02000065 is the microcode version, 09052019 is the date on which the IPU was created, and 00050654 is the family/model/stepping in the format returned by the CPUID instruction.
$ dmesg | grep microcode or $ cat /proc/cpuinfo | grep microcode | sort | uniq will give you a microcode version for comparison. Alternately, you can look for a microcode revision in the BIOS. reg query HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 /v "Update Revision".