In usage models where it is critical to avoid downtime (such as in cloud service environments), the ability to load microcode updates at runtime without a reboot is essential. Previously, operating system software had no indication whether a given update was suitable to be loaded at runtime without causing unexpected impact to running software or other system instability. This article describes how Intel will identify whether a given microcode update is suitable to be loaded during runtime. Operating system software can use this information to make informed decisions about whether to load an update at runtime.
Background
Microcode updates may be loaded into the processor at various points during and after the system boot process. A microcode update may be loaded into the processor by the BIOS, UEFI, or other system firmware before the operating system is launched. Subsequently, the operating system (OS) itself may load a newer microcode update during the OS boot process before user-level application or virtual machines are launched; this is known as OS early load. Additionally, the OS may support loading newer microcode updates during runtime, after the main operating system or virtual machine monitor has booted and is fully operational, running workloads including user-space applications and virtual machines; this is known as runtime update or OS late load.
While all microcode updates are generally suitable for loading during BIOS or OS early load, some microcode updates may not be suitable for runtime load. Updates that deprecate features or change interfaces in a way that may adversely impact running software are examples of microcode updates that may not be suitable for runtime update. Past microcode updates have not provided any software-consumable indication of which updates are suitable for runtime update versus which are not.
This article describes how Intel will identify updates that are suitable for runtime load. These changes do not impact the loading of microcode updates from BIOS, UEFI, or other system firmware, nor OS early load during the boot process.
Minimum Runtime Update Revision
Whether a particular microcode update (MCU) is suitable for runtime update depends on the specific content of the MCU as well as the microcode revision already loaded on the system prior to the runtime update.
A previously reserved field in the microcode update header is allocated to indicate the Minimum Runtime Update Revision. This field indicates the minimum revision of the currently loaded MCU required to support runtime update of the new MCU. Operating system software may use this information to make an informed decision regarding runtime load.
The format of the microcode update header is fully documented in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3, Chapter 10, Section 11.1 Microcode Update. A portion of the header format is shown below to indicate the location of the new Minimum Runtime Update Revision field.
| Field | Offset (bytes) | Size (bytes) | Description |
|---|---|---|---|
| Header Version | 0 | 4 | Version number of the update header |
| Update Revision | 4 | 4 | Unique version number for the update |
| Date | 8 | 4 | Date of update creation |
| Processor Signature | 12 | 4 | Family/model/stepping of the processor to which this update applies |
| Checksum | 16 | 4 | Checksum of the update header and data |
| Loader Revision | 20 | 4 | Version of the loader required to load this update |
| Processor Flags | 24 | 4 | Bitmask of platform IDs to which this update applies |
| Data Size | 28 | 4 | Size (in bytes) of the encrypted data |
| Total Size | 32 | 4 | Size (in bytes) of the entire update, including all header and data fields |
| Reserved | 36 | 4 | Reserved for future use |
| Minimum Runtime Update Revision | 40 | 4 | Minimum revision of the currently loaded update required to support runtime loading of this update |
| Reserved | 44 | 4 | Reserved for future use |
| Update Data | 48 | Variable | Encrypted update data |
For microcode updates that may be suitable for runtime update, the Minimum Runtime Update Revision field indicates the minimum MCU revision that must already be loaded to support runtime loading of the new MCU.
For microcode updates that are not suitable for runtime update, the Minimum Runtime Update Revision will be set equal to its own update revision, indicating that this update is not suitable for runtime update over any previous update revision. Such updates are still suitable for OS early loading.
Microcode updates with a Minimum Runtime Update Revision field of zero may or may not be suitable for runtime update. This includes updates released prior to the introduction of the Minimum Runtime Update Revision field. Operating system software may choose to prevent runtime loading of updates that do not specify a Minimum Runtime Update Revision. OS early load of such updates can still be allowed.
Runtime update software may examine the Minimum Runtime Update Revision of the incoming MCU to determine whether the MCU is suitable for runtime update. If the Minimum Runtime Update Revision is non-zero and the revision of the currently loaded MCU is greater than or equal to the Minimum Runtime Update Revision, then the MCU is suitable for runtime update. If the Minimum Runtime Update Revision field is zero, or if the revision of the currently loaded microcode update is less than the Minimum Runtime Update Revision, then the MCU may not be suitable for runtime update and should not be loaded at runtime.
For example, if the incoming MCU is revision 10, and its Minimum Runtime Update Revision field is 6, then MCU revision 10 is suitable for runtime update if the current MCU revision is greater than or equal to 6.
The following pseudo-code demonstrates how to determine whether an MCU is suitable for runtime update:
Suitable_For_Runtime_Update(Update_Base) {
wrmsr(IA32_BIOS_SIGN_ID, 0)
cpuid(1)
Current_Revision = rdmsr(IA32_BIOS_SIGN_ID) >> 32
if (Update_Base.Min_Runtime_Update_Revision != 0 &&
Current_Revision >= Update_Base.Min_Runtime_Update_Revision) {
return True
} else {
return False
}
}