Intel 64 and IA-32 Architectures. Software Developer’s Manual (2026)

VMX INSTRUCTION REFERENCE

FI;

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the memory operand effective address is outside the CS, DS, ES, FS, or GS segment limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the operand is located in an execute-only code segment.

#PF(fault-code)

If a page fault occurs in accessing the memory operand.

#SS(0)

If the memory operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If operand is a register.

If not in VMX operation.

Real-Address Mode Exceptions

#UD

The VMCLEAR instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMCLEAR instruction is not recognized in virtual-8086 mode.

Compatibility Mode Exceptions

#UD

The VMCLEAR instruction is not recognized in compatibility mode.

64-Bit Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the source operand is in the CS, DS, ES, FS, or GS segments and the memory address is in

a non-canonical form.

#PF(fault-code)

If a page fault occurs in accessing the memory operand.

#SS(0)

If the source operand is in the SS segment and the memory address is in a non-canonical

form.

#UD

If operand is a register.

If not in VMX operation.

33-12

Vol. 3C

VMCLEAR-Clear Virtual-Machine Control Structure

VMX INSTRUCTION REFERENCE

VMFUNC-Invoke VM function

Opcode/

Op/En

Description

Instruction

NP 0F 01 D4

Invoke VM function specified in EAX.

VMFUNC

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

Description

This instruction allows software in VMX non-root operation to invoke a VM function, which is processor functionality

enabled and configured by software in VMX root operation. The value of EAX selects the specific VM function being

invoked.

The behavior of each VM function (including any additional fault checking) is specified in Section 28.5.7,

“VM Functions.”

Operation

Perform functionality of the VM function specified in EAX;

Flags Affected

Depends on the VM function specified in EAX. See Section 28.5.7, “VM Functions.”

Protected Mode Exceptions (not including those defined by specific VM functions)

#UD

If executed outside VMX non-root operation.

If “enable VM functions” VM-execution control is 0.

If EAX ≥ 64.

Real-Address Mode Exceptions

Same exceptions as in protected mode.

Virtual-8086 Exceptions

Same exceptions as in protected mode.

Compatibility Mode Exceptions

Same exceptions as in protected mode.

64-Bit Mode Exceptions

Same exceptions as in protected mode.

VMFUNC-Invoke VM function

33-13

Vol. 3C

VMX INSTRUCTION REFERENCE

VMLAUNCH/VMRESUME-Launch/Resume Virtual Machine

Opcode/

Op/En

Description

Instruction

0F 01 C2

Launch virtual machine managed by current VMCS.

VMLAUNCH

0F 01 C3

Resume virtual machine managed by current VMCS.

VMRESUME

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

Description

Effects a VM entry managed by the current VMCS.

• VMLAUNCH fails if the launch state of current VMCS is not “clear”. If the instruction is successful, it sets the

launch state to “launched.”

• VMRESUME fails if the launch state of the current VMCS is not “launched.”

If VM entry is attempted, the logical processor performs a series of consistency checks as detailed in Chapter 29,

“VM Entries.” Failure to pass checks on the VMX controls or on the host-state area passes control to the instruction

following the VMLAUNCH or VMRESUME instruction. If these pass but checks on the guest-state area fail, the logical

processor loads state from the host-state area of the VMCS, passing control to the instruction referenced by the RIP

field in the host-state area.

VM entry is not allowed when events are blocked by MOV SS or POP SS. Neither VMLAUNCH nor VMRESUME should

be used immediately after either MOV to SS or POP to SS.

Operation

IF (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSIF current-VMCS pointer is not valid

THEN VMfailInvalid;

ELSIF events are being blocked by MOV SS

THEN VMfailValid(VM entry with events blocked by MOV SS);

ELSIF (VMLAUNCH and launch state of current VMCS is not “clear”)

THEN VMfailValid(VMLAUNCH with non-clear VMCS);

ELSIF (VMRESUME and launch state of current VMCS is not “launched”)

THEN VMfailValid(VMRESUME with non-launched VMCS);

ELSE

Check settings of VMX controls and host-state area;

IF invalid settings

THEN VMfailValid(VM entry with invalid VMX-control field(s)) or

VMfailValid(VM entry with invalid host-state field(s)) or

VMfailValid(VM entry with invalid executive-VMCS pointer)) or

VMfailValid(VM entry with non-launched executive VMCS) or

VMfailValid(VM entry with executive-VMCS pointer not VMXON pointer) or

33-14

Vol. 3C

VMLAUNCH/VMRESUME-Launch/Resume Virtual Machine

VMX INSTRUCTION REFERENCE

VMfailValid(VM entry with invalid VM-execution control fields in executive

VMCS)

as appropriate;

ELSE

Attempt to load guest state and PDPTRs as appropriate;

clear address-range monitoring;

IF failure in checking guest state or PDPTRs

THEN VM entry fails (see Section 29.8);

ELSE

Attempt to load MSRs from VM-entry MSR-load area;

IF failure

THEN VM entry fails

(see Section 29.8);

ELSE

IF VMLAUNCH

THEN launch state of VMCS := “launched”;

FI;

IF in SMM and “entry to SMM” VM-entry control is 0

THEN

IF “deactivate dual-monitor treatment” VM-entry

control is 0

THEN SMM-transfer VMCS pointer :=

current-VMCS pointer;

FI;

IF executive-VMCS pointer is VMXON pointer

THEN current-VMCS pointer :=

VMCS-link pointer;

ELSE current-VMCS pointer :=

executive-VMCS pointer;

FI;

leave SMM;

FI;

VM entry succeeds;

FI;

Further details of the operation of the VM-entry appear in Chapter 29.

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

#UD

If executed outside VMX operation.

Real-Address Mode Exceptions

#UD

The VMLAUNCH and VMRESUME instructions are not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMLAUNCH and VMRESUME instructions are not recognized in virtual-8086 mode.

VMLAUNCH/VMRESUME-Launch/Resume Virtual Machine

33-15

Vol. 3C

VMX INSTRUCTION REFERENCE

VMPTRLD-Load Pointer to Virtual-Machine Control Structure

Opcode/

Op/En

Description

Instruction

NP 0F C7 /6

Loads the current VMCS pointer from memory.

VMPTRLD m64

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ModRM:r/m (r)

Description

Marks the current-VMCS pointer valid and loads it with the physical address in the instruction operand. The instruc-

tion fails if its operand is not properly aligned, sets unsupported physical-address bits, or is equal to the VMXON

pointer. In addition, the instruction fails if the 32 bits in memory referenced by the operand do not match the VMCS

revision identifier supported by this processor.¹

The operand of this instruction is always 64 bits and is always in memory.

Operation

