UMONITOR

UMONITOR arms the address monitor for UMWAIT: it is the MONITOR that user code may run. A store to the watched range then ends a UMWAIT, or keeps one from starting. The UMWAIT page has the loop around the pair, with the flag checked before UMONITOR, between the two and after the wait, as Intel’s optimization manual shows it; this page is about the arming.

The address#

MONITOR always takes its address from RAX. UMONITOR takes it from any register named by its ModRM byte, whose width follows the address size: a 64-bit register in 64-bit code, a 32-bit one with a 67 prefix. DS is the default segment and a segment prefix may override it. The range around the address is as large as CPUID leaf 05H reports for the monitor line, and only write-back memory is promised to trigger it. With -mwaitpkg, GCC 14 and Clang 23 at -O2 compile _umonitor(p) to umonitor rdi.

UMONITOR reads nothing, but it is checked and ordered as a load of one byte: a page that is not readable raises #PF, and it sets the page’s accessed bit but not its dirty bit. Inside a TSX transaction it aborts the transaction.

Not interchangeable with MONITOR#

The pairs do not mix: MWAIT does not wait if UMONITOR ran after the last MONITOR, and UMWAIT does not wait if MONITOR ran after UMONITOR. The UMWAIT page lists the other events that leave it without an armed monitor.

The encoding#

UMONITOR is F3 0F AE /6 with a register operand. With a memory operand the same bytes are CLRSSBSY, a CPL 0 instruction of CET; with 66 or F2 in place of F3, the register forms are TPAUSE and UMWAIT, and with no prefix the register form is MFENCE.

UMONITOR needs WAITPKG (CPUID leaf 07H, ECX bit 5) and raises #UD without it; -march=alderlake and sapphirerapids include it, znver5 and x86-64-v4 do not. No AMD processor in this site’s data has WAITPKG, and the Zen 5 guest that ran the probe did not report it, so this page has no recorded cases. AMD’s nearest equivalent is MONITORX, with MWAITX.

In the optimization guide

What the optimization guide says about UMONITOR, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Tremont

• Instruction set and Lakefield: Tremont adds UMWAIT, TPAUSE, CLWB, CLDEMOTE and the direct stores, which GCC enables for it. sources differ

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

a = src.read()                   # a register of the address size: 64
                                 # bits, 32 with a 67 prefix; DS: or a
                                 # segment prefix's base
if not canonical(a):
    fault(GP, 0)
if not readable(a):
    fault(PF)                    # the checks of a 1-byte read
# arms the monitor on the range that holds a, for UMWAIT, at any
# privilege level

Operands

Flags

None: XED records no flag that the forms test or change.

Attributes

What else XED records about the forms. How to read.

All forms

may abort a TSX transaction

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to UMONITOR, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More WAITPKG instructions

• TPAUSE
• UMWAIT