On some Intel processors, the UMONITOR instruction can either cause performance loss or an inability to enter sleep states due to the monitoring hardware not reclaiming old addresses. Due to not reclaiming old addresses, the processor may enter a monitoring hardware overflow mode. This monitoring hardware overflow mode may lower performance for all threads. Alternatively, affected processors may reject new address monitoring requests, which can prevent the MWAIT instruction from entering sleep states.
The UMONITOR instruction is available at all privilege levels and thus this behavior may be caused by application software. The MONITOR instruction, which is only usable by privilege level 0, may also not reclaim old addresses.
In response to this issue, affected processors may disable the UMONITOR address monitoring. For some processors, this behavior occurs after a microcode update is loaded while for others it is the behavior at product launch. If disabled by default, a Model Specific Register (MSR) bit may be available for software to re-enable UMONITOR address monitoring.
Description
On some affected Intel processors, a high rate of MONITOR or UMONITOR instructions may exceed the capacity of an internal monitor tracking table within the processor, putting the processor into a monitor hardware overflow mode. Extra snoop traffic goes to the cores when in this monitor hardware overflow mode, which can lower their performance.
Alternatively, affected processors may have MONITOR or UMONITOR address monitoring requests not succeeding, which can impact UMWAIT or MWAIT entering sleep states.
Processors that do not have either behavior may indicate this to software by enumerating CPUID.7.2.EDX[bit7] MONITOR_MITG_NO as 1.
Potential Issues
Applications using UMONITOR may impact the overall system performance or power savings. Intel has not observed MONITOR impacting the system performance or power savings in production software.
Mitigation and Software Guidance
To address this, affected processors may disable UMONITOR address monitoring by default. Disabling UMONITOR address monitoring means that a UMONITOR does not set up an address monitor, which may prevent a subsequent UMWAIT from entering a sleep state. It does not mean that the UMONITOR instruction is disallowed or that the UMONITOR/UMWAIT CPUID enumeration, CPUID.7.0.ECX[5] (WAITPKG) is not set. On some processors, this disabling occurs only when a microcode update is loaded.
Disabling UMONITOR address monitoring prevents application software from putting the processor into address monitoring hardware overflow mode.
Applications that wish to avoid using the mitigation may wish to check that CPUID.7.2.EDX[7] MONITOR_MITG_NO is 1 in order to determine that the processor is unaffected by the issues described here. Note that some processors may only enumerate MONITOR_MITG_NO when a microcode update is loaded. Hypervisors should pass MONITOR_MITG_NO enumeration through to guests so that guests will know that UMONITOR and UMWAIT are effective.
Processors that disable UMONITOR address monitoring by default may support MSR bits to change the mitigation.
Processors that enumerate IA32_ARCH_CAPABILITIES[29] (IGN_UMONITOR_SUPPORT) will support IA32_MCU_OPT_CTL_MSR[6] (IGN_UMONITOR). System software can clear IGN_UMONITOR in order to enable UMONITOR address monitoring. Note that enabling UMONITOR address monitoring may allow UMONITOR to cause the issues described earlier.
Processors that enumerate IA32_ARCH_CAPABILITIES[30] (MON_UMON_MITG_SUPPORT) will support IA32_MCU_OPT_CTL_MSR[7] (MON_UMON_MITG). System software can set MON_UMON_MITG in order to enable an alternative mitigation. This alternative mitigation will try to avoid monitoring hardware overflow mode by trying to clear entries from the internal monitor tracking table more frequently. This should reduce the rate of entering monitor overflow mode and may enable leaving monitor overflow mode sooner. It may also cause wakeups from the monitor state on other threads/cores.
Application software cannot directly query the value of these MSR bits. For an application to know that UMONITOR is effective on a processor that does not enumerate MONITOR_MITG_NO, the operating system might need to create an API to inform the application software that UMONITOR has been re-enabled (by clearing IGN_UMONITOR_SUPPORT).
Future processors may not have these MSR bits, and Intel recommends that these MSR bits are not exposed to virtual machines by the hypervisor.
Note that the TPAUSE instruction is unaffected by this issue or its mitigation.
Enumeration
| Initial EAX Value | Information Provided About the Processor | Notes |
|---|---|---|
| 07H | EDX | Leaf 07H main leaf (ECX = 2). If ECX contains an invalid subleaf index, EAX/EBX/ECX/EDX return 0. |
| Bit 7: MONITOR_MITG_NO If 1, indicates that the MONITOR/UMONITOR instructions are not affected by performance or power issues due to MONITOR/UMONITOR instructions exceeding the capacity of an internal monitor tracking table. If 0, then the product may be affected by this issue. |
| Register Address Hex | Register Address DEC | Architectural MSR Name / Bit Fields | MSR / Bit Description | Comment |
|---|---|---|---|---|
| 10AH | 266 | IA32_ARCH_CAPABILITIES | Enumeration of Architectural Features (RO) | If CPUID.(EAX-07H, ECX=0):EDX[29]=1 |
| 10AH | 266 | 29 | IGN_UMONITOR_SUPPORT If 0, IA32_MCU_OPT_CTRL bit 6 (IGN_UMONITOR) is not supported. If 1, it indicates support of IA32_MCU_OPT_CTRL bit 6 (IGN_UMONITOR). |
|
| 10AH | 266 | 30 | MON_UMON_MITG_SUPPORT If 0, IA32_MCU_OPT_CTRL bit 7 (MON_UMON_MITG) is not supported. If 1, it indicates support of IA32_MCU_OPT_CTRL bit 7 (MON_UMON_MITG). |
| Register Address Hex | Register Address DEC | Architectural MSR Name / Bit Fields | MSR / Bit Description | Comment |
|---|---|---|---|---|
| 123H | 291 | IA32_MCU_OPT_CTRL | Microcode Update Option Control (R/W) | |
| 123H | 291 | 6 | IGN_UMONITOR If 0, UMONITOR instructions may set up an address monitor as described in their instruction definition. If 1 (default), UMONITORs will not set up address monitors1. This may cause later UMWAIT to not enter an implementation-dependent optimized state. |
If IA32_ARCH_CAPABILITIES[29]=1 |
| 7 | MON_UMON_MITG If 0 (default), Disabled. If 1, Enable: MONITOR and UMONITOR instructions will flush previously monitored addresses of the logical processor and, sometimes, nearby logical processors (on a sibling hyperthread or in the same module). This may reduce the rate of entering monitoring hardware overflow mode or may allow leaving that mode more quickly. Note that it may impact the latency of the MONITOR and UMONITOR instructions and may cause nearby logical processors to wake from sleep states. |
If IA32_ARCH_CAPABILITIES[30]=1 NOTE: The intent of this option is to try to keep the address monitoring hardware out of monitoring hardware overflow mode or recover faster if it is in that mode. |
Affected Processors
| CPUID Family_Model | Stepping | Code Names / Microarchitectures | Segment | Product Family |
|---|---|---|---|---|
|
06_8FH |
5,6,7,8 |
Sapphire Rapids |
Server |
4th Generation Intel® Xeon® Scalable Processors (formerly codenamed Sapphire Rapids) |
|
06_CFH |
1,2 |
Emerald Rapids |
Server |
5th Generation Intel® Xeon® Scalable Processors (formerly codenamed Emerald Rapids) |
|
06_AFH |
1,2 |
Sierra Forest |
Server |
Intel® Xeon® 6 with Efficient-cores processor family |
References
Intel® 64 and IA-32 Architectures Software Developer Manuals
Footnotes
- Note that when a UMONITOR does not set up an address monitor, it will not cause faults that would only occur on a memory access to that address monitor (for example, a page fault for the address monitor address).