IF (register operand) or (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSE

addr := contents of 64-bit in-memory source operand;

IF addr is not 4KB-aligned OR

addr sets any bits beyond the physical-address width^2,3

THEN VMfail(VMPTRLD with invalid physical address);

ELSIF addr = VMXON pointer

THEN VMfail(VMPTRLD with VMXON pointer);

ELSE

rev := 32 bits located at physical address addr;

IF rev[30:0] ≠ VMCS revision identifier supported by processor OR

rev[31] = 1 AND processor does not support 1-setting of “VMCS shadowing”

THEN VMfail(VMPTRLD with incorrect VMCS revision identifier);

ELSE

current-VMCS pointer := addr;

VMsucceed;

FI;

1. Software should consult the VMX capability MSR VMX_BASIC to discover the VMCS revision identifier supported by this processor

(see Appendix A, “VMX Capability Reporting Facility”).

2. If IA32_VMX_BASIC[48] is read as 1, VMfail occurs if addr sets any bits in the range 63:32; see Appendix A.1.

3. Usually, the processor’s physical-address width is the value enumerated in CPUID.80000008H:EAX[7:0] (at most 52). If

IA32_TME_ACTIVATE[0] = 1 (indicating that TME has been configured), the width is reduced by the value of IA32_TME_ACTI-

VATE[39:36] when a logical processor is outside secure arbitration mode (SEAM; see Chapter 35); the value is not reduced in SEAM.

IA32_TME_ACTIVATE[39:36] is the number of physical-address bits reserved to encode TDX-private key identifiers. This number is

never greater than IA32_TME_ACTIVATE[35:32], which is the number physical-address bits used for key identifiers generally.

VMPTRLD-Load Pointer to Virtual-Machine Control Structure

33-17

Vol. 3C

VMX INSTRUCTION REFERENCE

FI;

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the memory source operand effective address is outside the CS, DS, ES, FS, or GS segment

limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the source operand is located in an execute-only code segment.

#PF(fault-code)

If a page fault occurs in accessing the memory source operand.

#SS(0)

If the memory source operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If operand is a register.

If not in VMX operation.

Real-Address Mode Exceptions

#UD

The VMPTRLD instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMPTRLD instruction is not recognized in virtual-8086 mode.

Compatibility Mode Exceptions

#UD

The VMPTRLD instruction is not recognized in compatibility mode.

64-Bit Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the source operand is in the CS, DS, ES, FS, or GS segments and the memory address is in

a non-canonical form.

#PF(fault-code)

If a page fault occurs in accessing the memory source operand.

#SS(0)

If the source operand is in the SS segment and the memory address is in a non-canonical

form.

#UD

If operand is a register.

If not in VMX operation.

33-18

Vol. 3C

VMPTRLD-Load Pointer to Virtual-Machine Control Structure

VMX INSTRUCTION REFERENCE

VMPTRST-Store Pointer to Virtual-Machine Control Structure

Opcode/

Op/En

Description

Instruction

NP 0F C7 /7

Stores the current VMCS pointer into memory.

VMPTRST m64

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ModRM:r/m (w)

Description

Stores the current-VMCS pointer into a specified memory address. The operand of this instruction is always 64 bits

and is always in memory.

Operation

IF (register operand) or (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSE

64-bit in-memory destination operand := current-VMCS pointer;

VMsucceed;

FI;

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the memory destination operand effective address is outside the CS, DS, ES, FS, or GS

segment limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the destination operand is located in a read-only data segment or any code segment.

#PF(fault-code)

If a page fault occurs in accessing the memory destination operand.

#SS(0)

If the memory destination operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If operand is a register.

If not in VMX operation.

Real-Address Mode Exceptions

#UD

The VMPTRST instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMPTRST instruction is not recognized in virtual-8086 mode.

VMPTRST-Store Pointer to Virtual-Machine Control Structure

33-19

Vol. 3C

VMX INSTRUCTION REFERENCE

VMREAD-Read Field from Virtual-Machine Control Structure

Opcode/

Op/En

Description

Instruction

NP 0F 78

Reads a specified VMCS field (in 64-bit mode).

VMREAD r/m64, r64

NP 0F 78

Reads a specified VMCS field (outside 64-bit mode).

VMREAD r/m32, r32

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ModRM:r/m (w)

ModRM:reg (r)

Description

Reads a specified field from a VMCS and stores it into a specified destination operand (register or memory). In VMX

root operation, the instruction reads from the current VMCS. If executed in VMX non-root operation, the instruction

reads from the VMCS referenced by the VMCS link pointer field in the current VMCS.

The VMCS field is specified by the VMCS-field encoding contained in the register source operand. Outside IA-32e

mode, the source operand has 32 bits, regardless of the value of CS.D. In 64-bit mode, the source operand has 64

bits.

The effective size of the destination operand, which may be a register or in memory, is always 32 bits outside IA-

32e mode (the setting of CS.D is ignored with respect to operand size) and 64 bits in 64-bit mode. If the VMCS field

specified by the source operand is shorter than this effective operand size, the high bits of the destination operand

are cleared to 0. If the VMCS field is longer, then the high bits of the field are not read.

Note that any faults resulting from accessing a memory destination operand can occur only after determining, in

the operation section below, that the relevant VMCS pointer is valid and that the specified VMCS field is supported.

Operation

IF (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation AND (“VMCS shadowing” is 0 OR source operand sets bits in range 63:15 OR

VMREAD bit corresponding to bits 14:0 of source operand is 1)¹

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSIF (in VMX root operation AND current-VMCS pointer is not valid) OR

(in VMX non-root operation AND VMCS link pointer is not valid)

THEN VMfailInvalid;

ELSIF source operand does not correspond to any VMCS field

THEN VMfailValid(VMREAD/VMWRITE from/to unsupported VMCS component);

ELSE

IF in VMX root operation

THEN destination operand := contents of field indexed by source operand in current VMCS;

ELSE destination operand := contents of field indexed by source operand in VMCS referenced by VMCS link pointer;

FI;

VMsucceed;

FI;

1. The VMREAD bit for a source operand is defined as follows. Let x be the value of bits 14:0 of the source operand and let addr be the

VMREAD-bitmap address. The corresponding VMREAD bit is in bit position x & 7 of the byte at physical address addr | (x » 3).

VMREAD-Read Field from Virtual-Machine Control Structure

33-21

Vol. 3C

VMX INSTRUCTION REFERENCE

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If a memory destination operand effective address is outside the CS, DS, ES, FS, or GS

segment limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the destination operand is located in a read-only data segment or any code segment.

#PF(fault-code)

If a page fault occurs in accessing a memory destination operand.

#SS(0)

If a memory destination operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If not in VMX operation.

Real-Address Mode Exceptions

#UD

The VMREAD instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMREAD instruction is not recognized in virtual-8086 mode.

Compatibility Mode Exceptions

#UD

The VMREAD instruction is not recognized in compatibility mode.

64-Bit Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the memory destination operand is in the CS, DS, ES, FS, or GS segments and the memory

address is in a non-canonical form.

#PF(fault-code)

If a page fault occurs in accessing a memory destination operand.

#SS(0)

If the memory destination operand is in the SS segment and the memory address is in a non-

canonical form.

#UD

If not in VMX operation.

33-22

Vol. 3C

VMREAD-Read Field from Virtual-Machine Control Structure

VMX INSTRUCTION REFERENCE

VMWRITE-Write Field to Virtual-Machine Control Structure

Opcode/

Op/En

Description

Instruction

NP 0F 79

Writes a specified VMCS field (in 64-bit mode).

VMWRITE r64, r/m64

NP 0F 79

Writes a specified VMCS field (outside 64-bit mode).

VMWRITE r32, r/m32

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ModRM:reg (r)

ModRM:r/m (r)

Description

Writes the contents of a primary source operand (register or memory) to a specified field in a VMCS. In VMX root

operation, the instruction writes to the current VMCS. If executed in VMX non-root operation, the instruction writes

to the VMCS referenced by the VMCS link pointer field in the current VMCS.

The VMCS field is specified by the VMCS-field encoding contained in the register secondary source operand.

Outside IA-32e mode, the secondary source operand is always 32 bits, regardless of the value of CS.D. In 64-bit

mode, the secondary source operand has 64 bits.

The effective size of the primary source operand, which may be a register or in memory, is always 32 bits outside

IA-32e mode (the setting of CS.D is ignored with respect to operand size) and 64 bits in 64-bit mode. If the VMCS

field specified by the secondary source operand is shorter than this effective operand size, the high bits of the

primary source operand are ignored. If the VMCS field is longer, then the high bits of the field are cleared to 0.

Note that any faults resulting from accessing a memory source operand occur after determining, in the operation

section below, that the relevant VMCS pointer is valid but before determining if the destination VMCS field is

supported.

Operation

IF (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation AND (“VMCS shadowing” is 0 OR secondary source operand sets bits in range 63:15 OR

VMWRITE bit corresponding to bits 14:0 of secondary source operand is 1)¹

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSIF (in VMX root operation AND current-VMCS pointer is not valid) OR

(in VMX non-root operation AND VMCS-link pointer is not valid)

THEN VMfailInvalid;

ELSIF secondary source operand does not correspond to any VMCS field

THEN VMfailValid(VMREAD/VMWRITE from/to unsupported VMCS component);

ELSIF VMCS field indexed by secondary source operand is a VM-exit information field AND

processor does not support writing to such fields²

THEN VMfailValid(VMWRITE to read-only VMCS component);

ELSE

1. The VMWRITE bit for a secondary source operand is defined as follows. Let x be the value of bits 14:0 of the secondary source oper-

and and let addr be the VMWRITE-bitmap address. The corresponding VMWRITE bit is in bit position x & 7 of the byte at physical

address addr | (x » 3).

2. Software can discover whether these fields can be written by reading the VMX capability MSR IA32_VMX_MISC (see Appendix A.6).

33-24

Vol. 3C

VMWRITE-Write Field to Virtual-Machine Control Structure

VMX INSTRUCTION REFERENCE

IF in VMX root operation

THEN field indexed by secondary source operand in current VMCS := primary source operand;

ELSE field indexed by secondary source operand in VMCS referenced by VMCS link pointer := primary source operand;

FI;

VMsucceed;

FI;

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If a memory source operand effective address is outside the CS, DS, ES, FS, or GS segment

limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the source operand is located in an execute-only code segment.

#PF(fault-code)

If a page fault occurs in accessing a memory source operand.

#SS(0)

If a memory source operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If not in VMX operation.

Real-Address Mode Exceptions

#UD

The VMWRITE instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMWRITE instruction is not recognized in virtual-8086 mode.

Compatibility Mode Exceptions

#UD

The VMWRITE instruction is not recognized in compatibility mode.

64-Bit Mode Exceptions

#GP(0)

If the current privilege level is not 0.

If the memory source operand is in the CS, DS, ES, FS, or GS segments and the memory

address is in a non-canonical form.

#PF(fault-code)

If a page fault occurs in accessing a memory source operand.

#SS(0)

If the memory source operand is in the SS segment and the memory address is in a non-

canonical form.

#UD

If not in VMX operation.

VMWRITE-Write Field to Virtual-Machine Control Structure

33-25

Vol. 3C

VMX INSTRUCTION REFERENCE

VMXOFF-Leave VMX Operation

Opcode/

Op/En

Description

Instruction

0F 01 C4

Leaves VMX operation.

VMXOFF

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

Description

Takes the logical processor out of VMX operation, unblocks INIT signals, conditionally re-enables A20M, and clears

any address-range monitoring.¹

Operation

IF (not in VMX operation) or (CR0.PE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF in VMX non-root operation

THEN VMexit;

ELSIF CPL > 0 or in SEAM root operation

THEN #GP(0);

ELSIF dual-monitor treatment of SMIs and SMM is active

THEN VMfail(VMXOFF under dual-monitor treatment of SMIs and SMM);

ELSE

leave VMX operation;

unblock INIT;

IF IA32_SMM_MONITOR_CTL[2] = 0²

THEN unblock SMIs;

IF outside SMX operation³

THEN unblock and enable A20M;

FI;

IF the processor supports SEAM

THEN ensure that data for each active SEAM VMCS is in the memory of the corresponding VMCS region;

FI;

clear address-range monitoring;

VMsucceed;

FI;

Flags Affected

See the operation section and Section 33.2.

1. See the information on MONITOR/MWAIT in Chapter 11, “Multiple-Processor Management,” of the Intel^®64 and IA-32 Architectures

Software Developer’s Manual, Volume 3A.

2. Setting IA32_SMM_MONITOR_CTL[bit 2] to 1 prevents VMXOFF from unblocking SMIs regardless of the value of the register’s value

bit (bit 0). Not all processors allow this bit to be set to 1. Software should consult the VMX capability MSR IA32_VMX_MISC (see

Appendix A.6) to determine whether this is allowed.

3. A logical processor is outside SMX operation if GETSEC[SENTER] has not been executed or if GETSEC[SEXIT] was executed after the

last execution of GETSEC[SENTER]. See Chapter 6, “Safer Mode Extensions Reference.”

33-26

Vol. 3C

VMXOFF-Leave VMX Operation

VMX INSTRUCTION REFERENCE

VMXON-Enter VMX Operation

Opcode/

Op/En

Description

Instruction

F3 0F C7 /6

Enter VMX root operation.

VMXON m64

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

ModRM:r/m (r)

Description

Puts the logical processor in VMX operation with no current VMCS, blocks INIT signals, disables A20M, and clears

any address-range monitoring established by the MONITOR instruction.¹

The operand of this instruction is a 4KB-aligned physical address (the VMXON pointer) that references the VMXON

region, which the logical processor may use to support VMX operation. This operand is always 64 bits and is always

in memory.

Operation

IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)

THEN #UD;

ELSIF not in VMX operation

THEN

IF (CPL > 0) or (in A20M mode) or

(the values of CR0 and CR4 are not supported in VMX operation; see Section 26.8) or

(bit 0 (lock bit) of IA32_FEATURE_CONTROL MSR is clear) or

(in SMX operation² and bit 1 of IA32_FEATURE_CONTROL MSR is clear) or

(outside SMX operation and bit 2 of IA32_FEATURE_CONTROL MSR is clear)

THEN #GP(0);

ELSE

addr := contents of 64-bit in-memory source operand;

IF addr is not 4KB-aligned or

addr sets any bits beyond the physical-address width^3,4

THEN VMfailInvalid;

ELSE

rev := 32 bits located at physical address addr;

IF rev[30:0] ≠ VMCS revision identifier supported by processor OR rev[31] = 1

THEN VMfailInvalid;

ELSE

1. See the information on MONITOR/MWAIT in Chapter 11, “Multiple-Processor Management,” of the Intel^®64 and IA-32 Architectures

Software Developer’s Manual, Volume 3A.

2. A logical processor is in SMX operation if GETSEC[SEXIT] has not been executed since the last execution of GETSEC[SENTER]. A logi-

cal processor is outside SMX operation if GETSEC[SENTER] has not been executed or if GETSEC[SEXIT] was executed after the last

execution of GETSEC[SENTER]. See Chapter 7, “Safer Mode Extensions Reference.”

3. If IA32_VMX_BASIC[48] is read as 1, VMfailInvalid occurs if addr sets any bits in the range 63:32; see Appendix A.1.

4. Usually, the processor’s physical-address width is the value enumerated in CPUID.80000008H:EAX[7:0] (at most 52). If IA32_T-

ME_ACTIVATE[0] = 1 (indicating that TME has been configured), the width is reduced by the value of IA32_TME_ACTIVATE[39:36].

IA32_TME_ACTIVATE[39:36] is the number of physical-address bits reserved to encode TDX-private key identifiers. This number is

never greater than IA32_TME_ACTIVATE[35:32], which is the number physical-address bits used for key identifiers generally.

33-28

Vol. 3C

VMXON-Enter VMX Operation

VMX INSTRUCTION REFERENCE

current-VMCS pointer := FFFFFFFF_FFFFFFFFH;

enter VMX operation;

block INIT signals;

block and disable A20M;

clear address-range monitoring;

IF the processor supports Intel PT but does not allow it to be used in VMX operation¹

THEN IA32_RTIT_CTL.TraceEn := 0;

FI;

VMsucceed;

FI;

ELSIF in VMX non-root operation

THEN VMexit;

ELSIF CPL > 0

THEN #GP(0);

ELSE VMfail(“VMXON executed in VMX root operation”);

FI;

Flags Affected

See the operation section and Section 33.2.

Protected Mode Exceptions

#GP(0)

If executed outside VMX operation with CPL>0 or with invalid CR0 or CR4 fixed bits.

If executed in A20M mode.

If the memory source operand effective address is outside the CS, DS, ES, FS, or GS segment

limit.

If the DS, ES, FS, or GS register contains an unusable segment.

If the source operand is located in an execute-only code segment.

If the value of the IA32_FEATURE_CONTROL MSR does not support entry to VMX operation in

the current processor mode.

#PF(fault-code)

If a page fault occurs in accessing the memory source operand.

#SS(0)

If the memory source operand effective address is outside the SS segment limit.

If the SS register contains an unusable segment.

#UD

If operand is a register.

If executed with CR4.VMXE = 0.

Real-Address Mode Exceptions

#UD

The VMXON instruction is not recognized in real-address mode.

Virtual-8086 Mode Exceptions

#UD

The VMXON instruction is not recognized in virtual-8086 mode.

Compatibility Mode Exceptions

#UD

The VMXON instruction is not recognized in compatibility mode.

1. Software should read the VMX capability MSR IA32_VMX_MISC to determine whether the processor allows Intel PT to be used in

VMX operation (see Appendix A.6).

VMXON-Enter VMX Operation

33-29

Vol. 3C

VMX INSTRUCTION REFERENCE

64-Bit Mode Exceptions

#GP(0)

If executed outside VMX operation with CPL > 0 or with invalid CR0 or CR4 fixed bits.

If executed in A20M mode.

If the source operand is in the CS, DS, ES, FS, or GS segments and the memory address is in

a non-canonical form.

If the value of the IA32_FEATURE_CONTROL MSR does not support entry to VMX operation in

the current processor mode.

#PF(fault-code)

If a page fault occurs in accessing the memory source operand.

#SS(0)

If the source operand is in the SS segment and the memory address is in a non-canonical

form.

#UD

If operand is a register.

If executed with CR4.VMXE = 0.

33.4

VM INSTRUCTION ERROR NUMBERS

For certain error conditions, the VM-instruction error field is loaded with an error number to indicate the source of

the error. Table 33-1 lists VM-instruction error numbers.

Table 33-1. VM-Instruction Error Numbers

Error

Description

Number

VMCALL executed in VMX root operation

VMCLEAR with invalid physical address

VMCLEAR with VMXON pointer

VMLAUNCH with non-clear VMCS

VMRESUME with non-launched VMCS

VMRESUME after VMXOFF (VMXOFF and VMXON between VMLAUNCH and VMRESUME)^a

VM entry with invalid control field(s)^b,c

VM entry with invalid host-state field(s)^b

VMPTRLD with invalid physical address

VMPTRLD with VMXON pointer

VMPTRLD with incorrect VMCS revision identifier

VMREAD/VMWRITE from/to unsupported VMCS component

VMWRITE to read-only VMCS component

VMXON executed in VMX root operation

VM entry with invalid executive-VMCS pointer^b

VM entry with non-launched executive VMCS^b

VM entry with executive-VMCS pointer not VMXON pointer (when attempting to deactivate the dual-monitor treatment of

SMIs and SMM)^b

VMCALL with non-clear VMCS (when attempting to activate the dual-monitor treatment of SMIs and SMM)

VMCALL with invalid VM-exit control fields

VMCALL with incorrect MSEG revision identifier (when attempting to activate the dual-monitor treatment of SMIs and SMM)

VMXOFF under dual-monitor treatment of SMIs and SMM

VMCALL with invalid SMM-monitor features (when attempting to activate the dual-monitor treatment of SMIs and SMM)

33-30

Vol. 3C

VMXON-Enter VMX Operation

VMX INSTRUCTION REFERENCE

Table 33-1. VM-Instruction Error Numbers (Contd.)

Error

Description

Number

VM entry with invalid VM-execution control fields in executive VMCS (when attempting to return from SMM)^b,c

VM entry with events blocked by MOV SS.

Invalid operand to INVEPT/INVVPID.

NOTES:

a. Earlier versions of this manual described this error as “VMRESUME with a corrupted VMCS”.

b. VM-entry checks on control fields and host-state fields may be performed in any order. Thus, an indication by error number of one

cause does not imply that there are not also other errors. Different processors may give different error numbers for the same VMCS.

c. Error number 7 is not used for VM entries that return from SMM that fail due to invalid VM-execution control fields in the executive

VMCS. Error number 25 is used for these cases.

VMXON-Enter VMX Operation

33-31

Vol. 3C

CHAPTER 34

SYSTEM MANAGEMENT MODE

This chapter describes aspects of IA-64 and IA-32 architecture used in system management mode (SMM).

SMM provides an alternate operating environment that can be used to monitor and manage various system

resources for more efficient energy usage, to control system hardware, and/or to run proprietary code. It was

introduced into the IA-32 architecture in the Intel386 SL processor (a mobile specialized version of the Intel386

processor). It is also available in the Pentium M, Pentium 4, Intel Xeon, P6 family, and Pentium and Intel486

processors (beginning with the enhanced versions of the Intel486 SL and Intel486 processors).

34.1

SYSTEM MANAGEMENT MODE OVERVIEW

SMM is a special-purpose operating mode provided for handling system-wide functions like power management,

system hardware control, or proprietary OEM-designed code. It is intended for use only by system firmware, not by

applications software or general-purpose systems software. The main benefit of SMM is that it offers a distinct and

easily isolated processor environment that operates transparently to the operating system or executive and soft-

ware applications.

When SMM is invoked through a system management interrupt (SMI), the processor saves the current state of the

processor (the processor’s context), then switches to a separate operating environment defined by a new address

space. The system management software executive (SMI handler) starts execution in that environment, and the

critical code and data of the SMI handler reside in a physical memory region (SMRAM) within that address space.

While in SMM, the processor executes SMI handler code to perform operations such as powering down unused disk

drives or monitors, executing proprietary code, or placing the whole system in a suspended state. When the SMI

handler has completed its operations, it executes a resume (RSM) instruction. This instruction causes the processor

to reload the saved context of the processor, switch back to protected or real mode, and resume executing the

interrupted application or operating-system program or task.

The following SMM mechanisms make it transparent to applications programs and operating systems:

• The only way to enter SMM is by means of an SMI.

• The processor executes SMM code in a separate address space that can be made inaccessible from the other

operating modes.

• Upon entering SMM, the processor saves the context of the interrupted program or task.

• All interrupts normally handled by the operating system are disabled upon entry into SMM.

• The RSM instruction can be executed only in SMM.

Section 34.3 describes transitions into and out of SMM. The execution environment after entering SMM is in real-

address mode with paging disabled (CR0.PE = CR0.PG = 0). In this initial execution environment, the SMI handler

can address up to 4 GBytes of memory and can execute all I/O and system instructions. Section 34.5 describes in

detail the initial SMM execution environment for an SMI handler and operation within that environment. The SMI

handler may subsequently switch to other operating modes while remaining in SMM.

NOTES

Software developers should be aware that, even if a logical processor was using the physical-

address extension (PAE) mechanism (introduced in the P6 family processors) or was in IA-32e

mode before an SMI, this will not be the case after the SMI is delivered. This is because delivery of

an SMI disables paging (see Table 34-4). (This does not apply if the dual-monitor treatment of SMIs

and SMM is active; see Section 34.15.)

Vol. 3C

34-1

SYSTEM MANAGEMENT MODE

34.1.1 System Management Mode and VMX Operation

Traditionally, SMM services system management interrupts and then resumes program execution (back to the soft-

ware stack consisting of executive and application software; see Section 34.2 through Section 34.13).

A virtual machine monitor (VMM) using VMX can act as a host to multiple virtual machines and each virtual machine

can support its own software stack of executive and application software. On processors that support VMX, virtual-

machine extensions may use system-management interrupts (SMIs) and system-management mode (SMM) in one

of two ways:

• Default treatment. System firmware handles SMIs. The processor saves architectural states and critical

states relevant to VMX operation upon entering SMM. When the firmware completes servicing SMIs, it uses

RSM to resume VMX operation.

• Dual-monitor treatment. Two VM monitors collaborate to control the servicing of SMIs: one VMM operates

outside of SMM to provide basic virtualization in support for guests; the other VMM operates inside SMM (while

in VMX operation) to support system-management functions. The former is referred to as executive monitor,

the latter SMM-transfer monitor (STM).¹

The default treatment is described in Section 34.14, “Default Treatment of SMIs and SMM with VMX Operation and

SMX Operation.” Dual-monitor treatment of SMM is described in Section 34.15, “Dual-Monitor Treatment of SMIs

and SMM.”

34.2

SYSTEM MANAGEMENT INTERRUPT (SMI)

The only way to enter SMM is by signaling an SMI through the SMI# pin on the processor or through an SMI

message received through the APIC bus. The SMI is a nonmaskable external interrupt that operates independently

from the processor’s interrupt- and exception-handling mechanism and the local APIC. The SMI takes precedence

over an NMI and a maskable interrupt. SMM is non-reentrant; that is, the SMI is disabled while the processor is in

SMM.

NOTES

In the Pentium 4, Intel Xeon, and P6 family processors, when a processor that is designated as an

application processor during an MP initialization sequence is waiting for a startup IPI (SIPI), it is in

a mode where SMIs are masked. However if a SMI is received while an application processor is in

the wait for SIPI mode, the SMI will be pended. The processor then responds on receipt of a SIPI by

immediately servicing the pended SMI and going into SMM before handling the SIPI.

An SMI may be blocked for one instruction following execution of STI, MOV to SS, or POP into SS.

34.3

SWITCHING BETWEEN SMM AND THE OTHER PROCESSOR OPERATING

MODES

Figure 2-3 shows how the processor moves between SMM and the other processor operating modes (protected,

real-address, and virtual-8086). Signaling an SMI while the processor is in real-address, protected, or virtual-8086

modes always causes the processor to switch to SMM. Upon execution of the RSM instruction, the processor always

returns to the mode it was in when the SMI occurred.

34.3.1 Entering SMM

The processor always handles an SMI on an architecturally defined “interruptible” point in program execution

(which is commonly at an IA-32 architecture instruction boundary). When the processor receives an SMI, it waits

for all instructions to retire and for all stores to complete. The processor then saves its current context in SMRAM

(see Section 34.4), enters SMM, and begins to execute the SMI handler.

1. The dual-monitor treatment may not be supported by all processors. Software should consult the VMX capability MSR IA32_VMX-

_BASIC (see Appendix A.1) to determine whether it is supported.

34-2

Vol. 3C

SYSTEM MANAGEMENT MODE

Upon entering SMM, the processor signals external hardware that SMI handling has begun. The signaling mecha-

nism used is implementation dependent. For the P6 family processors, an SMI acknowledge transaction is gener-

ated on the system bus and the multiplexed status signal EXF4 is asserted each time a bus transaction is generated

while the processor is in SMM. For the Pentium and Intel486 processors, the SMIACT# pin is asserted.

An SMI has a greater priority than debug exceptions and external interrupts. Thus, if an NMI, maskable hardware

interrupt, or a debug exception occurs at an instruction boundary along with an SMI, only the SMI is handled.

Subsequent SMI requests are not acknowledged while the processor is in SMM. The first SMI interrupt request that

occurs while the processor is in SMM (that is, after SMM has been acknowledged to external hardware) is latched

and serviced when the processor exits SMM with the RSM instruction. The processor will latch only one SMI while

in SMM.

See Section 34.5 for a detailed description of the execution environment when in SMM.

34.3.2 Exiting From SMM

The only way to exit SMM is to execute the RSM instruction. The RSM instruction is only available to the SMI

handler; if the processor is not in SMM, attempts to execute the RSM instruction result in an invalid-opcode excep-

tion (#UD) being generated.

The RSM instruction restores the processor’s context by loading the state save image from SMRAM back into the

processor’s registers. The processor then returns an SMIACK transaction on the system bus and returns program

control back to the interrupted program.

NOTES

On processors that support the shadow-stack feature, RSM loads the SSP register from the state

save image in SMRAM (see Table 34-3). The value is made canonical by sign-extension before

loading it into SSP.

On processors that support Intel^® SGX, RSM consults the “incident to enclave mode” bit in SMRAM

(see Table 34-3). If it is set, FRED event delivery of or a subsequent VM exit due to an event

pending following RSM will indicate that it was incident to enclave mode. See Section 8.3.2.1 and

Section 30.2.1 for details.

Upon successful completion of the RSM instruction, the processor signals external hardware that SMM has been

exited. For the P6 family processors, an SMI acknowledge transaction is generated on the system bus and the

multiplexed status signal EXF4 is no longer generated on bus cycles. For the Pentium and Intel486 processors, the

SMIACT# pin is deserted.

If the processor detects invalid state information saved in the SMRAM, it enters the shutdown state and generates

a special bus cycle to indicate it has entered shutdown state. Shutdown happens only in the following situations:

• A reserved bit in control register CR4 is set to 1 on a write to CR4. This error should not happen unless SMI

handler code modifies reserved areas of the SMRAM saved state map (see Section 34.4.1). CR4 is saved in the

state map in a reserved location and cannot be read or modified in its saved state.

• An illegal combination of bits is written to control register CR0, in particular PG set to 1 and PE set to 0, or NW

set to 1 and CD set to 0.

• CR4.PCIDE would be set to 1 and IA32_EFER.LMA to 0.

• (For the Pentium and Intel486 processors only.) If the address stored in the SMBASE register when an RSM

instruction is executed is not aligned on a 32-KByte boundary. This restriction does not apply to the P6 family

processors.

• CR4.CET would be set to 1 and CR0.WP to 0.

• CR4.FRED would be set to 1 and any of the following apply:

- IA32_EFER.LMA would be 0.

- CPL would be 1 or 2.

- CPL would be 0, and the logical processor would be in compatibility mode.

Vol. 3C

34-3

SYSTEM MANAGEMENT MODE

- CPL would be 3, and either IOPL would be non-zero.

In the shutdown state, Intel processors stop executing instructions until a RESET#, INIT# or NMI# is asserted.

While Pentium family processors recognize the SMI# signal in shutdown state, P6 family and Intel486 processors

do not. Intel does not support using SMI# to recover from shutdown states for any processor family; the response

of processors in this circumstance is not well defined. On Pentium 4 and later processors, shutdown will inhibit INTR

and A20M but will not change any of the other inhibits. On these processors, NMIs will be inhibited if no action is

taken in the SMI handler to uninhibit them (see Section 34.8).

If the processor is in the HALT state when the SMI is received, the processor handles the return from SMM slightly

differently (see Section 34.10). Also, the SMBASE address can be changed on a return from SMM (see Section

34.11).

34.4

SMRAM

Upon entering SMM, the processor switches to a new address space. Because paging is disabled upon entering

SMM, this initial address space maps all memory accesses to the low 4 GBytes of the processor's physical address

space. The SMI handler's critical code and data reside in a memory region referred to as system-management RAM

(SMRAM). The processor uses a pre-defined region within SMRAM to save the processor's pre-SMI context. SMRAM

can also be used to store system management information (such as the system configuration and specific informa-

tion about powered-down devices) and OEM-specific information.

The default SMRAM size is 64 KBytes beginning at a base physical address in physical memory called the SMBASE

(see Figure 34-1). The SMBASE default value following a hardware reset is 30000H. The processor looks for the

first instruction of the SMI handler at the address [SMBASE + 8000H]. It stores the processor’s state in the area

from [SMBASE + FE00H] to [SMBASE + FFFFH]. See Section 34.4.1 for a description of the mapping of the state

save area.

The system logic is minimally required to decode the physical address range for the SMRAM from [SMBASE +

8000H] to [SMBASE + FFFFH]. A larger area can be decoded if needed. The size of this SMRAM can be between 32

KBytes and 4 GBytes.

The location of the SMRAM can be changed by changing the SMBASE value (see Section 34.11). It should be noted

that all processors in a multiple-processor system are initialized with the same SMBASE value (30000H). Initializa-

tion software must sequentially place each processor in SMM and change its SMBASE so that it does not overlap

those of other processors.

The actual physical location of the SMRAM can be in system memory or in a separate RAM memory. The processor

generates an SMI acknowledge transaction (P6 family processors) or asserts the SMIACT# pin (Pentium and

Intel486 processors) when the processor receives an SMI (see Section 34.3.1).

System logic can use the SMI acknowledge transaction or the assertion of the SMIACT# pin to decode accesses to

the SMRAM and redirect them (if desired) to specific SMRAM memory. If a separate RAM memory is used for

SMRAM, system logic should provide a programmable method of mapping the SMRAM into system memory space

when the processor is not in SMM. This mechanism will enable start-up procedures to initialize the SMRAM space

(that is, load the SMI handler) before executing the SMI handler during SMM.

34.4.1 SMRAM State Save Map

When an IA-32 processor that does not support Intel 64 architecture initially enters SMM, it writes its state to the

state save area of the SMRAM. The state save area begins at [SMBASE + 8000H + 7FFFH] and extends down to

[SMBASE + 8000H + 7E00H]. Table 34-1 shows the state save map. The offset in column 1 is relative to the

SMBASE value plus 8000H. Reserved spaces should not be used by software.

Some of the registers in the SMRAM state save area (marked YES in column 3) may be read and changed by the

SMI handler, with the changed values restored to the processor registers by the RSM instruction. Some register

images are read-only, and must not be modified (modifying these registers will result in unpredictable behavior).

An SMI handler should not rely on any values stored in an area that is marked as reserved.

34-4

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 34-1. SMRAM State Save Map (Contd.)

Offset

Writable?

(Added to SMBASE + 8000H)

7F00H

I/O Instruction Restart Field (Word)

Yes

7EFCH

SMM Revision Identifier Field (Doubleword)

7EF8H

SMBASE Field (Doubleword)

Yes

7EF7H - 7E00H

Reserved

NOTE:

1. The two most significant bytes are reserved.

The following registers are saved (but not readable) and restored upon exiting SMM:

• Control register CR4. (This register is cleared to all 0s when entering SMM).

• The hidden segment descriptor information stored in segment registers CS, DS, ES, FS, GS, and SS.

If an SMI request is issued for the purpose of powering down the processor, the values of all reserved locations in

the SMM state save must be saved to nonvolatile memory.

The following state is not automatically saved and restored following an SMI and the RSM instruction, respectively:

• Debug registers DR0 through DR3.

• The x87 FPU registers.

• The MTRRs.

• Control register CR2.

• The model-specific registers (for the P6 family and Pentium processors) or test registers TR3 through TR7 (for

the Pentium and Intel486 processors).

• The state of the trap controller.

• The machine-check architecture registers.

• The APIC internal interrupt state (ISR, IRR, etc.).

• The microcode update state.

If an SMI is used to power down the processor, a power-on reset will be required before returning to SMM, which

will reset much of this state back to its default values. So an SMI handler that is going to trigger power down should

first read these registers listed above directly, and save them (along with the rest of RAM) to nonvolatile storage.

After the power-on reset, the continuation of the SMI handler should restore these values, along with the rest of

the system's state. Anytime the SMI handler changes these registers in the processor, it must also save and restore

them.

NOTES

A small subset of the MSRs (such as, the time-stamp counter and performance-monitoring

counters) are not arbitrarily writable and therefore cannot be saved and restored. SMM-based

power-down and restoration should only be performed with operating systems that do not use or

rely on the values of these registers.

Operating system developers should be aware of this fact and ensure that their operating-system

assisted power-down and restoration software is immune to unexpected changes in these register

values.

34.4.1.1 SMRAM State Save Map and Intel 64 Architecture

When the processor initially enters SMM, it writes its state to the state save area of the SMRAM. The state save area

on an Intel 64 processor at [SMBASE + 8000H + 7FFFH] and extends to [SMBASE + 8000H + 7C00H].

Support for Intel 64 architecture is reported by CPUID.80000001:EDX[29] = 1. The layout of the SMRAM state save

map is shown in Table 34-3.

34-6

Vol. 3C

SYSTEM MANAGEMENT MODE

Additionally, the SMRAM state save map shown in Table 34-3 also applies to processors with the following CPUID

signatures listed in Table 34-2, irrespective of the value in CPUID.80000001H:EDX[29].

Table 34-2. Processor Signatures and 64-bit SMRAM State Save Map Format

DisplayFamily_DisplayModel

Processor Families/Processor Number Series

06_17H

Intel Xeon Processor 5200, 5400 series, Intel Core 2 Quad processor Q9xxx, Intel Core 2 Duo

processors E8000, T9000,

06_0FH

Intel Xeon Processor 3000, 3200, 5100, 5300, 7300 series, Intel Core 2 Quad, Intel Core 2 Extreme,

Intel Core 2 Duo processors, Intel Pentium dual-core processors

06_1CH

45 nm Intel Atom® processors

Table 34-3. SMRAM State Save Map for Intel 64 Architecture

Offset

Writable?

(Added to SMBASE + 8000H)

7FF8H

CR0

7FF0H

CR3

7FE8H

RFLAGS

Yes

7FE0H

IA32_EFER

Yes

7FD8H

RIP

Yes

7FD0H

DR6

7FC8H

DR7

7FC4H

TR SEL¹

7FC0H

LDTR SEL¹

7FBCH

GS SEL¹

7FB8H

FS SEL¹

7FB4H

DS SEL¹

7FB0H

SS SEL¹

7FACH

CS SEL¹

7FA8H

ES SEL¹

7FA4H

IO_MISC

7F9CH

IO_MEM_ADDR

7F94H

RDI

Yes

7F8CH

RSI

Yes

7F84H

RBP

Yes

7F7CH

RSP

Yes

7F74H

RBX

Yes

7F6CH

RDX

Yes

7F64H

RCX

Yes

7F5CH

RAX

Yes

7F54H

Yes

7F4CH

Yes

Vol. 3C

34-7

SYSTEM MANAGEMENT MODE

Table 34-3. SMRAM State Save Map for Intel 64 Architecture (Contd.)

Offset

Writable?

(Added to SMBASE + 8000H)

7F44H

R10

Yes

7F3CH

R11

Yes

7F34H

R12

Yes

7F2CH

R13

Yes

7F24H

R14

Yes

7F1CH

R15

Yes

7F1BH-7F04H

Reserved

7F02H

Auto HALT Restart Field (Word)

Yes

7F00H

I/O Instruction Restart Field (Word)

Yes

7EFCH

SMM Revision Identifier Field (Doubleword)

7EF8H

SMBASE Field (Doubleword)

Yes

7EF7H - 7EE4H

Reserved

Bit 0 is set if the SMI was incident to VMX non-root operation and the “enable

7EE0H

EPT” VM-execution control was 1.

Bit 1 is set if the SMI was incident to enclave mode.

7ED8H

Value of EPTP VM-execution control field

7ED7H - 7ECC0H

Reserved

7EC8H

SSP

Yes

7EC7H - 7EA0H

Reserved

7E9CH

LDT Base (lower 32 bits)

7E98H

Reserved

7E94H

IDT Base (lower 32 bits)

7E90H

Reserved

7E8CH

GDT Base (lower 32 bits)

7E8BH - 7E48H

Reserved

7E40H

CR4 (64 bits)

7E3FH - 7DF0H

Reserved

7DE8H

IO_RIP

Yes

7DE7H - 7DDCH

Reserved

7DD8H

IDT Base (Upper 32 bits)

7DD4H

LDT Base (Upper 32 bits)

7DD0H

GDT Base (Upper 32 bits)

7DCFH - 7C00H

Reserved

NOTE:

1. The two most significant bytes are reserved.

34.4.2 SMRAM Caching

An IA-32 processor does not automatically write back and invalidate its caches before entering SMM or before

exiting SMM. Because of this behavior, care must be taken in the placement of the SMRAM in system memory and

34-8

Vol. 3C

SYSTEM MANAGEMENT MODE

in the caching of the SMRAM to prevent cache incoherence when switching back and forth between SMM and

protected mode operation. Any of the following three methods of locating the SMRAM in system memory will guar-

antee cache coherency.

• Place the SMRAM in a dedicated section of system memory that the operating system and applications are

prevented from accessing. Here, the SMRAM can be designated as cacheable (WB, WT, or WC) for optimum

processor performance, without risking cache incoherence when entering or exiting SMM.

• Place the SMRAM in a section of memory that overlaps an area used by the operating system (such as the video

memory), but designate the SMRAM as uncacheable (UC). This method prevents cache access when in SMM to

maintain cache coherency, but the use of uncacheable memory reduces the performance of SMM code.

• Place the SMRAM in a section of system memory that overlaps an area used by the operating system and/or

application code, but explicitly flush (write back and invalidate) the caches upon entering and exiting SMM

mode. This method maintains cache coherency, but incurs the overhead of two complete cache flushes.

For Pentium 4, Intel Xeon, and P6 family processors, a combination of the first two methods of locating the SMRAM

is recommended. Here the SMRAM is split between an overlapping and a dedicated region of memory. Upon

entering SMM, the SMRAM space that is accessed overlaps video memory (typically located in low memory). This

SMRAM section is designated as UC memory. The initial SMM code then jumps to a second SMRAM section that is

located in a dedicated region of system memory (typically in high memory). This SMRAM section can be cached for

optimum processor performance.

For systems that explicitly flush the caches upon entering SMM (the third method described above), the cache flush

can be accomplished by asserting the FLUSH# pin at the same time as the request to enter SMM (generally initi-

ated by asserting the SMI# pin). The priorities of the FLUSH# and SMI# pins are such that the FLUSH# is serviced

first. To guarantee this behavior, the processor requires that the following constraints on the interaction of FLUSH#

and SMI# be met. In a system where the FLUSH# and SMI# pins are synchronous and the set up and hold times

are met, then the FLUSH# and SMI# pins may be asserted in the same clock. In asynchronous systems, the

FLUSH# pin must be asserted at least one clock before the SMI# pin to guarantee that the FLUSH# pin is serviced

first.

Upon leaving SMM (for systems that explicitly flush the caches), the WBINVD instruction should be executed prior

to leaving SMM to flush the caches.

NOTES

In systems based on the Pentium processor that use the FLUSH# pin to write back and invalidate

cache contents before entering SMM, the processor will prefetch at least one cache line in between

when the Flush Acknowledge cycle is run and the subsequent recognition of SMI# and the assertion

of SMIACT#.

It is the obligation of the system to ensure that these lines are not cached by returning KEN#

inactive to the Pentium processor.

34.4.2.1 System Management Range Registers (SMRR)

SMI handler code and data stored by SMM code resides in SMRAM. The SMRR interface is an enhancement in Intel

64 architecture to limit cacheable reference of addresses in SMRAM to code running in SMM. The SMRR interface

can be configured only by code running in SMM. Details of SMRR is described in Section 14.11.2.4.

34.5

SMI HANDLER EXECUTION ENVIRONMENT

Section 34.5.1 describes the initial execution environment for an SMI handler. An SMI handler may re-configure its

execution environment to other supported operating modes. Section 34.5.2 discusses modifications an SMI

handler can make to its execution environment. Section 34.5.3 discusses Control-flow Enforcement Technology

(CET) interactions in the environment.

Vol. 3C

34-9

SYSTEM MANAGEMENT MODE

34.5.1 Initial SMM Execution Environment

After saving the current context of the processor, the processor initializes its core registers to the values shown in

Table 34-4. Upon entering SMM, the PE and PG flags in control register CR0 are cleared, which places the processor

in an environment similar to real-address mode. The differences between the SMM execution environment and the

real-address mode execution environment are as follows:

• The addressable address space ranges from 0 to FFFFFFFFH (4 GBytes).

• The normal 64-KByte segment limit for real-address mode is increased to 4 GBytes.

• The default operand and address sizes are set to 16 bits, which restricts the addressable SMRAM address space

to the 1-MByte real-address mode limit for native real-address-mode code. However, operand-size and

address-size override prefixes can be used to access the address space beyond the 1-MByte.

Table 34-4. Processor Register Initialization in SMM

Contents

General-purpose registers

Undefined

EFLAGS

00000002H

EIP

00008000H

CS selector

SMM Base shifted right 4 bits (default 3000H)

CS base

SMM Base (default 30000H)

DS, ES, FS, GS, SS Selectors

0000H

DS, ES, FS, GS, SS Bases

000000000H

DS, ES, FS, GS, SS Limits

0FFFFFFFFH

CR0

PE, EM, TS, and PG flags set to 0; others unmodified

CR4

Cleared to zero

DR6

Undefined

DR7

00000400H

• Near jumps and calls can be made to anywhere in the 4-GByte address space if a 32-bit operand-size override

prefix is used. Due to the real-address-mode style of base-address formation, a far call or jump cannot transfer

control to a segment with a base address of more than 20 bits (1 MByte). However, since the segment limit in

SMM is 4 GBytes, offsets into a segment that go beyond the 1-MByte limit are allowed when using 32-bit

operand-size override prefixes. Any program control transfer that does not have a 32-bit operand-size override

prefix truncates the EIP value to the 16 low-order bits.

• Data and the stack can be located anywhere in the 4-GByte address space, but can be accessed only with a 32-

bit address-size override if they are located above 1 MByte. As with the code segment, the base address for a

data or stack segment cannot be more than 20 bits.

The value in segment register CS is automatically set to the default of 30000H for the SMBASE shifted 4 bits to the

right; that is, 3000H. The EIP register is set to 8000H. When the EIP value is added to shifted CS value (the

SMBASE), the resulting linear address points to the first instruction of the SMI handler.

The other segment registers (DS, SS, ES, FS, and GS) are cleared to 0 and their segment limits are set to 4 GBytes.

In this state, the SMRAM address space may be treated as a single flat 4-GByte linear address space. If a segment

(hidden part of the segment register). The limits and attributes are not modified.

Maskable hardware interrupts, exceptions, NMI interrupts, SMI interrupts, A20M interrupts, single-step traps,

breakpoint traps, and INIT operations are inhibited when the processor enters SMM. Maskable hardware interrupts,

exceptions, single-step traps, and breakpoint traps can be enabled in SMM if the SMM execution environment

provides and initializes an interrupt table and the necessary interrupt and exception handlers (see Section 34.6).

34-10

Vol. 3C

SYSTEM MANAGEMENT MODE

34.5.2 SMI Handler Operating Mode Switching

Within SMM, an SMI handler may change the processor's operating mode (e.g., to enable PAE paging, enter 64-bit

mode, etc.) after it has made proper preparation and initialization to do so. For example, if switching to 32-bit

protected mode, the SMI handler should follow the guidelines provided in Chapter 12, “Processor Management and

Initialization.” If the SMI handler does wish to change operating mode, it is responsible for executing the appro-

priate mode-transition code after each SMI.

It is recommended that the SMI handler make use of all means available to protect the integrity of its critical code

and data. In particular, it should use the system-management range register (SMRR) interface if it is available (see

Section 11.11.2.4). The SMRR interface can protect only the first 4 GBytes of the physical address space. The SMI

handler should take that fact into account if it uses operating modes that allow access to physical addresses beyond

that 4-GByte limit (e.g., PAE paging or 64-bit mode).

Execution of the RSM instruction restores the pre-SMI processor state from the SMRAM state-state map (see

Section 34.4.1) into which it was stored when the processor entered SMM. (The SMBASE field in the SMRAM state-

save map does not determine the state following RSM but rather the initial environment following the next entry to

SMM.) Any required change to operating mode is performed by the RSM instruction; there is no need for the SMI

handler to change modes explicitly prior to executing RSM.

34.5.3 Control-flow Enforcement Technology Interactions

On processors that support CET shadow stacks, when the processor enters SMM, the processor saves the SSP

ronment of the SMI handler has CET disabled and all of the CET state of the interrupted program is still in the

machine. An SMM that uses CET is required to save the interrupted program’s CET state and restore the CET state

prior to exiting SMM.

34.6

EXCEPTIONS AND INTERRUPTS WITHIN SMM

When the processor enters SMM, all hardware interrupts are disabled in the following manner:

• The IF flag in the EFLAGS register is cleared, which inhibits maskable hardware interrupts from being

generated.

• The TF flag in the EFLAGS register is cleared, which disables single-step traps.

• Debug register DR7 is cleared, which disables breakpoint traps. (This action prevents a debugger from acciden-

tally breaking into an SMI handler if a debug breakpoint is set in normal address space that overlays code or

data in SMRAM.)

• NMI, SMI, and A20M interrupts are blocked by internal SMM logic. (See Section 34.8 for more information

about how NMIs are handled in SMM.)

Software-invoked interrupts and exceptions can still occur, and maskable hardware interrupts can be enabled by

setting the IF flag. Intel recommends that SMM code be written in so that it does not invoke software interrupts

(with the INT n, INTO, INT1, INT3, or BOUND instructions) or generate exceptions.

If the SMI handler requires interrupt and exception handling, an SMM interrupt table and the necessary exception

and interrupt handlers must be created and initialized from within SMM. Until the interrupt table is correctly initial-

ized (using the LIDT instruction), exceptions and software interrupts will result in unpredictable processor

behavior.

The following restrictions apply when designing SMM interrupt and exception-handling facilities:

• The interrupt table should be located at linear address 0 and must contain real-address mode style interrupt

vectors (4 bytes containing CS and IP).

• Due to the real-address mode style of base address formation, an interrupt or exception cannot transfer control

to a segment with a base address of more that 20 bits.

• An interrupt or exception cannot transfer control to a segment offset of more than 16 bits (64 KBytes).

Vol. 3C

34-11

SYSTEM MANAGEMENT MODE

• When an exception or interrupt occurs, only the 16 least-significant bits of the return address (EIP) are pushed

onto the stack. If the offset of the interrupted procedure is greater than 64 KBytes, it is not possible for the

interrupt/exception handler to return control to that procedure. (One solution to this problem is for a handler to

adjust the return address on the stack.)

• The SMBASE relocation feature affects the way the processor will return from an interrupt or exception

generated while the SMI handler is executing. For example, if the SMBASE is relocated to above 1 MByte, but

the exception handlers are below 1 MByte, a normal return to the SMI handler is not possible. One solution is

to provide the exception handler with a mechanism for calculating a return address above 1 MByte from the 16-

bit return address on the stack, then use a 32-bit far call to return to the interrupted procedure.

• If an SMI handler needs access to the debug trap facilities, it must ensure that an SMM accessible debug

handler is available and save the current contents of debug registers DR0 through DR3 (for later restoration).

Debug registers DR0 through DR3 and DR7 must then be initialized with the appropriate values.

• If an SMI handler needs access to the single-step mechanism, it must ensure that an SMM accessible single-

step handler is available, and then set the TF flag in the EFLAGS register.

• If the SMI design requires the processor to respond to maskable hardware interrupts or software-generated

interrupts while in SMM, it must ensure that SMM accessible interrupt handlers are available and then set the

IF flag in the EFLAGS register (using the STI instruction). Software interrupts are not blocked upon entry to

SMM, so they do not need to be enabled.

34.7

MANAGING SYNCHRONOUS AND ASYNCHRONOUS SYSTEM MANAGEMENT

INTERRUPTS

When coding for a multiprocessor system or a system with Intel HT Technology, it was not always possible for an

SMI handler to distinguish between a synchronous SMI (triggered during an I/O instruction) and an asynchronous

SMI. To facilitate the discrimination of these two events, incremental state information has been added to the SMM

state save map.

Processors that have an SMM revision ID of 30004H or higher have the incremental state information described

below.

34.7.1 I/O State Implementation

Within the extended SMM state save map, a bit (IO_SMI) is provided that is set only when an SMI is either taken

immediately after a successful I/O instruction or is taken after a successful iteration of a REP I/O instruction (the

successful notion pertains to the processor point of view; not necessarily to the corresponding platform function).

When set, the IO_SMI bit provides a strong indication that the corresponding SMI was synchronous. In this case,

the SMM State Save Map also supplies the port address of the I/O operation. The IO_SMI bit and the I/O Port

Address may be used in conjunction with the information logged by the platform to confirm that the SMI was

indeed synchronous.

The IO_SMI bit by itself is a strong indication, not a guarantee, that the SMI is synchronous. This is because an

asynchronous SMI might coincidentally be taken after an I/O instruction. In such a case, the IO_SMI bit would still

be set in the SMM state save map.

Information characterizing the I/O instruction is saved in two locations in the SMM State Save Map (Table 34-5).

The IO_SMI bit also serves as a valid bit for the rest of the I/O information fields. The contents of these I/O infor-

mation fields are not defined when the IO_SMI bit is not set.

Table 34-5. I/O Instruction Information in the SMM State Save Map

State (SMM Rev. ID: 30004H or higher)

Format

34-12

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 34-5. I/O Instruction Information in the SMM State Save Map

I/0 State Field

SMRAM offset 7FA4

I/O Memory Address Field

I/O Memory Address

SMRAM offset 7FA0

When IO_SMI is set, the other fields may be interpreted as follows:

• I/O length:

•

001 - Byte

•

010 - Word

•

100 - Dword

• I/O instruction type (Table 34-6)

Table 34-6. I/O Instruction Type Encodings

Instruction

Encoding

IN Immediate

1001

IN DX

0001

OUT Immediate

1000

OUT DX

0000

INS

0011

OUTS

0010

REP INS

0111

REP OUTS

0110

34.8

NMI HANDLING WHILE IN SMM

NMI interrupts are blocked upon entry to the SMI handler. If an NMI request occurs during the SMI handler, it is

latched and serviced after the processor exits SMM. Only one NMI request will be latched during the SMI handler.

If an NMI request is pending when the processor executes the RSM instruction, the NMI is serviced before the next

instruction of the interrupted code sequence. This assumes that NMIs were not blocked before the SMI occurred. If

NMIs were blocked before the SMI occurred, they are blocked after execution of RSM.

Although NMI requests are blocked when the processor enters SMM, they may be enabled through software by

executing an IRET instruction. If the SMI handler requires the use of NMI interrupts, it should invoke a dummy

interrupt service routine for the purpose of executing an IRET instruction. Once an IRET instruction is executed,

NMI interrupt requests are serviced in the same “real mode” manner in which they are handled outside of SMM.

Also, for the Pentium processor, exceptions that invoke a trap or fault handler will enable NMI interrupts from inside

of SMM. This behavior is implementation specific for the Pentium processor and is not part of the IA-32 architec-

ture.

34.9

SMM REVISION IDENTIFIER

The SMM revision identifier field is used to indicate the version of SMM and the SMM extensions that are supported

by the processor (see Figure 34-2). The SMM revision identifier is written during SMM entry and can be examined

in SMRAM space at offset 7EFCH. The lower word of the SMM revision identifier refers to the version of the base

SMM architecture.

Vol. 3C

34-13

SYSTEM MANAGEMENT MODE

7EFCH

18 17 16 15

Reserved

SMM Revision Identifier

SMBASE Relocation

I/O Instruction Restart

Figure 34-2. SMM Revision Identifier

The upper word of the SMM revision identifier refers to the extensions available. If the I/O instruction restart flag

(bit 16) is set, the processor supports the I/O instruction restart (see Section 34.12); if the SMBASE relocation flag

(bit 17) is set, SMRAM base address relocation is supported (see Section 34.11).

34.10 AUTO HALT RESTART

If the processor is in a HALT state (due to the prior execution of a HLT instruction) when it receives an SMI, the

processor records the fact in the auto HALT restart flag in the saved processor state (see Figure 34-3). (This flag is

located at offset 7F02H and bit 0 in the state save area of the SMRAM.)

If the processor sets the auto HALT restart flag upon entering SMM (indicating that the SMI occurred when the

processor was in the HALT state), the SMI handler has two options:

• It can leave the auto HALT restart flag set, which instructs the RSM instruction to return program control to the

HLT instruction. This option in effect causes the processor to re-enter the HALT state after handling the SMI.

(This is the default operation.)

• It can clear the auto HALT restart flag, which instructs the RSM instruction to return program control to the

instruction following the HLT instruction.

Reserved

7F02H

Auto HALT Restart

Figure 34-3. Auto HALT Restart Field

These options are summarized in Table 34-7. If the processor was not in a HALT state when the SMI was received

(the auto HALT restart flag is cleared), setting the flag to 1 will cause unpredictable behavior when the RSM instruc-

tion is executed.

Table 34-7. Auto HALT Restart Flag Values

Value of Flag After

Value of Flag When

Action of Processor When Exiting SMM

Entry to SMM

Exiting SMM

Returns to next instruction in interrupted program or task.

Unpredictable.

Returns to next instruction after HLT instruction.

Returns to HALT state.

If the HLT instruction is restarted, the processor will generate a memory access to fetch the HLT instruction (if it is

34-14

Vol. 3C

SYSTEM MANAGEMENT MODE

not in the internal cache), and execute a HLT bus transaction. This behavior results in multiple HLT bus transactions

for the same HLT instruction.

34.10.1 Executing the HLT Instruction in SMM

The HLT instruction should not be executed during SMM, unless interrupts have been enabled by setting the IF flag

in the EFLAGS register. If the processor is halted in SMM, the only event that can remove the processor from this

state is a maskable hardware interrupt or a hardware reset.

34.11 SMBASE RELOCATION

The default base address for the SMRAM is 30000H. This value is contained in an internal processor register called

the SMBASE register. Software can relocate the SMRAM by setting the SMBASE field in the saved state map (at

offset 7EF8H) to a new value (see Figure 34-4). The RSM instruction reloads the internal SMBASE register with the

value in the SMBASE field each time it exits SMM. All subsequent SMI requests will use the new SMBASE value to

find the starting address for the SMI handler (at SMBASE + 8000H) and the SMRAM state save area (from SMBASE

+ FE00H to SMBASE + FFFFH). (The processor resets the value in its internal SMBASE register to 30000H on a

RESET, but does not change it on an INIT.)

SMM Base

7EF8H

Figure 34-4. SMBASE Relocation Field

In multiple-processor systems, initialization software must adjust the SMBASE value for each processor so that the

SMRAM state save areas for each processor do not overlap. (For Pentium and Intel486 processors, the SMBASE

values must be aligned on a 32-KByte boundary or the processor will enter shutdown state during the execution of

a RSM instruction.)

If the SMBASE relocation flag in the SMM revision identifier field is set, it indicates the ability to relocate the

SMBASE (see Section 34.9).

34.12 I/O INSTRUCTION RESTART

If the I/O instruction restart flag in the SMM revision identifier field is set (see Section 34.9), the I/O instruction

restart mechanism is present on the processor. This mechanism allows an interrupted I/O instruction to be re-

executed upon returning from SMM mode. For example, if an I/O instruction is used to access a powered-down I/O

device, a chipset supporting this device can intercept the access and respond by asserting SMI#. This action

invokes the SMI handler to power-up the device. Upon returning from the SMI handler, the I/O instruction restart

mechanism can be used to re-execute the I/O instruction that caused the SMI.

The I/O instruction restart field (at offset 7F00H in the SMM state-save area, see Figure 34-5) controls I/O instruc-

tion restart. When an RSM instruction is executed, if this field contains the value FFH, then the EIP register is modi-

fied to point to the I/O instruction that received the SMI request. The processor will then automatically re-execute

the I/O instruction that the SMI trapped. (The processor saves the necessary machine state to ensure that re-

execution of the instruction is handled coherently.)

Vol. 3C

34-15

SYSTEM MANAGEMENT MODE

I/O Instruction Restart Field

7F00H

Figure 34-5. I/O Instruction Restart Field

If the I/O instruction restart field contains the value 00H when the RSM instruction is executed, then the processor

begins program execution with the instruction following the I/O instruction. (When a repeat prefix is being used,

the next instruction may be the next I/O instruction in the repeat loop.) Not re-executing the interrupted I/O

instruction is the default behavior; the processor automatically initializes the I/O instruction restart field to 00H

upon entering SMM. Table 34-8 summarizes the states of the I/O instruction restart field.

Table 34-8. I/O Instruction Restart Field Values

Value of Flag After

Value of Flag When

Action of Processor When Exiting SMM

Entry to SMM

Exiting SMM

00H

Does not re-execute trapped I/O instruction.

00H

FFH

Re-executes trapped I/O instruction.

The I/O instruction restart mechanism does not indicate the cause of the SMI. It is the responsibility of the SMI

handler to examine the state of the processor to determine the cause of the SMI and to determine if an I/O instruc-

tion was interrupted and should be restarted upon exiting SMM. If an SMI interrupt is signaled on a non-I/O instruc-

tion boundary, setting the I/O instruction restart field to FFH prior to executing the RSM instruction will likely result

in a program error.

34.12.1 Back-to-Back SMI Interrupts When I/O Instruction Restart Is Being Used

If an SMI interrupt is signaled while the processor is servicing an SMI interrupt that occurred on an I/O instruction

boundary, the processor will service the new SMI request before restarting the originally interrupted I/O instruc-

tion. If the I/O instruction restart field is set to FFH prior to returning from the second SMI handler, the EIP will point

to an address different from the originally interrupted I/O instruction, which will likely lead to a program error. To

avoid this situation, the SMI handler must be able to recognize the occurrence of back-to-back SMI interrupts when

I/O instruction restart is being used and ensure that the handler sets the I/O instruction restart field to 00H prior

to returning from the second invocation of the SMI handler.

34.13 SMM MULTIPLE-PROCESSOR CONSIDERATIONS

The following should be noted when designing multiple-processor systems:

• Any processor in a multiprocessor system can respond to an SMI.

• Each processor needs its own SMRAM space. This space can be in system memory or in a separate RAM.

• The SMRAMs for different processors can be overlapped in the same memory space. The only stipulation is that

each processor needs its own state save area and its own dynamic data storage area. (Also, for the Pentium

and Intel486 processors, the SMBASE address must be located on a 32-KByte boundary.) Code and static data

can be shared among processors. Overlapping SMRAM spaces can be done more efficiently with the P6 family

processors because they do not require that the SMBASE address be on a 32-KByte boundary.

• The SMI handler will need to initialize the SMBASE for each processor.

• Processors can respond to local SMIs through their SMI# pins or to SMIs received through the APIC interface.

The APIC interface can distribute SMIs to different processors.

• Two or more processors can be executing in SMM at the same time.

34-16

Vol. 3C

SYSTEM MANAGEMENT MODE

• When operating Pentium processors in dual processing (DP) mode, the SMIACT# pin is driven only by the MRM

processor and should be sampled with ADS#. For additional details, see Chapter 14 of the Pentium Processor

Family User’s Manual, Volume 1.

SMM is not re-entrant, because the SMRAM State Save Map is fixed relative to the SMBASE. If there is a need to

support two or more processors in SMM mode at the same time then each processor should have dedicated SMRAM

spaces. This can be done by using the SMBASE Relocation feature (see Section 34.11).

34.14 DEFAULT TREATMENT OF SMIS AND SMM WITH VMX OPERATION AND

SMX OPERATION

Under the default treatment, the interactions of SMIs and SMM with VMX operation are few. This section details

those interactions. It also explains how this treatment affects SMX operation.

34.14.1 Default Treatment of SMI Delivery

Ordinary SMI delivery saves processor state into SMRAM and then loads state based on architectural definitions.

Under the default treatment, processors that support VMX operation perform SMI delivery as follows:

enter SMM;

save the following internal to the processor:

CR4.VMXE

an indication of whether the logical processor was in VMX operation (root or non-root)

IF the logical processor is in VMX operation

THEN

save current VMCS pointer internal to the processor;

leave VMX operation;

save VMX-critical state defined below;

FI;

IF the logical processor supports SMX operation

THEN

save internal to the logical processor an indication of whether the Intel® TXT private space is locked;

IF the TXT private space is unlocked

THEN lock the TXT private space;

FI;

CR4.VMXE := 0;

perform ordinary SMI delivery:

save processor state in SMRAM;

set processor state to standard SMM values;¹

invalidate linear mappings and combined mappings associated with VPID 0000H (for all PCIDs); combined mappings for VPID 0000H

are invalidated for all EPTRTA values (EPTRTA is the value of bits 51:12 of EPTP; see Section 31.4);

The pseudocode above makes reference to the saving of VMX-critical state. This state consists of the following:

(1) SS.DPL (the current privilege level); (2) RFLAGS.VM²; (3) the state of blocking by STI and by MOV SS (see

Table 27-3 in Section 27.4.2); (4) the state of virtual-NMI blocking (only if the processor is in VMX non-root oper-

ation and the “virtual NMIs” VM-execution control is 1); and (5) an indication of whether an MTF VM exit is pending

(see Section 28.5.2). These data may be saved internal to the processor or in the VMCS region of the current

1. This causes the logical processor to block INIT signals, NMIs, and SMIs.

2. Section 34.14 and Section 34.15 use the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that

support VMX operation also support Intel 64 architecture. For processors that do not support Intel 64 architecture, this notation

refers to the 32-bit forms of these registers (EAX, EIP, ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer spe-

cifically to the lower 32 bits of the register.

Vol. 3C

34-17

SYSTEM MANAGEMENT MODE

VMCS. Processors that do not support SMI recognition while there is blocking by STI or by MOV SS need not save

the state of such blocking.

If the logical processor supports the 1-setting of the “enable EPT” VM-execution control and the logical processor

was in VMX non-root operation at the time of an SMI, it saves the value of that control into bit 0 of the 32-bit field

at offset SMBASE + 8000H + 7EE0H (SMBASE + FEE0H; see Table 34-3).¹ If the logical processor was not in VMX

non-root operation at the time of the SMI, it saves 0 into that bit. If the logical processor saves 1 into that bit (it

was in VMX non-root operation and the “enable EPT” VM-execution control was 1), it saves the value of the EPT

pointer (EPTP) into the 64-bit field at offset SMBASE + 8000H + 7ED8H (SMBASE + FED8H).

Because SMI delivery causes a logical processor to leave VMX operation, all the controls associated with VMX non-

root operation are disabled in SMM and thus cannot cause VM exits while the logical processor in SMM.

34.14.2 Default Treatment of RSM

Ordinary execution of RSM restores processor state from SMRAM. Under the default treatment, processors that

support VMX operation perform RSM as follows:

IF VMXE = 1 in CR4 image in SMRAM

THEN fail and enter shutdown state;

ELSE

restore state normally from SMRAM;

invalidate linear mappings and combined mappings associated with all VPIDs and all PCIDs; combined mappings are invalidated

for all EPTRTA values (EPTRTA is the value of bits 51:12 of EPTP; see Section 31.4);

IF the logical processor supports SMX operation andthe Intel® TXT private space was unlocked at the time of the last SMI (as

saved)

THEN unlock the TXT private space;

FI;

CR4.VMXE := value stored internally;

IF internal storage indicates that the logical processor

had been in VMX operation (root or non-root)

THEN

enter VMX operation (root or non-root);

restore VMX-critical state as defined in Section 34.14.1;

set to their fixed values any bits in CR0 and CR4 whose values must be fixed in VMX operation (see Section 26.8);²

IF RFLAGS.VM = 0 AND (in VMX root operation OR the “unrestricted guest” VM-execution control is 0)³

THEN

CS.RPL := SS.DPL;

SS.RPL := SS.DPL;

FI;

restore current VMCS pointer;

FI;

leave SMM;

IF logical processor will be in VMX operation or in SMX operation after RSM

THEN block A20M and leave A20M mode;

FI;

1. “Enable EPT” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution controls

is 0, SMI functions as the “enable EPT” VM-execution control were 0. See Section 27.6.2.

2. If the RSM is to VMX non-root operation and both the “unrestricted guest” VM-execution control and bit 31 of the primary proces-

sor-based VM-execution controls will be 1, CR0.PE and CR0.PG retain the values that were loaded from SMRAM regardless of what is

reported in the capability MSR IA32_VMX_CR0_FIXED0.

3. “Unrestricted guest” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execution

controls is 0, VM entry functions as if the “unrestricted guest” VM-execution control were 0. See Section 27.6.2.

34-18

Vol. 3C

SYSTEM MANAGEMENT MODE

RSM unblocks SMIs. It restores the state of blocking by NMI (see Table 27-3 in Section 27.4.2) as follows:

• If the RSM is not to VMX non-root operation or if the “virtual NMIs” VM-execution control will be 0, the state of

NMI blocking is restored normally.

• If the RSM is to VMX non-root operation and the “virtual NMIs” VM-execution control will be 1, NMIs are not

blocked after RSM. The state of virtual-NMI blocking is restored as part of VMX-critical state.

INIT signals are blocked after RSM if and only if the logical processor will be in VMX root operation.

If RSM returns a logical processor to VMX non-root operation, it re-establishes the controls associated with the

current VMCS. If the “interrupt-window exiting” VM-execution control is 1, a VM exit occurs immediately after RSM

if the enabling conditions apply. The same is true for the “NMI-window exiting” VM-execution control. Such

VM exits occur with their normal priority. See Section 28.2.

If an MTF VM exit was pending at the time of the previous SMI, an MTF VM exit is pending on the instruction

boundary following execution of RSM. The following items detail the treatment of MTF VM exits that may be

pending following RSM:

• System-management interrupts (SMIs), INIT signals, and higher priority events take priority over these MTF

VM exits. These MTF VM exits take priority over debug-trap exceptions and lower priority events.

• These MTF VM exits wake the logical processor if RSM caused the logical processor to enter the HLT state (see

Section 34.10). They do not occur if the logical processor just entered the shutdown state.

34.14.3 Protection of CR4.VMXE in SMM

Under the default treatment, CR4.VMXE is treated as a reserved bit while a logical processor is in SMM. Any

attempt by software running in SMM to set this bit causes a general-protection exception. In addition, software

cannot use VMX instructions or enter VMX operation while in SMM.

34.14.4 VMXOFF and SMI Unblocking

The VMXOFF instruction can be executed only with the default treatment (see Section 34.15.1) and only outside

SMM. If SMIs are blocked when VMXOFF is executed, VMXOFF unblocks them unless

IA32_SMM_MONITOR_CTL[bit 2] is 1 (see Section 34.15.5 for details regarding this MSR).¹ Section 34.15.7 iden-

tifies a case in which SMIs may be blocked when VMXOFF is executed.

Not all processors allow this bit to be set to 1. Software should consult the VMX capability MSR IA32_VMX_MISC

(see Appendix A.6) to determine whether this is allowed.

34.15 DUAL-MONITOR TREATMENT OF SMIs AND SMM

Dual-monitor treatment is activated through the cooperation of the executive monitor (the VMM that operates

outside of SMM to provide basic virtualization) and the SMM-transfer monitor (STM; the VMM that operates

inside SMM-while in VMX operation-to support system-management functions). Control is transferred to the STM

through VM exits; VM entries are used to return from SMM.

The dual-monitor treatment may not be supported by all processors. Software should consult the VMX capability

MSR IA32_VMX_BASIC (see Appendix A.1) to determine whether it is supported.

34.15.1 Dual-Monitor Treatment Overview

The dual-monitor treatment uses an executive monitor and an SMM-transfer monitor (STM). Transitions from the

executive monitor or its guests to the STM are called SMM VM exits and are discussed in Section 34.15.2. SMM

1. Setting IA32_SMM_MONITOR_CTL[bit 2] to 1 prevents VMXOFF from unblocking SMIs regardless of the value of the register’s valid

bit (bit 0).

Vol. 3C

34-19

SYSTEM MANAGEMENT MODE

VM exits are caused by SMIs as well as executions of VMCALL in VMX root operation. The latter allow the executive

monitor to call the STM for service.

The STM runs in VMX root operation and uses VMX instructions to establish a VMCS and perform VM entries to its

own guests. This is done all inside SMM (see Section 34.15.3). The STM returns from SMM, not by using the RSM

instruction, but by using a VM entry that returns from SMM. Such VM entries are described in Section 34.15.4.

Initially, there is no STM and the default treatment (Section 34.14) is used. The dual-monitor treatment is not used

until it is enabled and activated. The steps to do this are described in Section 34.15.5 and Section 34.15.6.

It is not possible to leave VMX operation under the dual-monitor treatment; VMXOFF will fail if executed. The dual-

monitor treatment must be deactivated first. The STM deactivates dual-monitor treatment using a VM entry that

returns from SMM with the “deactivate dual-monitor treatment” VM-entry control set to 1 (see Section 34.15.7).

The executive monitor configures any VMCS that it uses for VM exits to the executive monitor. SMM VM exits, which

transfer control to the STM, use a different VMCS. Under the dual-monitor treatment, each logical processor uses

a separate VMCS called the SMM-transfer VMCS. When the dual-monitor treatment is active, the logical

processor maintains another VMCS pointer called the SMM-transfer VMCS pointer. The SMM-transfer VMCS

pointer is established when the dual-monitor treatment is activated.

34.15.2 SMM VM Exits

An SMM VM exit is a VM exit that begins outside SMM and that ends in SMM.

Unlike other VM exits, SMM VM exits can begin in VMX root operation. SMM VM exits result from the arrival of an

SMI outside SMM or from execution of VMCALL in VMX root operation outside SMM. Execution of VMCALL in VMX

root operation causes an SMM VM exit only if the valid bit is set in the IA32_SMM_MONITOR_CTL MSR (see Section

34.15.5).

Execution of VMCALL in VMX root operation causes an SMM VM exit even under the default treatment. This SMM

VM exit activates the dual-monitor treatment (see Section 34.15.6).

Differences between SMM VM exits and other VM exits are detailed in Sections 34.15.2.1 through 34.15.2.5.

Differences between SMM VM exits that activate the dual-monitor treatment and other SMM VM exits are described

in Section 34.15.6.

34.15.2.1 Architectural State Before a VM Exit

System-management interrupts (SMIs) that cause SMM VM exits always do so directly. They do not save state to

SMRAM as they do under the default treatment.

34.15.2.2 Updating the Current-VMCS and Executive-VMCS Pointers

SMM VM exits begin by performing the following steps:

1. The executive-VMCS pointer field in the SMM-transfer VMCS is loaded as follows:

- If the SMM VM exit commenced in VMX non-root operation, it receives the current-VMCS pointer.

- If the SMM VM exit commenced in VMX root operation, it receives the VMXON pointer.

2. The current-VMCS pointer is loaded with the value of the SMM-transfer VMCS pointer.

The last step ensures that the current VMCS is the SMM-transfer VMCS. VM-exit information is recorded in that

VMCS, and VM-entry control fields in that VMCS are updated. State is saved into the guest-state area of that VMCS.

The VM-exit controls and host-state area of that VMCS determine how the VM exit operates.

34.15.2.3 Recording VM-Exit Information

SMM VM exits differ from other VM exit with regard to the way they record VM-exit information. The differences

follow.

• Exit reason.

34-20

Vol. 3C

SYSTEM MANAGEMENT MODE

- Bits 15:0 of this field contain the basic exit reason. The field is loaded with the reason for the SMM VM exit:

I/O SMI (an SMI arrived immediately after retirement of an I/O instruction), other SMI, or VMCALL. See

Appendix C, “VMX Basic Exit Reasons.”

- SMM VM exits are the only VM exits that may occur in VMX root operation. Because the SMM-transfer

monitor may need to know whether it was invoked from VMX root or VMX non-root operation, this

information is stored in bit 29 of the exit-reason field (see Table 27-19 in Section 27.9.1). The bit is set by

SMM VM exits from VMX root operation.

- If the SMM VM exit occurred in VMX non-root operation and an MTF VM exit was pending, bit 28 of the exit-

reason field is set; otherwise, it is cleared.

- Bits 27:16 and bits 31:30 are cleared.

• Exit qualification. For an SMM VM exit due an SMI that arrives immediately after the retirement of an I/O

instruction, the exit qualification contains information about the I/O instruction that retired immediately before

the SMI. It has the format given in Table 34-9.

Table 34-9. Exit Qualification for SMIs That Arrive Immediately After the Retirement of an I/O Instruction

Bit Position(s)

Contents

2:0

Size of access:

0 = 1-byte

1 = 2-byte

3 = 4-byte

Other values not used.

Direction of the attempted access (0 = OUT, 1 = IN)

String instruction (0 = not string; 1 = string)

REP prefixed (0 = not REP; 1 = REP)

Operand encoding (0 = DX, 1 = immediate)

15:7

Reserved (cleared to 0)

31:16

Port number (as specified in the I/O instruction)

63:32

Reserved (cleared to 0). These bits exist only on processors

that support Intel 64 architecture.

• Guest linear address. This field is used for VM exits due to SMIs that arrive immediately after the retirement

of an INS or OUTS instruction for which the relevant segment (ES for INS; DS for OUTS unless overridden by

an instruction prefix) is usable. The field receives the value of the linear address generated by ES:(E)DI (for

INS) or segment:(E)SI (for OUTS; the default segment is DS but can be overridden by a segment override

prefix) at the time the instruction started. If the relevant segment is not usable, the value is undefined. On

processors that support Intel 64 architecture, bits 63:32 are clear if the logical processor was not in 64-bit

mode before the VM exit.

• I/O RCX, I/O RSI, I/O RDI, and I/O RIP. For an SMM VM exit due an SMI that arrives immediately after

the retirement of an I/O instruction, these fields receive the values that were in RCX, RSI, RDI, and RIP, respec-

tively, before the I/O instruction executed. Thus, the value saved for I/O RIP addresses the I/O instruction.

34.15.2.4 Saving Guest State

SMM VM exits save the contents of the SMBASE register into the corresponding field in the guest-state area.

The value of the VMX-preemption timer is saved into the corresponding field in the guest-state area if the “save

VMX-preemption timer value” VM-exit control is 1. That field becomes undefined if, in addition, either the SMM

VM exit is from VMX root operation or the SMM VM exit is from VMX non-root operation and the “activate VMX-

preemption timer” VM-execution control is 0.

Vol. 3C

34-21

SYSTEM MANAGEMENT MODE

34.15.2.5 Updating State

If an SMM VM exit is from VMX non-root operation and the “Intel PT uses guest physical addresses” VM-execution

control is 1, the IA32_RTIT_CTL MSR is cleared to 00000000_00000000H.¹ This is done even if the “clear IA32_R-

TIT_CTL” VM-exit control is 0.

SMM VM exits affect the non-register state of a logical processor as follows:

• SMM VM exits cause non-maskable interrupts (NMIs) to be blocked; they may be unblocked through execution

of IRET or through a VM entry (depending on the value loaded for the interruptibility state and the setting of the

“virtual NMIs” VM-execution control).

• SMM VM exits cause SMIs to be blocked; they may be unblocked by a VM entry that returns from SMM (see

Section 34.15.4).

SMM VM exits invalidate linear mappings and combined mappings associated with VPID 0000H for all PCIDs.

Combined mappings for VPID 0000H are invalidated for all EPTRTA values (EPTRTA is the value of bits 51:12 of

EPTP; see Section 31.4). (Ordinary VM exits are not required to perform such invalidation if the “enable VPID” VM-

execution control is 1; see Section 30.5.5.)

34.15.3 Operation of the SMM-Transfer Monitor

Once invoked, the SMM-transfer monitor (STM) is in VMX root operation and can use VMX instructions to configure

VMCSs and to cause VM entries to virtual machines supported by those structures. As noted in Section 34.15.1, the

VMXOFF instruction cannot be used under the dual-monitor treatment and thus cannot be used by the STM.

The RSM instruction also cannot be used under the dual-monitor treatment. As noted in Section 28.1.3, it causes a

VM exit if executed in SMM in VMX non-root operation. If executed in VMX root operation, it causes an invalid-

opcode exception. The STM uses VM entries to return from SMM (see Section 34.15.4).

34.15.4 VM Entries that Return from SMM

The SMM-transfer monitor (STM) returns from SMM using a VM entry with the “entry to SMM” VM-entry control

clear. VM entries that return from SMM reverse the effects of an SMM VM exit (see Section 34.15.2).

VM entries that return from SMM may differ from other VM entries in that they do not necessarily enter VMX non-

root operation. If the executive-VMCS pointer field in the current VMCS contains the VMXON pointer, the logical

processor remains in VMX root operation after VM entry.

For differences between VM entries that return from SMM and other VM entries see Sections 34.15.4.1 through

34.15.4.10.

34.15.4.1 Checks on the Executive-VMCS Pointer Field

VM entries that return from SMM perform the following checks on the executive-VMCS pointer field in the current

VMCS:

• Bits 11:0 must be 0.

• The pointer must not set any bits beyond the processor’s physical-address width.^2,3

1. In this situation, the value of this MSR was saved earlier into the guest-state area. All VM exits save this MSR if the 1-setting of the

“load IA32_RTIT_CTL” VM-entry control is supported (see Section 30.3.1), which must be the case if the “Intel PT uses guest physi-

cal addresses” VM-execution control is 1 (see Section 29.2.1.1).

2. Usually, the processor’s physical-address width is the value enumerated in CPUID.80000008H:EAX[7:0] (at most 52). If

IA32_TME_ACTIVATE[0] = 1 (indicating that TME has been configured), the width is reduced by the value of IA32_TME_ACTI-

VATE[39:36]. IA32_TME_ACTIVATE[39:36] is the number of physical-address bits reserved to encode TDX-private key identifiers.

This number is never greater than IA32_TME_ACTIVATE[35:32], which is the number physical-address bits used for key identifiers

generally.

3. If IA32_VMX_BASIC[48] is read as 1, this pointer must not set any bits in the range 63:32; see Appendix A.1.

34-22

Vol. 3C

SYSTEM MANAGEMENT MODE

• The 32 bits located in memory referenced by the physical address in the pointer must contain the processor’s

VMCS revision identifier (see Section 27.2).

The checks above are performed before the checks described in Section 34.15.4.2 and before any of the following

checks:

• 'If the “deactivate dual-monitor treatment” VM-entry control is 0 and the executive-VMCS pointer field does not

contain the VMXON pointer, the launch state of the executive VMCS (the VMCS referenced by the executive-

VMCS pointer field) must be launched (see Section 27.11.3).

• If the “deactivate dual-monitor treatment” VM-entry control is 1, the executive-VMCS pointer field must

contain the VMXON pointer (see Section 34.15.7).¹

34.15.4.2 Checks on VM-Execution Control Fields

VM entries that return from SMM differ from other VM entries with regard to the checks performed on the VM-

execution control fields specified in Section 29.2.1.1. They do not apply the checks to the current VMCS. Instead,

VM-entry behavior depends on whether the executive-VMCS pointer field contains the VMXON pointer:

• If the executive-VMCS pointer field contains the VMXON pointer (the VM entry remains in VMX root operation),

the checks are not performed at all.

• If the executive-VMCS pointer field does not contain the VMXON pointer (the VM entry enters VMX non-root

operation), the checks are performed on the VM-execution control fields in the executive VMCS (the VMCS

referenced by the executive-VMCS pointer field in the current VMCS). These checks are performed after

checking the executive-VMCS pointer field itself (for proper alignment).

Other VM entries ensure that, if “activate VMX-preemption timer” VM-execution control is 0, the “save VMX-

preemption timer value” VM-exit control is also 0. This check is not performed by VM entries that return from SMM.

34.15.4.3 Checks on VM-Entry Control Fields

VM entries that return from SMM differ from other VM entries with regard to the checks performed on the VM-entry

control fields specified in Section 29.2.1.3.

Specifically, if the executive-VMCS pointer field contains the VMXON pointer (the VM entry remains in VMX root

operation), the injected-event identification field must not indicate injection of a pending MTF VM exit (see Section

29.6.2). Specifically, the following cannot all be true for that field:

• the valid bit (bit 31) is 1

• the event type (bits 10:8) is 7 (other event); and

• the vector (bits 7:0) is 0 (pending MTF VM exit).

34.15.4.4 Checks on the Guest State Area

Section 29.3.1 specifies checks performed on fields in the guest-state area of the VMCS. Some of these checks are

conditioned on the settings of certain VM-execution controls (e.g., “virtual NMIs” or “unrestricted guest”).

VM entries that return from SMM modify these checks based on whether the executive-VMCS pointer field contains

the VMXON pointer:²

• If the executive-VMCS pointer field contains the VMXON pointer (the VM entry remains in VMX root operation),

the checks are performed as all relevant VM-execution controls were 0. (As a result, some checks may not be

performed at all.)

• If the executive-VMCS pointer field does not contain the VMXON pointer (the VM entry enters VMX non-root

operation), this check is performed based on the settings of the VM-execution controls in the executive VMCS

(the VMCS referenced by the executive-VMCS pointer field in the current VMCS).

1. The STM can determine the VMXON pointer by reading the executive-VMCS pointer field in the current VMCS after the SMM VM exit

that activates the dual-monitor treatment.

2. The STM can determine the VMXON pointer by reading the executive-VMCS pointer field in the current VMCS after the SMM VM exit

that activates the dual-monitor treatment.

Vol. 3C

34-23

SYSTEM MANAGEMENT MODE

For VM entries that return from SMM, the activity-state field must not indicate the wait-for-SIPI state if the execu-

tive-VMCS pointer field contains the VMXON pointer (the VM entry is to VMX root operation).

34.15.4.5 Loading Guest State

VM entries that return from SMM load the SMBASE register from the SMBASE field.

VM entries that return from SMM invalidate linear mappings and combined mappings associated with all VPIDs.

Combined mappings are invalidated for all EPTRTA values (EPTRTA is the value of bits 51:12 of EPTP; see Section

31.4). (Ordinary VM entries are required to perform such invalidation only for VPID 0000H and are not required to

do even that if the “enable VPID” VM-execution control is 1; see Section 29.3.2.5.)

34.15.4.6 VMX-Preemption Timer

A VM entry that returns from SMM activates the VMX-preemption timer only if the executive-VMCS pointer field

does not contain the VMXON pointer (the VM entry enters VMX non-root operation) and the “activate VMX-preemp-

tion timer” VM-execution control is 1 in the executive VMCS (the VMCS referenced by the executive-VMCS pointer

field). In this case, VM entry starts the VMX-preemption timer with the value in the VMX-preemption timer-value

field in the current VMCS.

34.15.4.7 Updating the Current-VMCS and SMM-Transfer VMCS Pointers

Successful VM entries (returning from SMM) load the SMM-transfer VMCS pointer with the current-VMCS pointer.

Following this, they load the current-VMCS pointer from a field in the current VMCS:

• If the executive-VMCS pointer field contains the VMXON pointer (the VM entry remains in VMX root operation),

the current-VMCS pointer is loaded from the VMCS-link pointer field.

• If the executive-VMCS pointer field does not contain the VMXON pointer (the VM entry enters VMX non-root

operation), the current-VMCS pointer is loaded with the value of the executive-VMCS pointer field.

If the VM entry successfully enters VMX non-root operation, the VM-execution controls in effect after the VM entry

are those from the new current VMCS. This includes any structures external to the VMCS referenced by VM-execu-

tion control fields.

The updating of these VMCS pointers occurs before event injection. Event injection is determined, however, by the

VM-entry control fields in the VMCS that was current when the VM entry commenced.

34.15.4.8 VM Exits Induced by VM Entry

Section 29.6.1.2 describes how the event-delivery process invoked by event injection may lead to a VM exit.

Section 29.7.3 to Section 29.7.7 describe other situations that may cause a VM exit to occur immediately after a

VM entry.

Whether these VM exits occur is determined by the VM-execution control fields in the current VMCS. For VM entries

that return from SMM, they can occur only if the executive-VMCS pointer field does not contain the VMXON pointer

(the VM entry enters VMX non-root operation).

In this case, determination is based on the VM-execution control fields in the VMCS that is current after the

VM entry. This is the VMCS referenced by the value of the executive-VMCS pointer field at the time of the VM entry

(see Section 34.15.4.7). This VMCS also controls the delivery of such VM exits. Thus, VM exits induced by a

VM entry returning from SMM are to the executive monitor and not to the STM.

34.15.4.9 SMI Blocking

VM entries that return from SMM determine the blocking of system-management interrupts (SMIs) as follows:

• If the “deactivate dual-monitor treatment” VM-entry control is 0, SMIs are blocked after VM entry if and only if

the bit 2 in the interruptibility-state field is 1.

• If the “deactivate dual-monitor treatment” VM-entry control is 1, the blocking of SMIs depends on whether the

logical processor is in SMX operation:¹

- If the logical processor is in SMX operation, SMIs are blocked after VM entry.

34-24

Vol. 3C

SYSTEM MANAGEMENT MODE

- If the logical processor is outside SMX operation, SMIs are unblocked after VM entry.

VM entries that return from SMM and that do not deactivate the dual-monitor treatment may leave SMIs blocked.

This feature exists to allow the STM to invoke functionality outside of SMM without unblocking SMIs.

34.15.4.10 Failures of VM Entries That Return from SMM

Section 29.8 describes the treatment of VM entries that fail during or after loading guest state. Such failures record

information in the VM-exit information fields and load processor state as would be done on a VM exit. The VMCS

used is the one that was current before the VM entry commenced. Control is thus transferred to the STM and the

logical processor remains in SMM.

34.15.5 Enabling the Dual-Monitor Treatment

Code and data for the SMM-transfer monitor (STM) reside in a region of SMRAM called the monitor segment

(MSEG). Code running in SMM determines the location of MSEG and establishes its content. This code is also

responsible for enabling the dual-monitor treatment.

SMM code enables the dual-monitor treatment and specifies the location of MSEG by writing to the IA32_SMM_-

MONITOR_CTL MSR (index 9BH). The MSR has the following format:

• Bit 0 is the register’s valid bit. The STM may be invoked using VMCALL only if this bit is 1. Because VMCALL is

used to activate the dual-monitor treatment (see Section 34.15.6), the dual-monitor treatment cannot be

activated if the bit is 0. This bit is cleared when the logical processor is reset.

• Bit 1 is reserved.

• Bit 2 determines whether executions of VMXOFF unblock SMIs under the default treatment of SMIs and SMM.

Executions of VMXOFF unblock SMIs unless bit 2 is 1 (the value of bit 0 is irrelevant). See Section 34.14.4.

Certain leaf functions of the GETSEC instruction clear this bit (see Chapter 7, “Safer Mode Extensions

Reference,” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2D).

• Bits 11:3 are reserved.

• Bits 31:12 contain a value that, when shifted left 12 bits, is the physical address of MSEG (the MSEG base

address).

• Bits 63:32 are reserved.

The following items detail use of this MSR:

• The IA32_SMM_MONITOR_CTL MSR is supported only on processors that support the dual-monitor treatment.¹

On other processors, accesses to the MSR using RDMSR or WRMSR generate a general-protection fault

(#GP(0)).

• A write to the IA32_SMM_MONITOR_CTL MSR using WRMSR generates a general-protection fault (#GP(0)) if

executed outside of SMM or if an attempt is made to set any reserved bit. An attempt to write to the IA32_SM-

M_MONITOR_CTL MSR fails if made as part of a VM exit that does not end in SMM or part of a VM entry that

does not begin in SMM.

• Reads from the IA32_SMM_MONITOR_CTL MSR using RDMSR are allowed any time RDMSR is allowed. The

MSR may be read as part of any VM exit.

• The dual-monitor treatment can be activated only if the valid bit in the MSR is set to 1.

1. A logical processor is in SMX operation if GETSEC[SEXIT] has not been executed since the last execution of GETSEC[SENTER]. A logi-

cal processor is outside SMX operation if GETSEC[SENTER] has not been executed or if GETSEC[SEXIT] was executed after the last

execution of GETSEC[SENTER]. See Chapter 7, “Safer Mode Extensions Reference‚” in the Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 2D.

1. Software should consult the VMX capability MSR IA32_VMX_BASIC (see Appendix A.1) to determine whether the dual-monitor

treatment is supported.

Vol. 3C

34-25

SYSTEM MANAGEMENT MODE

The 32 bytes located at the MSEG base address are called the MSEG header. The format of the MSEG header is

given in Table 34-10 (each field is 32 bits).

Table 34-10. Format of MSEG Header

Byte Offset

Field

MSEG-header revision identifier

SMM-transfer monitor features

GDTR limit

GDTR base offset

CS selector

EIP offset

ESP offset

CR3 offset

To ensure proper behavior in VMX operation, software should maintain the MSEG header in writeback cacheable

memory. Future implementations may allow or require a different memory type.¹ Software should consult the VMX

capability MSR IA32_VMX_BASIC (see Appendix A.1).

SMM code should enable the dual-monitor treatment (by setting the valid bit in IA32_SMM_MONITOR_CTL MSR)

only after establishing the content of the MSEG header as follows:

• Bytes 3:0 contain the MSEG revision identifier. Different processors may use different MSEG revision identi-

fiers. These identifiers enable software to avoid using an MSEG header formatted for one processor on a

processor that uses a different format. Software can discover the MSEG revision identifier that a processor uses

by reading the VMX capability MSR IA32_VMX_MISC (see Appendix A.6).

• Bytes 7:4 contain the SMM-transfer monitor features field. Bits 31:1 of this field are reserved and must be

zero. Bit 0 of the field is the IA-32e mode SMM feature bit. It indicates whether the logical processor will be

in IA-32e mode after the STM is activated (see Section 34.15.6).

• Bytes 31:8 contain fields that determine how processor state is loaded when the STM is activated (see Section

34.15.6.5). SMM code should establish these fields so that activating of the STM invokes the STM’s initialization

code.

34.15.6 Activating the Dual-Monitor Treatment

The dual-monitor treatment may be enabled by SMM code as described in Section 34.15.5. The dual-monitor treat-

ment is activated only if it is enabled and only by the executive monitor. The executive monitor activates the dual-

monitor treatment by executing VMCALL in VMX root operation.

When VMCALL activates the dual-monitor treatment, it causes an SMM VM exit. Differences between this SMM

VM exit and other SMM VM exits are discussed in Sections 34.15.6.1 through 34.15.6.6. See also “VMCALL-Call to

VM Monitor” in Chapter 33.

34.15.6.1 Initial Checks

An execution of VMCALL attempts to activate the dual-monitor treatment if (1) the processor supports the dual-

monitor treatment;² (2) the logical processor is in VMX root operation; (3) the logical processor is outside SMM and

1. Alternatively, software may map the MSEG header with the UC memory type; this may be necessary, depending on how memory is

organized. Doing so is strongly discouraged unless necessary as it will cause the performance of transitions using those structures

to suffer significantly. In addition, the processor will continue to use the memory type reported in the VMX capability MSR

IA32_VMX_BASIC with exceptions noted in Appendix A.1.

34-26

Vol. 3C

SYSTEM MANAGEMENT MODE

the valid bit is set in the IA32_SMM_MONITOR_CTL MSR; (4) the logical processor is not in virtual-8086 mode and

not in compatibility mode; (5) CPL = 0; and (6) the dual-monitor treatment is not active.

Such an execution of VMCALL begins with some initial checks. These checks are performed before updating the

current-VMCS pointer and the executive-VMCS pointer field (see Section 34.15.2.2).

The VMCS that manages SMM VM exit caused by this VMCALL is the current VMCS established by the executive

monitor. The VMCALL performs the following checks on the current VMCS in the order indicated:

1. There must be a current VMCS pointer.

2. The launch state of the current VMCS must be clear.

3. The VM-exit controls in the current VMCS must be set properly:

• Reserved bits in the primary VM-exit controls must be set properly. Software may consult the VMX

capability MSRs to determine the proper setting (see Appendix A.4.1).

• If the “activate secondary controls” primary VM-exit control is 1, reserved bits in the secondary VM-exit

controls must be cleared. Software may consult the VMX capability MSRs to determine which bits are

reserved (see Appendix A.4.2).

• If the “activate secondary controls” primary VM-exit control is 0 (or if the processor does not support

the 1-setting of that control), no checks are performed on the secondary VM-exit controls. The logical

processor operates as if all the secondary VM-exit controls were 0.

If any of these checks fail, subsequent checks are skipped and VMCALL fails. If all these checks succeed, the logical

processor uses the IA32_SMM_MONITOR_CTL MSR to determine the base address of MSEG. The following checks

are performed in the order indicated:

1. The logical processor reads the 32 bits at the base of MSEG and compares them to the processor’s MSEG

revision identifier.

2. The logical processor reads the SMM-transfer monitor features field:

- Bit 0 of the field is the IA-32e mode SMM feature bit, and it indicates whether the logical processor will be

in IA-32e mode after the SMM-transfer monitor (STM) is activated.

• If the VMCALL is executed on a processor that does not support Intel 64 architecture, the IA-32e mode

SMM feature bit must be 0.

• If the VMCALL is executed in 64-bit mode, the IA-32e mode SMM feature bit must be 1.

- Bits 31:1 of this field are currently reserved and must be zero.

If any of these checks fail, subsequent checks are skipped and the VMCALL fails.

34.15.6.2 Updating the Current-VMCS and Executive-VMCS Pointers

Before performing the steps in Section 34.15.2.2, SMM VM exits that activate the dual-monitor treatment begin by

loading the SMM-transfer VMCS pointer with the value of the current-VMCS pointer.

34.15.6.3 Saving Guest State

As noted in Section 34.15.2.4, SMM VM exits save the contents of the SMBASE register into the corresponding field

in the guest-state area. While this is true also for SMM VM exits that activate the dual-monitor treatment, the

VMCS used for those VM exits exists outside SMRAM.

The SMM-transfer monitor (STM) can also discover the current value of the SMBASE register by using the RDMSR

instruction to read the IA32_SMBASE MSR (MSR address 9EH). The following items detail use of this MSR:

• The MSR is supported only if IA32_VMX_MISC[15] = 1 (see Appendix A.6).

• A write to the IA32_SMBASE MSR using WRMSR generates a general-protection fault (#GP(0)). An attempt to

write to the IA32_SMBASE MSR fails if made as part of a VM exit or part of a VM entry.

2. Software should consult the VMX capability MSR IA32_VMX_BASIC (see Appendix A.1) to determine whether the dual-monitor

treatment is supported.

Vol. 3C

34-27

SYSTEM MANAGEMENT MODE

• A read from the IA32_SMBASE MSR using RDMSR generates a general-protection fault (#GP(0)) if executed

outside of SMM. An attempt to read from the IA32_SMBASE MSR fails if made as part of a VM exit that does not

end in SMM.

34.15.6.4 Saving MSRs

The VM-exit MSR-store area is not used by SMM VM exits that activate the dual-monitor treatment. No MSRs are

saved into that area.

34.15.6.5 Loading Host State

The VMCS that is current during an SMM VM exit that activates the dual-monitor treatment was established by the

executive monitor. It does not contain the VM-exit controls and host state required to initialize the STM. For this

reason, such SMM VM exits do not load processor state as described in Section 30.5. Instead, state is set to fixed

values or loaded based on the content of the MSEG header (see Table 34-10):

•

CR0 is set to as follows:

- PG, NE, ET, MP, and PE are all set to 1.

- CD and NW are left unchanged.

- All other bits are cleared to 0.

•

CR3 is set as follows:

- Bits 63:32 are cleared on processors that support IA-32e mode.

- Bits 31:12 are set to bits 31:12 of the sum of the MSEG base address and the CR3-offset field in the MSEG

header.

- Bits 11:5 and bits 2:0 are cleared (the corresponding bits in the CR3-offset field in the MSEG header are

ignored).

- Bits 4:3 are set to bits 4:3 of the CR3-offset field in the MSEG header.

•

CR4 is set as follows:

- MCE, PGE, CET, PCIDE, LA57, and FRED are cleared.

- PAE is set to the value of the IA-32e mode SMM feature bit.

- If the IA-32e mode SMM feature bit is clear, PSE is set to 1 if supported by the processor; if the bit is set,

PSE is cleared.

- All other bits are unchanged.

•

DR7 is set to 400H.

•

The IA32_DEBUGCTL MSR is cleared to 00000000_00000000H.

•

The registers CS, SS, DS, ES, FS, and GS are loaded as follows:

- All registers are usable.

- CS.selector is loaded from the corresponding field in the MSEG header (the high 16 bits are ignored), with

bits 2:0 cleared to 0. If the result is 0000H, CS.selector is set to 0008H.

- The selectors for SS, DS, ES, FS, and GS are set to CS.selector+0008H. If the result is 0000H (if the CS

selector was FFF8H), these selectors are instead set to 0008H.

- The base addresses of all registers are cleared to zero.

- The segment limits for all registers are set to FFFFFFFFH.

- The AR bytes for the registers are set as follows:

• CS.Type is set to 11 (execute/read, accessed, non-conforming code segment).

• For SS, DS, ES, FS, and GS, the Type is set to 3 (read/write, accessed, expand-up data segment).

• The S bits for all registers are set to 1.

• The DPL for each register is set to 0.

34-28

Vol. 3C

SYSTEM MANAGEMENT MODE

• The P bits for all registers are set to 1.

• On processors that support Intel 64 architecture, CS.L is loaded with the value of the IA-32e mode SMM

feature bit.

• CS.D is loaded with the inverse of the value of the IA-32e mode SMM feature bit.

• For each of SS, DS, ES, FS, and GS, the D/B bit is set to 1.

• The G bits for all registers are set to 1.

• LDTR is unusable. The LDTR selector is cleared to 0000H, and the register is otherwise undefined (although the

base address is always canonical)

• GDTR.base is set to the sum of the MSEG base address and the GDTR base-offset field in the MSEG header

(bits 63:32 are always cleared on processors that support IA-32e mode). GDTR.limit is set to the corre-

sponding field in the MSEG header (the high 16 bits are ignored).

• IDTR.base is unchanged. IDTR.limit is cleared to 0000H.

• RIP is set to the sum of the MSEG base address and the value of the RIP-offset field in the MSEG header

(bits 63:32 are always cleared on logical processors that support IA-32e mode).

• RSP is set to the sum of the MSEG base address and the value of the RSP-offset field in the MSEG header

(bits 63:32 are always cleared on logical processor that supports IA-32e mode).

• RFLAGS is cleared, except bit 1, which is always set.

• The logical processor is left in the active state.

• Event blocking after the SMM VM exit is as follows:

- There is no blocking by STI or by MOV SS.

- There is blocking by non-maskable interrupts (NMIs) and by SMIs.

• There are no pending debug exceptions after the SMM VM exit.

• For processors that support IA-32e mode, the IA32_EFER MSR is modified so that LME and LMA both contain

the value of the IA-32e mode SMM feature bit.

If any of CR3[63:5], CR4.PAE, CR4.PSE, or IA32_EFER.LMA is changing, the TLBs are updated so that, after

VM exit, the logical processor does not use translations that were cached before the transition. This is not neces-

sary for changes that would not affect paging due to the settings of other bits (for example, changes to CR4.PSE if

IA32_EFER.LMA was 1 before and after the transition).

34.15.6.6 Loading MSRs

The VM-exit MSR-load area is not used by SMM VM exits that activate the dual-monitor treatment. No MSRs are

loaded from that area.

34.15.7 Deactivating the Dual-Monitor Treatment

The SMM-transfer monitor may deactivate the dual-monitor treatment and return the processor to default treat-

ment of SMIs and SMM (see Section 34.14). It does this by executing a VM entry with the “deactivate dual-monitor

treatment” VM-entry control set to 1.

As noted in Section 29.2.1.3 and Section 34.15.4.1, an attempt to deactivate the dual-monitor treatment fails in

the following situations: (1) the processor is not in SMM; (2) the “entry to SMM” VM-entry control is 1; or (3) the

executive-VMCS pointer does not contain the VMXON pointer (the VM entry is to VMX non-root operation).

As noted in Section 34.15.4.9, VM entries that deactivate the dual-monitor treatment ignore the SMI bit in the

interruptibility-state field of the guest-state area. Instead, the blocking of SMIs following such a VM entry depends

on whether the logical processor is in SMX operation:¹

1. A logical processor is in SMX operation if GETSEC[SEXIT] has not been executed since the last execution of GETSEC[SENTER]. A logi-

cal processor is outside SMX operation if GETSEC[SENTER] has not been executed or if GETSEC[SEXIT] was executed after the last

execution of GETSEC[SENTER]. See Chapter 7, “Safer Mode Extensions Reference,” in the Intel^® 64 and IA-32 Architectures Soft-

ware Developer’s Manual, Volume 2D.

Vol. 3C

34-29

SYSTEM MANAGEMENT MODE

• If the logical processor is in SMX operation, SMIs are blocked after VM entry. SMIs may later be unblocked by

the VMXOFF instruction (see Section 34.14.4) or by certain leaf functions of the GETSEC instruction (see

Chapter 7, “Safer Mode Extensions Reference,” in the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 2D).

• If the logical processor is outside SMX operation, SMIs are unblocked after VM entry.

34.16 SMI AND PROCESSOR EXTENDED STATE MANAGEMENT

On processors that support processor extended states using XSAVE/XRSTOR (see Chapter 13, “Managing State

Using the XSAVE Feature Set‚” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1),

the processor does not save any XSAVE/XRSTOR related state on an SMI. It is the responsibility of the SMI handler

code to properly preserve the state information (including CR4.OSXSAVE, XCR0, and possibly processor extended

states using XSAVE/XRSTOR). Therefore, the SMI handler must follow the rules described in Chapter 13,

“Managing State Using the XSAVE Feature Set‚” of the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1.

34.17 MODEL-SPECIFIC SYSTEM MANAGEMENT ENHANCEMENT

This section describes enhancement of system management features that apply only to the 4th generation Intel

Core processors. These features are model-specific. BIOS and SMM handler must use CPUID to enumerate Display-

Family_DisplayModel signature when programming with these interfaces.

34.17.1 SMM Handler Code Access Control

The BIOS may choose to restrict the address ranges of code that SMM handler executes. When SMM handler code

execution check is enabled, an attempt by the SMM handler to execute outside the ranges specified by SMRR (see

Section 34.4.2.1) will cause the assertion of an unrecoverable machine check exception (MCE).

The interface to enable SMM handler code access check resides in a per-package scope model-specific register

MSR_SMM_FEATURE_CONTROL at address 4E0H. An attempt to access MSR_SMM_FEATURE_CONTROL outside of

SMM will cause a #GP. Writes to MSR_SMM_FEATURE_CONTROL is further protected by configuration interface of

MSR_SMM_MCA_CAP at address 17DH.

Details of the interface of MSR_SMM_FEATURE_CONTROL and MSR_SMM_MCA_CAP are described in Table 2-29 in

Chapter 2, “Model-Specific Registers (MSRs),” of the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 4.

34.17.2 SMI Delivery Delay Reporting

Entry into the system management mode occurs at instruction boundary. In situations where a logical processor is

executing an instruction involving a long flow of internal operations, servicing an SMI by that logical processor will

be delayed. Delayed servicing of SMI of each logical processor due to executing long flows of internal operation in

a physical processor can be queried via a package-scope register MSR_SMM_DELAYED at address 4E2H.

The interface to enable reporting of SMI delivery delay due to long internal flows resides in a per-package scope

model-specific register MSR_SMM_DELAYED. An attempt to access MSR_SMM_DELAYED outside of SMM will cause

a #GP. Availability to MSR_SMM_DELAYED is protected by configuration interface of MSR_SMM_MCA_CAP at

address 17DH.

Details of the interface of MSR_SMM_DELAYED and MSR_SMM_MCA_CAP are described in Table 2-29 in Chapter 2,

“Model-Specific Registers (MSRs),” of the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume

34-30

Vol. 3C

CHAPTER 35

SECURE ARBITRATION MODE (SEAM)

This chapter specifies secure arbitration mode (SEAM), an extension of the virtual machines extensions architec-

ture (VMX) that allows running secure virtual machines.

The SEAM architecture is used as a foundation for Trusted Domains Extensions (TDX) architecture. For details

about TDX, see Intel^® Trust Domain Extensions (Intel^® TDX) - An overview of the Intel TDX technology.

35.1

MODES OF OPERATION

The SEAM architecture defines a protected mode of operation called SEAM, which is an extension of VMX operation.

Like VMX operation, SEAM includes root and non-root operations:

• SEAM root operation is the SEAM extension of VMX root operation. The software running in SEAM root

operation is called a SEAM module. There are two sub-modes to SEAM root operation:

- Loader mode: At most one logical processor can execute in this sub-mode at any time.

- Module mode: Multiple logical processors can execute in this sub-mode in parallel.

• SEAM non-root operation is the SEAM extension of VMX non-root operation. The software running in this

SEAM non-root operation is called SEAM guest. Multiple logical processors can execute in this mode concur-

rently.

Certain platform operations may be required to enable SEAM; until they are performed, SEAM is not enabled. Once

SEAM is enabled, it may or may not be ready for execution in loader mode or in module mode (again, possibly

based on certain platform operations). Details regarding this enabling are provided in the Intel^® Trust Domain CPU

Architectural Extensions

The following diagram shows the VMX and SEAM software components, the modes in which they operate, and the

transitions between these execution modes.

Figure 35-1. SEAM Modes of Operation

Vol. 3C

35-1

SECURE ARBITRATION MODE (SEAM)

35.1.1 SEAM Calls

Processor transitions from VMX root operation to SEAM root operation are called SEAM calls. SEAM calls are initi-

ated by executing the SEAMCALL instruction. A SEAM call operates in a manner similar to that of SMM VM exits (see

Section 34.15.2) in response to execution of the VMCALL instruction in VMX root operation. A SEAM call uses a

SEAM-transfer VMCS that resides within the SEAM range of the physical-address space (see Section 35.4.1).

SEAM calls use RAX[63] to determine the SEAM root operation sub-mode to be entered. When RAX[63] is 0, the

transition is into module-mode SEAM root operation; otherwise, it is into loader-mode SEAM root operation. An

attempt to enter loader-mode SEAM root operation fails if another logical processor is in SEAM having entered in

loader mode.

35.1.2 SEAM Returns

Processor transitions from SEAM root operation back to VMX root operation are called SEAM returns. SEAM

returns are initiated by executing the SEAMRET instruction. A SEAM return operates in a manner similar to that of

VM entries that return from SMM (see Section 34.15.4). Like SEAM calls, SEAM returns use a SEAM-transfer VMCS.

A SEAM return from loader-mode SEAM root operation ensures that all data for any VMCS that the logical processor

used in SEAM (including the SEAM-transfer VMCS) are in memory; in addition, there is no current VMCS after such

a SEAM return.

35.1.3 SEAM Host-Guest Transitions

Processor transitions between SEAM root operation and SEAM non-root operation are similar to processor transition

between VMX root operation and VMX non-root operation. A VMCS used to transition between SEAM root and non-

root operation, and to control SEAM non-root operation, is called SEAM-guest VMCS.

A SEAM-guest VMCS supports SEAM-specific fields and controls. In general, those fields and controls are ignored

outside SEAM.

The SEAM-specific VMCS fields are the following:

• SEAM-guest KeyID. This is a VM-execution control field that contains the key identifier (KeyID) assigned for

the key with which the SEAM guest’s private pages are encrypted in memory.

• SEAM shared EPT pointer. This is a VM-execution control field that contains the physical address of the base

of shared EPT PML4 table or PML5 table (depending on how EPT is configured).

The SEAM-specific VMX controls are the following:

• SEAM guest-physical address width. This is a VM-execution control that determines, for SEAM non-root

operation, the width of guest-physical addresses translated by EPT and also the position of the SHARED bit in

guest-physical addresses. See Section 35.4.

• Allow SEAM-guest telemetry. This is a VM-entry control that allows collection of core telemetry in SEAM non-

root operation.

Any processor that supports SEAM also supports the SEAM-specific VMCS fields and controls identified above.

Support for the SEAM-specific VMX controls above is enumerated normally by the IA32_VMX_PROCBASED_CTLS3

MSR (for “SEAM guest-physical address width”) and by IA32_VMX_ENTRY_CTLS MSR (for “allow SEAM-guest

telemetry”).

SEAM guests must run with EPT enabled. VM entry in SEAM root operation will fail if the “enable EPT” VM-execution

control is not set in the SEAM-guest VMCS.

35.2

SEAM AND TME-MK

SEAM interoperates with multi-key total memory encryption (TME-MK). This section explains the specifics of

TME-MK related to that interoperation.

The current configuration of TME-MK can be inferred from the contents of the IA32_TME_ACTIVATE MSR (MSR

address 982H). The following fields are relevant:

35-2

Vol. 3C

SECURE ARBITRATION MODE (SEAM)

• If IA32_TME_ACTIVATE[1:0] = 11B, total-memory encryption (TME) is active.

• IA32_TME_ACTIVATE.MK_TME_KEYID_BITS[35:32] specifies the number of bits in a physical address that are

interpreted as a key identifier (KeyID). If TME is active and this value is greater than 0, TME-MK is active.

• IA32_TME_ACTIVATE.TDX_RESERVED_KEYID_BITS[39:36] specifies the number of KeyID bits that can be

used only in SEAM-private KeyIDs (see Section 35.3.2). This value never exceeds IA32_TME_AC-

TIVATE.MK_TME_KEYID_BITS.

Let m be the value enumerated by CPUID.80000008H:EAX[7:0]; k = IA32_TME_ACTIVATE.MK_TME_KEYID_BITS;

and p = IA32_TME_ACTIVATE.TDX_RESERVED_KEYID_BITS. Then in any physical address, bits m-1:m-k form a

key identifier that is used to select an encryption key (only bits (m-k)-1:0 are used to address memory). The

PCONFIG instruction can be used to specify the encryption key associated with each key identifier. it sets it sets

The IA32_MKTME_KEYID_PARTITIONING MSR (MSR address 87H) enumerates the number of key identifiers avail-

able for use:

• IA32_MKTME_KEYID_PARTITIONING.NUM_MKTME_KIDS[31:0] enumerates the number of TME-MK key

identifiers available for general use. These are numbered 1 to NUM_MKTME_KIDS (0 is not considered a

TME-MK key identifier).

• IA32_MKTME_KEYID_PARTITIONING.NUM_TDX_PRIV_KIDS[63:32] enumerates the number of SEAM-private

key identifiers. These are numbered NUM_MKTME_KIDS + 1 to NUM_MKTME_KIDS + NUM_TDX_PRIV_KIDS.

35.3

OPERATION IN SEAM

This section provides details of both SEAM root operation and SEAM non-root operation.

35.3.1 SEAM Root Operation

Processor behavior in SEAM root operation is similar to processor behavior in VMX root operation, with the

following differences:

• Software can execute the SEAMRET and SEAMOPS instructions. (Execution of these instructions outside SEAM

root operation results in a #UD exception.) As noted in Section 35.1.2, execution of SEAMRET causes a SEAM

return to VMX root operation. The SEAMRET and SEAMOPS instructions are is described in Intel^® Trust Domain

CPU Architectural Extensions.

• Software can access a special set of SEAM-only MSRs. An attempt to access a SEAM-only MSR outside SEAM

results in a #GP(0) exception. (Some may be accessible only in SEAM root operation.) The full set of SEAM-only

MSRs is specified in Intel^® Trust Domain CPU Architectural Extensions.

• An attempt to execute the VMXOFF instruction or the VMCALL instruction in SEAM root operation results in a

#GP(0) exception. Software in SEAM cannot leave VMX operation, nor can it invoke an SMM-transfer monitor

using an SMM VM exit.

• Entry to SEAM root operation (by either a SEAM call or a VM exit from SEAM non-root operation) blocks NMIs.

Execution of IRET in SEAM root operation unblocks NMIs normally.

• System-management interrupts (SMIs), uncore machine checks and machine-check SMIs (MSMIs) are masked

in SEAM root operation. If pending, they are delivered after leaving SEAM root operation.

• Triple faults and machine checks caused by poisoned cache-line consumption in SEAM root operation cause

unbreakable shutdown.

• TLB entries that cache address translations are tagged with an “in SEAM” bit, to separate them from address

translations cached in VMX non-root operation. Software running in VMX root operation can invalidate them

using the INVEPT instruction but not using the INVVPID instruction.

35.3.2 SEAM Non-Root Operation

Processor behavior in SEAM non-root operation is largely the same as that in VMX non-root operation.

Vol. 3C

35-3

SECURE ARBITRATION MODE (SEAM)

System-management interrupts (SMIs) and machine-check SMIs (MSMIs) that occur in SEAM non-root operation

cause a VM exit instead of being delivered normally. The SMI or MSMI remains pending and will be delivered

following the next SEAM return.

The remainder of this section explains the changes in SEAM non-root operation with regard to the use of guest-

physical addresses.

As noted in Section 35.1.3, VM entry to SEAM non-root operation requires EPT to be enabled. Thus, all addresses

used by guest software as physical addresses (e.g., addresses in the guest’s paging structures) are treated as

guest-physical addresses and are thus translated by EPT. Translation by EPT in SEAM non-root operation differs

somewhat from that in ordinary VMX non-root operation.

In VMX non-root operation, the width of guest-physical addresses is either 48 bits (if 4-level EPT is in use) or 52

bits (for 5-level EPT). In SEAM non-root operation, the guest-physical address width is 48 bits if the “SEAM guest-

physical address width” VM-execution control is 0 (even if 5-level EPT is in use).

If the guest-physical address width is 48, an access to a guest-physical address that sets bits in the range 51:48

causes an EPT violation. (This is not the case with 5-level EPT outside SEAM. In SEAM, this occurs with 5-level

paging as long as the “SEAM guest-physical address width” VM-execution control is 0.)

The uppermost bit in a guest-physical address (bit 47 or bit 51 as appropriate) is defined to be the address’s

“SHARED” bit. Guest-physical addresses that clear this bit are SEAM-guest private addresses; those that set

this bit are SEAM-guest shared addresses.

Certain situations in SEAM non-root operation require SEAM-guest private addresses:

• Instruction fetches are limited to SEAM-guest private addresses. An attempt to fetch an instruction from a

SEAM-guest shared address results in a general-protection exception (#GP(0)).

• CR3 must contain a SEAM-guest private address. An attempt to load CR3 with a SEAM-guest shared address

results in #GP(0).

• With PAE paging, each of the PDPTE registers must contain a SEAM-guest private address. An attempt to load

any PDPTE register with a SEAM-guest shared address results in #GP(0).

• The guest paging structures must be located at SEAM-guest private addresses. If linear-address translation

encounters a paging-structure entry that references a paging structure with a SEAM-guest shared address, a

page fault (#PF) occurs. The error code will set bit 3, indicating that a reserved bit was set.

Translation of guest-physical addresses differs for private and shared addresses:

• Translation of a SEAM-guest private address uses EPT paging structures located using the EPTP field in the

VMCS.

- Any physical address used to access an EPT paging structure is modified as follows. Let k be the value of

IA32_TME_ACTIVATE.MK_TME_KEYID_BITS[35:32] and M be the value enumerated by

CPUID.80000008H:EAX[7:0]. Before being used to access memory, bits M-1:M-k of the physical address

are replaced by bits k-1:0 of the SEAM-guest KeyID field in the VMCS.

- The final physical address (to which the original SEAM-guest private address is being translated) is also

modified in the manner described in the previous paragraph.

• Translation of a SEAM-guest shared address uses EPT paging structures located using the SEAM shared EPT

pointer in the VMCS.

- Bits 7:0 of the EPTP field (not the SEAM shared EPT pointer) control the translation of the guest-physical

address.

- Any physical address used to access an EPT paging structure should not use a SEAM-private KeyID (see

Section 35.2).

If translation of a SEAM-guest shared address would access an EPT paging structure with a SEAM-private

KeyID, an EPT misconfiguration occurs.

- The final physical address (to which the original SEAM-guest shared address is being translated) also must

not contain a SEAM-private KeyID; otherwise, an EPT misconfiguration occurs.

35-4

Vol. 3C

SECURE ARBITRATION MODE (SEAM)

35.4

MEMORY PROTECTION

This section specifies access controls and cryptographic measures applied to protect software running in SEAM root

operation (SEAM modules) and SEAM non-root operation (SEAM guests).

35.4.1 SEAM Range

The SEAM range is a physical memory range sequestered for SEAM modules. The range is allocated using range-

these MSRs is enumerated by bit 15 of IA32_MTRRCAP (MSR address FEH). Processors that support SEAM archi-

tecture return IA32_MTRRCAP bit 15 as 1. For more information about these MSRs, see Chapter 2 in Volume 4 of

the Intel^® 64 and IA-32 Architectures Software Developer’s Manual.

The SEAM range is divided into a module sub-range and a loader sub-range.

Bit 11 of IA32_SEAMRR_MASK MSR indicates whether the SEAM range is valid and protected. When this bit is 1,

the processor provides the SEAM range with cryptographic and access-control protections as follows:

• Outside SEAM root operation, accesses to the physical addresses in the SEAM range are aborted, meaning that

writes are ignored and reads return values with all bits set to 1.

• The following items apply in SEAM root operation:

- Accesses to the module sub-range of the SEAM range are allowed.

- Accesses to the loader sub-range of the SEAM range are allowed only in loader-mode SEAM root operation;

otherwise they are aborted (see above).

- Instruction fetches from physical addresses outside the SEAM range are prevented by the processor (the

response to such attempts is implementation-specific).

• The contents of the SEAM range are encrypted by the TME-MK engine. The encryption key is machine-specific.

It's typically an “ephemeral” key that is generated each time the platform is restarted.

Accesses to SEAM range when CR0.CD = 0 use the writeback (WB) memory type regardless of the MTRR and PAT

registers. If CR0.CD = 1, accesses use the uncacheable (UC) memory type.

35.4.2 Memory Protections

Outside SEAM, registers holding physical addresses cannot be loaded with physical addresses with SEAM-private

KeyIDs (see Section 35.3.2):

• Attempts to load control registers and MSRs with a physical address with a SEAM-private KeyID results in a

general-protection exception (#GP(0)). This does not apply to loads of the IA32_RTIT_OUTPUT_BASE MSR

(using WRMSR, WRMSRLIST, WRMSRNS, or XRSTORS), as that MSR is checked at another time (see below).

• Linear-address translation without EPT that encounters a paging-structure entry with a physical address with a

SEAM-private KeyID results in a page fault.

• Guest-physical-address translation with EPT that encounters an EPT paging-structure entry with a physical

address with a SEAM-private KeyID results in an EPT misconfiguration.

• VM entry fails if it would use or load a physical address (from a VMCS field other than the SEAM shared EPT

pointer) that contains a SEAM-private KeyID.

• When processor trace is enabled (IA32_RTIT_CTL.TraceEn is set to 1), the value of a physical address being

loaded into IA32_RTIT_OUTPUT_BASE MSR is checked, as is the physical address of a new output buffer when

it is loaded from the table of physical addresses (ToPA). Attempts to load one of these with a physical address

that has a SEAM-private KeyID results in a machine-dependent behavior: either processor trace is disabled

with an error logged or subsequent trace output is dropped.

• An attempt to load IA32_APIC_BASE with a physical address that has a non-zero KeyID results in #GP(0).

• A VMX instruction with a physical-address operand with a SEAM-private KeyID fails as if the physical address

set a reserved bit to 1.

Vol. 3C

35-5

SECURE ARBITRATION MODE (SEAM)

If, despite the limitations identified above, there is an access using a physical address with a SEAM-private KeyID

(perhaps because an MSR had been loaded before TME was activated), the access is aborted, meaning that writes

are ignored and reads return values with all bits set to 1.

A cacheline that was written with a physical address with a SEAM-private KeyID cannot be read using a physical

address with a different KeyID. The memory-protection mode supported by a particular processor is machine-

dependent. For information about memory protection modes, see Intel^® Architecture Memory Protections for

Confidential Compute Usages.

35.5

SEAM INSTRUCTION REFERENCE

The SEAM architecture includes the following instructions:

• SEAMCALL. Execution causes a SEAM call (see Section 35.1.1) to enter SEAM root operation. It can be used

by virtual-machine monitors (operating in VMX root operation) to call SEAM module services.

• TDCALL. Execution causes a VM exit from SEAM non-root operation to SEAM root operation. It can be used by

SEAM guests to request SEAM-module services.

• SEAMOPS. Execution invokes SEAM-specific operation. It is used by SEAM modules to execute such

operations.

• SEAMRET. Execution causes a SEAM return (Section 35.1.2) that leaves SEAM root operation. It is used by

SEAM modules to return to the calling virtual-machine monitor.

SEAMCALL and TDCALL are described later in this section. SEAMOPS and SEAMRET can be executed only in SEAM

root operation. Details are given in Intel^® Trust Domain CPU Architectural Extensions, while the following items

provide high-level information:

• SEAMOPS. The SEAMOPS instruction allows software running in SEAM root operation to invoke SEAM-specific

operations. Some of these operations can be invoked only in loader mode.

• SEAMRET.

- SEAMRET is a privileged instruction that allows software running in SEAM root operation to return to VMX

root operation.

- The instruction causes a SEAM return (see Section 35.1.2) using the SEAM-transfer VMCS. This transition

is similar to VM entries that return from SMM (see Section 34.15.4).

An attempt to execute a SEAM instruction on a processor that does not support SEAM results in an invalid-opcode

exception (#UD).

35-6

Vol. 3C

SECURE ARBITRATION MODE (SEAM)

SEAMCALL-Enter SEAM Root Operation

Opcode

Instruction

Op/

64-bit

Compat/

Description

Mode

Leg Mode

66 0F 01 CF

SEAMCALL

Valid

Invalid

Transitions to SEAM root operation.

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

N/A

Description

SEAMCALL is a privileged instruction that passes control to software running in SEAM root operation. The instruc-

tion can be executed only in 64-bit mode in VMX operation outside SEAM and outside SMM. In VMX non-root oper-

ation, execution causes a VM exit with exit reason 76, SEAMCALL.

Execution when the SEAM range is not valid (IA32_SEAMRR_MASK MSR[11] = 0) or immediately following execu-

tion of MOV to SS or POP SS instruction results in a general-protection exception (#GP).

The instruction uses RAX[63] to select a submode of SEAM root operation: if this value is 1, the instruction transi-

tions into loader-mode SEAM root operation; otherwise, it transitions into module-mode SEAM root operation. The

instruction fails with VMFailInvalid indication (see Section 33.2) if SEAM is globally disabled; or if a loader-mode

SEAM root operation is called when another logical processor is in SEAM having entered in loader mode.

If there is no failure, the SEAMCALL uses the SEAM-transfer VMCS to effect a SEAM call (see Section 35.1.1). The

details of such transitions are specified in the Intel^® Trust Domain CPU Architectural Extensions.

Operation

IF not in VMX operation or in SMM or in SEAM or IA32_EFER.LMA = 0 or CS.L = 0

THEN #UD;

ELSIF CPL > 0

THEN #GP(0);

ELSIF in VMX non-root operation

THEN VM exit;

ELSIF IA32_SEAMRR_MASK.VALID = 0 or events blocked by MOV SS

THEN #GP(0);

ELSIF SEAM is globally disabled

THEN VMFailInvalid;

ELSIF RAX[63] = 0

THEN

IF module-mode SEAM root operation is not ready for execution

THEN VMFailInvalid;

ELSE

Enter module-mode SEAM root operation;

FI;

ELSE

IF loader-mode SEAM root operation is not ready for execution or

another logical processor is executing in SEAM having entered in loader mode

THEN VMFailInvalid;

ELSE

Enter loader-mode SEAM root operation;

FI;

Vol. 3C

35-7

SECURE ARBITRATION MODE (SEAM)

TDCALL-Call SEAM Module

Opcode

Instruction

Op/

64-bit

Compat/

Description

Mode

Leg Mode

66 0F 01 CC

TDCALL

Valid

Call SEAM monitor from SEAM guest.

Instruction Operand Encoding

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

N/A

Description

TDCALL is a privileged instruction that allows software running in SEAM non-root operation to call software running

in SEAM root operation. The instruction can be executed only in SEAM non-root operation or VMX non-root opera-

tion.

In SEAM non-root operation or VMX non-root operation, execution causes a VM exit with exit reason 77 (TDCALL).

Operation

IF not in SEAM non-root operation and not in VMX non-root operation

THEN #UD;

ELSIF CPL > 0

THEN #GP(0);

ELSE VM exit;

FI;

Flags Affected

None.

Protected Mode Exceptions

#UD

If executed outside VMX non-root operation and outside SEAM non-root operation.

#GP(0)

If the current privilege level is not 0.

Real-Address Mode Exceptions

#UD

If executed outside VMX non-root operation and outside SEAM non-root operation.

Virtual-8086 Mode Exceptions

#UD

If executed outside VMX non-root operation and outside SEAM non-root operation.

#GP(0)

If executed in VMX non-root operation or in SEAM non-root operation.

Compatibility Mode Exceptions

Same as protected mode exceptions.

64-Bit Mode Exceptions

Same as protected mode exceptions.

Vol. 3C

35-9

INTEL® PROCESSOR TRACE

CHAPTER 36

INTEL® PROCESSOR TRACE

36.1

OVERVIEW

Intel^® Processor Trace (Intel PT) is an extension of Intel^® Architecture that captures information about software

execution using dedicated hardware facilities that cause only minimal performance perturbation to the software

being traced. This information is collected in data packets. The initial implementations of Intel PT offer control

flow tracing, which generates a variety of packets to be processed by a software decoder. The packets include

timing, program flow information (e.g., branch targets, branch taken/not taken indications) and program-induced

mode related information (e.g., Intel TSX state transitions, CR3 changes). These packets may be buffered inter-

nally before being sent to the memory subsystem or other output mechanism available in the platform. Debug soft-

ware can process the trace data and reconstruct the program flow.

Intel Processor Trace was first introduced in Intel^® processors based on Broadwell microarchitecture and Intel

Atom^®processors based on Goldmont microarchitecture. Later generations include additional trace sources,

including software trace instrumentation using PTWRITE, and Power Event tracing.

36.1.1 Features and Capabilities

Intel PT’s control flow trace generates a variety of packets that, when combined with the binaries of a program by

a post-processing tool, can be used to produce an exact execution trace. The packets record flow information such

as instruction pointers (IP), indirect branch targets, and directions of conditional branches within contiguous code

regions (basic blocks).

Intel PT can also be configured to log software-generated packets using PTWRITE, and packets describing

processor power management events. Further, Precise Event-Based Sampling (PEBS) can be configured to log

PEBS records in the Intel PT trace; see Section 22.5.5.2.

In addition, the packets record other contextual, timing, and bookkeeping information that enables both functional

and performance debugging of applications. Intel PT has several control and filtering capabilities available to

customize the tracing information collected and to append other processor state and timing information to enable

debugging. For example, there are modes that allow packets to be filtered based on the current privilege level

(CPL) or the value of CR3.

Configuration of the packet generation and filtering capabilities are programmed via a set of MSRs. The MSRs

generally follow the naming convention of IA32_RTIT_*. The capability provided by these configuration MSRs are

enumerated by CPUID, see Section 36.3. Details of the MSRs for configuring Intel PT are described in Section

36.2.8.

36.1.1.1 Packet Summary

After a tracing tool has enabled and configured the appropriate MSRs, the processor will collect and generate trace

information in the following categories of packets (for more details on the packets, see Section 36.4):

• Packets about basic information on program execution; these include:

- Packet Stream Boundary (PSB) packets: PSB packets act as ‘heartbeats’ that are generated at regular

intervals (e.g., every 4K trace packet bytes). These packets allow the packet decoder to find the packet

boundaries within the output data stream; a PSB packet should be the first packet that a decoder looks for

when beginning to decode a trace.

- Paging Information Packet (PIP): PIPs record modifications made to the CR3 register. This information,

along with information from the operating system on the CR3 value of each process, allows the debugger

to attribute linear addresses to their correct application source.

- Time-Stamp Counter (TSC) packets: TSC packets aid in tracking wall-clock time, and contain some portion

of the software-visible time-stamp counter.

- Core Bus Ratio (CBR) packets: CBR packets contain the core:bus clock ratio.

Vol. 3C

36-1

INTEL® PROCESSOR TRACE

- Mini Time Counter (MTC) packets: MTC packets provide periodic indication of the passing of wall-clock time.

- Cycle Count (CYC) packets: CYC packets provide indication of the number of processor core clock cycles

that pass between packets.

- Overflow (OVF) packets: OVF packets are sent when the processor experiences an internal buffer overflow,

resulting in packets being dropped. This packet notifies the decoder of the loss and can help the decoder to

respond to this situation.

•

Packets about control flow information:

- Taken Not-Taken (TNT) packets: TNT packets track the “direction” of direct conditional branches (taken or

not taken).

- Target IP (TIP) packets: TIP packets record the target IP of indirect branches, exceptions, interrupts, and

other branches or events. These packets can contain the IP, although that IP value may be compressed by

eliminating upper bytes that match the last IP. There are various types of TIP packets; they are covered in

more detail in Section 36.4.2.2.

- Flow Update Packets (FUP): FUPs provide the source IP addresses for asynchronous events (interrupt and

exceptions), as well as other cases where the source address cannot be determined from the binary.

- MODE packets: These packets provide the decoder with important processor execution information so that

it can properly interpret the dis-assembled binary and trace log. MODE packets have a variety of formats

that indicate details such as the execution mode (16-bit, 32-bit, or 64-bit).

•

Packets inserted by software:

- PTWRITE (PTW) packets: includes the value of the operand passed to the PTWRITE instruction (see

“PTWRITE-Write Data to a Processor Trace Packet” in the Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 2B).

•

Packets about processor power management events:

- MWAIT packets: Indicate successful completion of an MWAIT operation to a C-state deeper than C0.0.

- Power State Entry (PWRE) packets: Indicate entry to a C-state deeper than C0.0.

- Power State Exit (PWRX) packets: Indicate exit from a C-state deeper than C0.0, returning to C0.

- Execution Stopped (EXSTOP) packets: Indicate that software execution has stopped, due to events such as

P-state change, C-state change, or thermal throttling.

•

Packets containing groups of processor state values:

- Block Begin Packets (BBP): Indicate the type of state held in the following group.

- Block Item Packets (BIP): Indicate the state values held in the group.

- Block End Packets (BEP): Indicate the end of the current group.

36.2

INTEL® PROCESSOR TRACE OPERATIONAL MODEL

This section describes the overall Intel Processor Trace mechanism and the essential concepts relevant to how it

operates.

36.2.1 Change of Flow Instruction (COFI) Tracing

A basic program block is a section of code where no jumps or branches occur. The instruction pointers (IPs) in this

block of code need not be traced, as the processor will execute them from start to end without redirecting code

flow. Instructions such as branches, and events such as exceptions or interrupts, can change the program flow.

These instructions and events that change program flow are called Change of Flow Instructions (COFI). There are

three categories of COFI:

• Direct transfer COFI.

• Indirect transfer COFI.

• Far transfer COFI.

36-2

Vol. 3C

INTEL® PROCESSOR TRACE

The following subsections describe the COFI events that result in trace packet generation. Table 36-1 lists branch

instruction by COFI types. For detailed description of specific instructions, see the Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual.

Table 36-1. COFI Type for Branch Instructions

COFI Type

Instructions

Conditional Branch

JA, JAE, JB, JBE, JC, JCXZ, JECXZ, JRCXZ, JE, JG, JGE, JL, JLE, JNA, JNAE, JNB, JNBE, JNC, JNE, JNG, JNGE, JNL,

JNLE, JNO, JNP, JNS, JNZ, JO, JP, JPE, JPO, JS, JZ, LOOP, LOOPE, LOOPNE, LOOPNZ, LOOPZ

Unconditional Direct Branch

JMP (E9 xx, EB xx), CALL (E8 xx)

Indirect Branch

JMP (FF /4), CALL (FF /2), RET (C3, C2 xx)

Far Transfers

ERETS, ERETU, INT1, INT3, INT n, INTO, IRET, IRETD, IRETQ, JMP (EA xx, FF /5), CALL (9A xx, FF /3),

RET (CB, CA xx), SYSCALL, SYSRET, SYSENTER, SYSEXIT, VMLAUNCH, VMRESUME

36.2.1.1 Direct Transfer COFI

Direct Transfer COFI are relative branches. This means that their target is an IP whose offset from the current IP is

embedded in the instruction bytes. It is not necessary to indicate target of these instructions in the trace output

since it can be obtained through the source disassembly. Conditional branches need to indicate only whether the

branch is taken or not. Unconditional branches do not need any recording in the trace output. There are two sub-

categories:

• Conditional Branch (Jcc, J*CXZ) and LOOP

To track this type of instruction, the processor encodes a single bit (taken or not taken - TNT) to indicate the

program flow after the instruction.

Jcc, J*CXZ, and LOOP can be traced with TNT bits. To improve the trace packet output efficiency, the processor

will compact several TNT bits into a single packet.

• Unconditional Direct Jumps

There is no trace output required for direct unconditional jumps (like JMP near relative or CALL near relative)

since they can be directly inferred from the application assembly. Direct unconditional jumps do not generate a

TNT bit or a Target IP packet, though TIP.PGD and TIP.PGE packets can be generated by unconditional direct

jumps that toggle Intel PT enables (see Section 36.2.6).

36.2.1.2 Indirect Transfer COFI

Indirect transfer instructions involve updating the IP from a register or memory location. Since the register or

memory contents can vary at any time during execution, there is no way to know the target of the indirect transfer

until the register or memory contents are read. As a result, the disassembled code is not sufficient to determine the

target of this type of COFI. Therefore, tracing hardware must send out the destination IP in the trace packet for

debug software to determine the target address of the COFI. Note that this IP may be a linear or effective address

(see Section 36.3.1.1).

An indirect transfer instruction generates a Target IP Packet (TIP) that contains the target address of the branch.

There are two sub-categories:

• Near JMP Indirect and Near Call Indirect

As previously mentioned, the target of an indirect COFI resides in the contents of either a register or memory

location. Therefore, the processor must generate a packet that includes this target address to allow the

decoder to determine the program flow.

• Near RET

When a CALL instruction executes, it pushes onto the stack the address of the next instruction following the

CALL. Upon completion of the call procedure, the RET instruction is often used to pop the return address off of

the call stack and redirect code flow back to the instruction following the CALL.

A RET instruction simply transfers program flow to the address it popped off the stack. Because a called

procedure may change the return address on the stack before executing the RET instruction, debug software

Vol. 3C

36-3

INTEL® PROCESSOR TRACE

can be misled if it assumes that code flow will return to the instruction following the last CALL. Therefore,

even for near RET, a Target IP Packet may be sent.

- RET Compression

A special case is applied if the target of the RET is consistent with what would be expected from tracking the

CALL stack. If it is assured that the decoder has seen the corresponding CALL (with “corresponding” defined

as the CALL with matching stack depth), and the RET target is the instruction after that CALL, the RET

target may be “compressed”. In this case, only a single TNT bit of “taken” is generated instead of a Target

IP Packet. To ensure that the decoder will not be confused in cases of RET compression, only RETs that

correspond to CALLs which have been seen since the last PSB packet may be compressed in a given logical

processor. For details, see “Indirect Transfer Compression for Returns (RET)” in Section 36.4.2.2.

36.2.1.3 Far Transfer COFI

All operations that change the instruction pointer and are not near jumps are “far transfers”. This includes excep-

tions, interrupts, traps, TSX aborts, and instructions that do far transfers.

All far transfers will produce a Target IP (TIP) packet, which provides the destination IP address. For those far

transfers that cannot be inferred from the binary source (e.g., asynchronous events such as exceptions and inter-

rupts), the TIP will be preceded by a Flow Update packet (FUP), which provides the source IP address at which the

event was taken. Table 36-23 indicates exactly which IP will be included in the FUP generated by a far transfer.

36.2.2 Software Trace Instrumentation with PTWRITE

PTWRITE provides a mechanism by which software can instrument the Intel PT trace. PTWRITE is a ring3-acces-

sible instruction that can be passed to a register or memory variable, see “PTWRITE-Write Data to a Processor

Trace Packet” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B, for details. The

contents of that variable will be used as the payload for the PTW packet (see Table 36-40 “PTW Packet Definition”),

inserted at the time of PTWRITE retirement, assuming PTWRITE is enabled and all other filtering conditions are

met. Decode and analysis software will then be able to determine the meaning of the PTWRITE packet based on the

IP of the associated PTWRITE instruction.

PTWRITE is enabled via IA32_RTIT_CTL.PTWEn[12] (see Table 36-6). Optionally, the user can use IA32_R-

TIT_CTL.FUPonPTW[5] to enable PTW packets to be followed by FUP packets containing the IP of the associated

PTWRITE instruction. Support for PTWRITE is introduced in Intel Atom processors based on the Goldmont Plus

microarchitecture.

36.2.3 Power Event Tracing

Power Event Trace is a capability that exposes core- and thread-level sleep state and power down transition infor-

mation. When this capability is enabled, the trace will expose information about:

- Scenarios where software execution stops.

• Due to sleep state entry, frequency change, or other powerdown.

• Includes the IP, when in the tracing context.

- The requested and resolved hardware thread C-state.

• Including indication of hardware autonomous C-state entry.

- The last and deepest core C-state achieved during a sleep session.

- The reason for C-state wake.

This information is in addition to the bus ratio (CBR) information provided by default after any powerdown, and the

timing information (TSC, TMA, MTC, CYC) provided during or after a powerdown state.

Power Event Trace is enabled via IA32_RTIT_CTL.PwrEvtEn[4]. Support for Power Event Tracing is introduced in

Intel Atom processors based on the Goldmont Plus microarchitecture.

36-4

Vol. 3C

INTEL® PROCESSOR TRACE

36.2.4 Event Tracing

Event Trace is a capability that exposes details about the asynchronous events, when they are generated, and

when their corresponding software event handler completes execution. These include:

• Interrupts, including NMI and SMI, including the interrupt vector when defined.

• Faults, exceptions including the fault vector.

- Page faults additionally include the page fault address, when in context.

• Event handler returns, including ERETS, ERETU, IRET, and RSM.

• VM exits and VM entries.¹

- VM exits include the values written to the “exit reason” and “exit qualification” VMCS fields.

• INIT and SIPI events.

• TSX aborts, including the abort status returned for the RTM instructions.

• Shutdown.

Additionally, it provides indication of the status of the Interrupt Flag (IF), to indicate when interrupts are masked.

Event Trace is enabled via IA32_RTIT_CTL.EventEn[31]. Event Trace information is conveyed in Control Flow Event

(CFE) and Event Data (EVD) packets, as well as the legacy MODE.Exec packet. See Section 36.4.2 for packet

details. Support for Event Trace is introduced in Intel^® processors based on Gracemont microarchitecture.

36.2.5 Trace Filtering

Intel Processor Trace provides filtering capabilities, by which the debug/profile tool can control what code is traced.

36.2.5.1 Filtering by Current Privilege Level (CPL)

Intel PT provides the ability to configure a logical processor to generate trace packets only when CPL = 0, when

CPL > 0, or regardless of CPL.

CPL filtering ensures that no IPs or other architectural state information associated with the filtered CPL can be

seen in the log. For example, if the processor is configured to trace only when CPL > 0, and software executes

SYSCALL (changing the CPL to 0), the destination IP of the SYSCALL will be suppressed from the generated packet

(see the discussion of TIP.PGD in Section 36.4.2.5).

It should be noted that CPL is always 0 in real-address mode and that CPL is always 3 in virtual-8086 mode. To

trace code in these modes, filtering should be configured accordingly.

When software is executing in a non-enabled CPL, ContextEn is cleared. See Section 36.2.6.1 for details.

36.2.5.2 Filtering by CR3

Intel PT supports a CR3-filtering mechanism by which the generation of packets containing architectural states can

be enabled or disabled based on the value of CR3. A debugger can use CR3 filtering to trace only a single applica-

tion without context switching the state of the RTIT MSRs. For the reconstruction of traces from software with

multiple threads, debug software may wish to context-switch for the state of the RTIT MSRs (if the operating

system does not provide context-switch support) to separate the output for the different threads (see Section

36.3.5, “Context Switch Consideration”).

To trace for only a single CR3 value, software can write that value to the IA32_RTIT_CR3_MATCH MSR, and set

IA32_RTIT_CTL.CR3Filter. When CR3 value does not match IA32_RTIT_CR3_MATCH and IA32_RTIT_CTL.CR3Filter

is 1, ContextEn is forced to 0, and packets containing architectural states will not be generated. Some other

packets can be generated when ContextEn is 0; see Section 36.2.6.3 for details. When CR3 does match IA32_R-

TIT_CR3_MATCH (or when IA32_RTIT_CTL.CR3Filter is 0), CR3 filtering does not force ContextEn to 0 (although it

could be 0 due to other filters or modes).

1. Logging of VMX transitions depends on VMCS configuration, see Section 36.5.1.

Vol. 3C

36-5

Intel 64 and IA-32 Architectures. Software Developer’s Manual (2026) - page 64