Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023)

VM ENTRIES

With the exception of FS.base and GS.base, any of these MSRs is subsequently overwritten if it appears in the

VM-entry MSR-load area. See Section 27.4.

• The SMBASE register is unmodified by all VM entries except those that return from SMM.

27.3.2.2 Loading Guest Segment Registers and Descriptor-Table Registers

For each of CS, SS, DS, ES, FS, GS, TR, and LDTR, fields are loaded from the guest-state area as follows:

•

The unusable bit is loaded from the access-rights field. This bit can never be set for TR (see Section 27.3.1.2).

If it is set for one of the other registers, the following apply:

- For each of CS, SS, DS, ES, FS, and GS, uses of the segment cause faults (general-protection exception or

stack-fault exception) outside 64-bit mode, just as they would had the segment been loaded using a null

selector. This bit does not cause accesses to fault in 64-bit mode.

- If this bit is set for LDTR, uses of LDTR cause general-protection exceptions in all modes, just as they would

had LDTR been loaded using a null selector.

If this bit is clear for any of CS, SS, DS, ES, FS, GS, TR, and LDTR, a null selector value does not cause a fault

(general-protection exception or stack-fault exception).

•

TR. The selector, base, limit, and access-rights fields are loaded.

•

CS.

- The following fields are always loaded: selector, base address, limit, and (from the access-rights field) the

L, D, and G bits.

- For the other fields, the unusable bit of the access-rights field is consulted:

• If the unusable bit is 0, all of the access-rights field is loaded.

• If the unusable bit is 1, the remainder of CS access rights are undefined after VM entry.

•

SS, DS, ES, FS, GS, and LDTR.

- The selector fields are loaded.

- For the other fields, the unusable bit of the corresponding access-rights field is consulted:

• If the unusable bit is 0, the base-address, limit, and access-rights fields are loaded.

• If the unusable bit is 1, the base address, the segment limit, and the remainder of the access rights are

undefined after VM entry with the following exceptions:

- Bits 3:0 of the base address for SS are cleared to 0.

- SS.DPL is always loaded from the SS access-rights field. This will be the current privilege level

(CPL) after the VM entry completes.

- SS.B is always set to 1.

- The base addresses for FS and GS are loaded from the corresponding fields in the VMCS. On

processors that support Intel 64 architecture, the values loaded for base addresses for FS and GS

are also manifest in the FS.base and GS.base MSRs.

- On processors that support Intel 64 architecture, the base address for LDTR is set to an undefined

but canonical value.

- On processors that support Intel 64 architecture, bits 63:32 of the base addresses for SS, DS, and

ES are cleared to 0.

GDTR and IDTR are loaded using the base and limit fields.

27.3.2.3 Loading Guest RIP, RSP, RFLAGS, and SSP

RSP, RIP, and RFLAGS are loaded from the RSP field, the RIP field, and the RFLAGS field, respectively.

If the “load CET” VM-entry control is 1, SSP (shadow-stack pointer) is loaded from the SSP field.

The following items regard the upper 32 bits of these fields on VM entries that are not to 64-bit mode:

Vol. 3C

27-17

VM ENTRIES

• Bits 63:32 of RSP are undefined outside 64-bit mode. Thus, a logical processor may ignore the contents of

bits 63:32 of the RSP field on VM entries that are not to 64-bit mode.

• As noted in Section 27.3.1.4, bits 63:32 of the RIP and RFLAGS fields must be 0 on VM entries that are not to

64-bit mode. (The same is true for SSP for VM entries that are not to 64-bit mode when the “load CET” VM-

entry control is 1.)

27.3.2.4 Loading Page-Directory-Pointer-Table Entries

As noted in Section 27.3.1.6, the logical processor uses PAE paging if CR0.PG = 1, CR4.PAE = 1, and

IA32_EFER.LME = 0. A VM entry to a guest that uses PAE paging loads the PDPTEs into internal, non-architectural

registers based on the setting of the “enable EPT” VM-execution control:

• If the control is 0, the PDPTEs are loaded from the page-directory-pointer table referenced by the physical

address in the value of CR3 being loaded by the VM entry (see Section 27.3.2.1). The values loaded are treated

as physical addresses in VMX non-root operation.

• If the control is 1, the PDPTEs are loaded from corresponding fields in the guest-state area (see Section

25.4.2). The values loaded are treated as guest-physical addresses in VMX non-root operation.

27.3.2.5 Updating Non-Register State

Section 29.4 describes how the VMX architecture controls how a logical processor manages information in the TLBs

and paging-structure caches. The following items detail how VM entries invalidate cached mappings:

• If the “enable VPID” VM-execution control is 0, the logical processor invalidates 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).

• VM entries are not required to invalidate any guest-physical mappings, nor are they required to invalidate any

linear mappings or combined mappings if the “enable VPID” VM-execution control is 1.

If the “virtual-interrupt delivery” VM-execution control is 1, VM entry loads the values of RVI and SVI from the

guest interrupt-status field in the VMCS (see Section 25.4.2). After doing so, the logical processor first causes PPR

virtualization (Section 30.1.3) and then evaluates pending virtual interrupts (Section 30.2.1).

If a virtual interrupt is recognized, it may be delivered in VMX non-root operation immediately after VM entry

(including any specified event injection) completes; see Section 27.7.5. See Section 30.2.2 for details regarding

the delivery of virtual interrupts.

27.3.3 Clearing Address-Range Monitoring

The Intel 64 and IA-32 architectures allow software to monitor a specified address range using the MONITOR and

MWAIT instructions. See Section 9.10.4 in the Intel^®64 and IA-32 Architectures Software Developer’s Manual,

Volume 3A. VM entries clear any address-range monitoring that may be in effect.

27.4

LOADING MSRS

VM entries may load MSRs from the VM-entry MSR-load area (see Section 25.8.2). Specifically each entry in that

area (up to the number specified in the VM-entry MSR-load count) is processed in order by loading the MSR indexed

by bits 31:0 with the contents of bits 127:64 as they would be written by WRMSR.¹

Processing of an entry fails in any of the following cases:

• The value of bits 31:0 is either C0000100H (the IA32_FS_BASE MSR) or C0000101 (the IA32_GS_BASE MSR).

• The value of bits 31:8 is 000008H, meaning that the indexed MSR is one that allows access to an APIC register

when the local APIC is in x2APIC mode.

1. Because attempts to modify the value of IA32_EFER.LMA by WRMSR are ignored, attempts to modify it using the VM-entry MSR-

load area are also ignored.

27-18

Vol. 3C

VM ENTRIES

• The value of bits 31:0 indicates an MSR that can be written only in system-management mode (SMM) and the

VM entry did not commence in SMM. (IA32_SMM_MONITOR_CTL is an MSR that can be written only in SMM.)

• The value of bits 31:0 indicates an MSR that cannot be loaded on VM entries for model-specific reasons. A

processor may prevent loading of certain MSRs even if they can normally be written by WRMSR. Such model-

specific behavior is documented in Chapter 2, “Model-Specific Registers (MSRs),” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 4.

• Bits 63:32 are not all 0.

• An attempt to write bits 127:64 to the MSR indexed by bits 31:0 of the entry would cause a general-protection

exception if executed via WRMSR with CPL = 0.¹

The VM entry fails if processing fails for any entry. The logical processor responds to such failures by loading state

from the host-state area, as it would for a VM exit. See Section 27.8.

If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so

that, after VM entry, the logical processor will not use any translations that were cached before the transition.

27.5

TRACE-ADDRESS PRE-TRANSLATION (TAPT)

When the “Intel PT uses guest physical addresses” VM-execution control is 1, the addresses used by Intel PT are

treated as guest-physical addresses, and these are translated to physical addresses using EPT.

VM entry uses trace-address pre-translation (TAPT) to prevent buffered trace data from being lost due to an

EPT violation; see Section 26.5.4.2. VM entry uses TAPT only if Intel PT will be enabled following VM entry

(IA32_RTIT_CTL.TraceEn = 1) and only if the “Intel PT uses guest physical addresses” VM-execution control is 1

As noted in Section 26.5.4, TAPT may cause a VM exit due to an EPT violation, EPT misconfiguration, page-modifi-

cation log-full event, or APIC access. If such a VM exit occurs as a result of TAPT during VM entry, the VM exit oper-

ates as if it had occurred in VMX non-root operation after the VM entry completed (in the guest context).

If TAPT during VM entry causes a VM exit, the VM entry does not perform event injection (Section 27.6), even if the

valid bit in the VM-entry interruption-information field is 1. Such VM exits save the contents of VM-entry interrup-

tion-information and VM-entry exception error code fields into the IDT-vectoring information and IDT-vectoring

error code fields, respectively.

27.6

EVENT INJECTION

If the valid bit in the VM-entry interruption-information field (see Section 25.8.3) is 1, VM entry causes an event to

be delivered (or made pending) after all components of guest state have been loaded (including MSRs) and after

the VM-execution control fields have been established.

• If the interruption type in the field is 0 (external interrupt), 2 (non-maskable interrupt); 3 (hardware

exception), 4 (software interrupt), 5 (privileged software exception), or 6 (software exception), the event is

delivered as described in Section 27.6.1.

• If the interruption type in the field is 7 (other event) and the vector field is 0, an MTF VM exit is pending after

VM entry. See Section 27.6.2.

27.6.1 Vectored-Event Injection

VM entry delivers an injected vectored event within the guest context established by VM entry. This means that

delivery occurs after all components of guest state have been loaded (including MSRs) and after the VM-execution

control fields have been established.² The event is delivered using the vector in that field to select a descriptor in

the IDT. Since event injection occurs after loading IDTR from the guest-state area, this is the guest IDT.

1. If CR0.PG = 1, WRMSR to the IA32_EFER MSR causes a general-protection exception if it would modify the LME bit. If VM entry has

established CR0.PG = 1, the IA32_EFER MSR should not be included in the VM-entry MSR-load area for the purpose of modifying the

LME bit.

Vol. 3C

27-19

VM ENTRIES

Section 27.6.1.1 provides details of vectored-event injection. In general, the event is delivered exactly as if it had

been generated normally.

An exception is made if the following all hold: bit 25 (UINTR) is set to 1 in the guest CR4 field and the “IA-32e mode

guest” VM-entry control is 1, and VM entry is modified if it is injecting an external interrupt whose vector is the

value that UINV would have after VM entry. In this case, the logical processor then performs user-interrupt notifi-

cation processing as specified in Section 7.5.2 instead of the process described in Section 27.6.1.1. (If the guest

activity-state field indicated the HLT state, the logical processor enters the HLT state following user-interrupt noti-

fication processing.)

If event delivery (or user-interrupt notification processing; see above) encounters a nested exception (for

example, a general-protection exception because the vector indicates a descriptor beyond the IDT limit), the

exception bitmap is consulted using the vector of that exception:

• If the bit for the nested exception is 0, the nested exception is delivered normally. If the nested exception is

benign, it is delivered through the IDT. If it is contributory or a page fault, a double fault may be generated,

depending on the nature of the event whose delivery encountered the nested exception. See Chapter 6,

“Interrupt 8-Double Fault Exception (#DF)” in the Intel^®64 and IA-32 Architectures Software Developer’s

Manual, Volume 3A.¹

• If the bit for the nested exception is 1, a VM exit occurs. Section 27.6.1.2 details cases in which event injection

causes a VM exit.

27.6.1.1 Details of Vectored-Event Injection

The event-injection process is controlled by the contents of the VM-entry interruption information field (format

given in Table 25-17), the VM-entry exception error-code field, and the VM-entry instruction-length field. The

following items provide details of the process:

• The value pushed on the stack for RFLAGS is generally that which was loaded from the guest-state area. The

value pushed for the RF flag is not modified based on the type of event being delivered. However, the pushed

value of RFLAGS may be modified if a software interrupt is being injected into a guest that will be in virtual-

8086 mode (see below). After RFLAGS is pushed on the stack, the value in the RFLAGS register is modified as

is done normally when delivering an event through the IDT.

• The instruction pointer that is pushed on the stack depends on the type of event and whether nested exceptions

occur during its delivery. The term current guest RIP refers to the value to be loaded from the guest-state

area. The value pushed is determined as follows:²

- If VM entry successfully injects (with no nested exception) an event with interruption type external

interrupt, NMI, or hardware exception, the current guest RIP is pushed on the stack.

- If VM entry successfully injects (with no nested exception) an event with interruption type software

interrupt, privileged software exception, or software exception, the current guest RIP is incremented by the

VM-entry instruction length before being pushed on the stack.

- If VM entry encounters an exception while injecting an event and that exception does not cause a VM exit,

the current guest RIP is pushed on the stack regardless of event type or VM-entry instruction length. If the

encountered exception does cause a VM exit that saves RIP, the saved RIP is current guest RIP.

• If the deliver-error-code bit (bit 11) is set in the VM-entry interruption-information field, the contents of the

VM-entry exception error-code field is pushed on the stack as an error code would be pushed during delivery of

an exception.

• DR6, DR7, and the IA32_DEBUGCTL MSR are not modified by event injection, even if the event has vector 1

(normal deliveries of debug exceptions, which have vector 1, do update these registers).

2. This does not imply that injection of an exception or interrupt will cause a VM exit due to the settings of VM-execution control fields

(such as the exception bitmap) that would cause a VM exit if the event had occurred in VMX non-root operation. In contrast, a nested

exception encountered during event delivery may cause a VM exit; see Section 27.6.1.1.

1. Hardware exceptions with the following unused vectors are considered benign: 15 and 21-31. A hardware exception with vector 20

is considered benign unless the processor supports the 1-setting of the “EPT-violation #VE” VM-execution control; in that case, it

has the same severity as page faults.

2. While these items refer to RIP, the width of the value pushed (16 bits, 32 bits, or 64 bits) is determined normally.

27-20

Vol. 3C

VM ENTRIES

•

If VM entry is injecting a software interrupt and the guest will be in virtual-8086 mode (RFLAGS.VM = 1), no

general-protection exception can occur due to RFLAGS.IOPL < 3. A VM monitor should check RFLAGS.IOPL

before injecting such an event and, if desired, inject a general-protection exception instead of a software

interrupt.

•

If VM entry is injecting a software interrupt and the guest will be in virtual-8086 mode with virtual-8086 mode

extensions (RFLAGS.VM = CR4.VME = 1), event delivery is subject to VME-based interrupt redirection based

on the software interrupt redirection bitmap in the task-state segment (TSS) as follows:

- If bit n in the bitmap is clear (where n is the number of the software interrupt), the interrupt is directed to

an 8086 program interrupt handler: the processor uses a 16-bit interrupt-vector table (IVT) located at

linear address zero. If the value of RFLAGS.IOPL is less than 3, the following modifications are made to the

value of RFLAGS that is pushed on the stack: IOPL is set to 3, and IF is set to the value of VIF.

- If bit n in the bitmap is set (where n is the number of the software interrupt), the interrupt is directed to a

protected-mode interrupt handler. (In other words, the injection is treated as described in the next item.)

In this case, the software interrupt does not invoke such a handler if RFLAGS.IOPL < 3 (a general-

protection exception occurs instead). However, as noted above, RFLAGS.IOPL cannot cause an injected

software interrupt to cause such a exception. Thus, in this case, the injection invokes a protected-mode

interrupt handler independent of the value of RFLAGS.IOPL.

Injection of events of other types are not subject to this redirection.

•

If VM entry is injecting a software interrupt (not redirected as described above) or software exception, privilege

checking is performed on the IDT descriptor being accessed as would be the case for executions of INT n, INT3,

or INTO (the descriptor’s DPL cannot be less than CPL). There is no checking of RFLAGS.IOPL, even if the guest

will be in virtual-8086 mode. Failure of this check may lead to a nested exception. Injection of an event with

interruption type external interrupt, NMI, hardware exception, and privileged software exception, or with inter-

ruption type software interrupt and being redirected as described above, do not perform these checks.

•

If VM entry is injecting a non-maskable interrupt (NMI) and the “virtual NMIs” VM-execution control is 1,

virtual-NMI blocking is in effect after VM entry.

•

The transition causes a last-branch record to be logged if the LBR bit is set in the IA32_DEBUGCTL MSR. This is

true even for events such as debug exceptions, which normally clear the LBR bit before delivery.

•

The last-exception record MSRs (LERs) may be updated based on the setting of the LBR bit in the

IA32_DEBUGCTL MSR. Events such as debug exceptions, which normally clear the LBR bit before they are

delivered, and therefore do not normally update the LERs, may do so as part of VM-entry event injection.

•

If injection of an event encounters a nested exception, the value of the EXT bit (bit 0) in any error code for that

nested exception is determined as follows:

- If event being injected has interruption type external interrupt, NMI, hardware exception, or privileged

software exception and encounters a nested exception (but does not produce a double fault), the error code

for that exception sets the EXT bit.

- If event being injected is a software interrupt or a software exception and encounters a nested exception,

the error code for that exception clears the EXT bit.

- If event delivery encounters a nested exception and delivery of that exception encounters another

exception (but does not produce a double fault), the error code for that exception sets the EXT bit.

- If a double fault is produced, the error code for the double fault is 0000H (the EXT bit is clear).

27.6.1.2 VM Exits During Event Injection

An event being injected never causes a VM exit directly regardless of the settings of the VM-execution controls. For

example, setting the “NMI exiting” VM-execution control to 1 does not cause a VM exit due to injection of an NMI.

However, the event-delivery process may lead to a VM exit:

• If the vector in the VM-entry interruption-information field identifies a task gate in the IDT, the attempted task

switch may cause a VM exit just as it would had the injected event occurred during normal execution in VMX

non-root operation (see Section 26.4.2).

• If event delivery encounters a nested exception, a VM exit may occur depending on the contents of the

exception bitmap (see Section 26.2).

Vol. 3C

27-21

VM ENTRIES

• If event delivery generates a double-fault exception (due to a nested exception); the logical processor

encounters another nested exception while attempting to call the double-fault handler; and that exception does

not cause a VM exit due to the exception bitmap; then a VM exit occurs due to triple fault (see Section 26.2).

• If event delivery injects a double-fault exception and encounters a nested exception that does not cause a

VM exit due to the exception bitmap, then a VM exit occurs due to triple fault (see Section 26.2).

• If the “virtualize APIC accesses” VM-execution control is 1 and event delivery generates an access to the APIC-

access page, that access is treated as described in Section 30.4 and may cause a VM exit.¹

If the event-delivery process does cause a VM exit, the processor state before the VM exit is determined just as it

would be had the injected event occurred during normal execution in VMX non-root operation. If the injected event

directly accesses a task gate that cause a VM exit or if the first nested exception encountered causes a VM exit,

information about the injected event is saved in the IDT-vectoring information field (see Section 28.2.4).

The material in this section applies also if injection of an external interrupt results in user-interrupt notification

processing instead of event delivery (see Section 27.6.1 earlier).

27.6.1.3 Event Injection for VM Entries to Real-Address Mode

If VM entry is loading CR0.PE with 0, any injected vectored event is delivered as would normally be done in real-

address mode.² Specifically, VM entry uses the vector provided in the VM-entry interruption-information field to

select a 4-byte entry from an interrupt-vector table at the linear address in IDTR.base. Further details are provided

in Section 15.1.4 in the Intel^®64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.

Because bit 11 (deliver error code) in the VM-entry interruption-information field must be 0 if CR0.PE will be 0 after

VM entry (see Section 27.2.1.3), vectored events injected with CR0.PE = 0 do not push an error code on the stack.

This is consistent with event delivery in real-address mode.

If event delivery encounters a fault (due to a violation of IDTR.limit or of SS.limit), the fault is treated as if it had

occurred during event delivery in VMX non-root operation. Such a fault may lead to a VM exit as discussed in

Section 27.6.1.2.

27.6.2 Injection of Pending MTF VM Exits

If the interruption type in the VM-entry interruption-information field is 7 (other event) and the vector field is 0,

VM entry causes an MTF VM exit to be pending on the instruction boundary following VM entry. This is the case

even if the “monitor trap flag” VM-execution control is 0. See Section 26.5.2 for the treatment of pending MTF

VM exits.

27.7

SPECIAL FEATURES OF VM ENTRY

This section details a variety of features of VM entry. It uses the following terminology: a VM entry is vectoring if

the valid bit (bit 31) of the VM-entry interruption information field is 1 and the interruption type in the field is 0

(external interrupt), 2 (non-maskable interrupt); 3 (hardware exception), 4 (software interrupt), 5 (privileged

software exception), or 6 (software exception).

27.7.1 Interruptibility State

The interruptibility-state field in the guest-state area (see Table 25-3) contains bits that control blocking by STI,

blocking by MOV SS, and blocking by NMI. This field impacts event blocking after VM entry as follows:

1. “Virtualize APIC accesses” is a secondary processor-based VM-execution control. If bit 31 of the primary processor-based VM-execu-

tion controls is 0, VM entry functions as if the “virtualize APIC accesses” VM-execution control were 0. See Section 25.6.2.

2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, VM entry must be loading CR0.PE

with 1 unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution controls are

both 1.

27-22

Vol. 3C

VM ENTRIES

•

If the VM entry is vectoring, there is no blocking by STI or by MOV SS following the VM entry, regardless of the

contents of the interruptibility-state field.

•

If the VM entry is not vectoring, the following apply:

- Events are blocked by STI if and only if bit 0 in the interruptibility-state field is 1. This blocking is cleared

after the guest executes one instruction or incurs an exception (including a debug exception made pending

by VM entry; see Section 27.7.3).

- Events are blocked by MOV SS if and only if bit 1 in the interruptibility-state field is 1. This may affect the

treatment of pending debug exceptions; see Section 27.7.3. This blocking is cleared after the guest

executes one instruction or incurs an exception (including a debug exception made pending by VM entry).

•

The blocking of non-maskable interrupts (NMIs) is determined as follows:

- If the “virtual NMIs” VM-execution control is 0, NMIs are blocked if and only if bit 3 (blocking by NMI) in the

interruptibility-state field is 1. If the “NMI exiting” VM-execution control is 0, execution of the IRET

instruction removes this blocking (even if the instruction generates a fault). If the “NMI exiting” control is

1, IRET does not affect this blocking.

- The following items describe the use of bit 3 (blocking by NMI) in the interruptibility-state field if the

“virtual NMIs” VM-execution control is 1:

• The bit’s value does not affect the blocking of NMIs after VM entry. NMIs are not blocked in VMX non-

root operation (except for ordinary blocking for other reasons, such as by the MOV SS instruction, the

wait-for-SIPI state, etc.)

• The bit’s value determines whether there is virtual-NMI blocking after VM entry. If the bit is 1, virtual-

NMI blocking is in effect after VM entry. If the bit is 0, there is no virtual-NMI blocking after VM entry

unless the VM entry is injecting an NMI (see Section 27.6.1.1). Execution of IRET removes virtual-NMI

blocking (even if the instruction generates a fault).

If the “NMI exiting” VM-execution control is 0, the “virtual NMIs” control must be 0; see Section 27.2.1.1.

•

Blocking of system-management interrupts (SMIs) is determined as follows:

- If the VM entry was not executed in system-management mode (SMM), SMI blocking is unchanged by

VM entry.

- If the VM entry was executed in SMM, SMIs are blocked after VM entry if and only if the bit 2 in the inter-

ruptibility-state field is 1.

27.7.2 Activity State

The activity-state field in the guest-state area controls whether, after VM entry, the logical processor is active or in

one of the inactive states identified in Section 25.4.2. The use of this field is determined as follows:

• If the VM entry is vectoring, the logical processor is in the active state after VM entry. While the consistency

checks described in Section 27.3.1.5 on the activity-state field do apply in this case, the contents of the

activity-state field do not determine the activity state after VM entry.

• If the VM entry is not vectoring, the logical processor ends VM entry in the activity state specified in the guest-

state area. If VM entry ends with the logical processor in an inactive activity state, the VM entry generates any

special bus cycle that is normally generated when that activity state is entered from the active state. If

VM entry would end with the logical processor in the shutdown state and the logical processor is in SMX

operation,¹ an Intel^® TXT shutdown condition occurs. The error code used is 0000H, indicating “legacy

shutdown.” See the Intel^® Trusted Execution Technology Preliminary Architecture Specification.

• Some activity states unconditionally block certain events. The following blocking is in effect after any VM entry

that puts the processor in the indicated state:

- The active state blocks start-up IPIs (SIPIs). SIPIs that arrive while a logical processor is in the active state

and in VMX non-root operation are discarded and do not cause VM exits.

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

Chapter 6, “Safer Mode Extensions Reference,” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 2B.

Vol. 3C

27-23

VM ENTRIES

- The HLT state blocks start-up IPIs (SIPIs). SIPIs that arrive while a logical processor is in the HLT state and

in VMX non-root operation are discarded and do not cause VM exits.

- The shutdown state blocks external interrupts and SIPIs. External interrupts that arrive while a logical

processor is in the shutdown state and in VMX non-root operation do not cause VM exits even if the

“external-interrupt exiting” VM-execution control is 1. SIPIs that arrive while a logical processor is in the

shutdown state and in VMX non-root operation are discarded and do not cause VM exits.

- The wait-for-SIPI state blocks external interrupts, non-maskable interrupts (NMIs), INIT signals, and

system-management interrupts (SMIs). Such events do not cause VM exits if they arrive while a logical

processor is in the wait-for-SIPI state and in VMX non-root operation.

27.7.3 Delivery of Pending Debug Exceptions after VM Entry

The pending debug exceptions field in the guest-state area indicates whether there are debug exceptions that have

not yet been delivered (see Section 25.4.2). This section describes how these are treated on VM entry.

There are no pending debug exceptions after VM entry if any of the following are true:

• The VM entry is vectoring with one of the following interruption types: external interrupt, non-maskable

interrupt (NMI), hardware exception, or privileged software exception.

• The interruptibility-state field does not indicate blocking by MOV SS and the VM entry is vectoring with either of

the following interruption type: software interrupt or software exception.

• The VM entry is not vectoring and the activity-state field indicates either shutdown or wait-for-SIPI.

If none of the above hold, the pending debug exceptions field specifies the debug exceptions that are pending for

the guest. There are valid pending debug exceptions if either the BS bit (bit 14) or the enable-breakpoint bit

(bit 12) is 1. If there are valid pending debug exceptions, they are handled as follows:

• If the VM entry is not vectoring, the pending debug exceptions are treated as they would had they been

encountered normally in guest execution:

- If the logical processor is not blocking such exceptions (the interruptibility-state field indicates no blocking

by MOV SS), a debug exception is delivered after VM entry (see below).

- If the logical processor is blocking such exceptions (due to blocking by MOV SS), the pending debug

exceptions are held pending or lost as would normally be the case.

• If the VM entry is vectoring (with interruption type software interrupt or software exception and with blocking

by MOV SS), the following items apply:

- For injection of a software interrupt or of a software exception with vector 3 (#BP) or vector 4 (#OF) - or

a privileged software exception with vector 1 (#DB) - the pending debug exceptions are treated as they

would had they been encountered normally in guest execution if the corresponding instruction (INT1, INT3,

or INTO) were executed after a MOV SS that encountered a debug trap.

- For injection of a software exception with a vector other than 3 and 4, the pending debug exceptions may

be lost or they may be delivered after injection (see below).

If there are no valid pending debug exceptions (as defined above), no pending debug exceptions are delivered after

VM entry.

If a pending debug exception is delivered after VM entry, it has the priority of “traps on the previous instruction”

(see Section 6.9 in the Intel^®64 and IA-32 Architectures Software Developer’s Manual, Volume 3A). Thus, INIT

signals and system-management interrupts (SMIs) take priority of such an exception, as do VM exits induced by

the TPR threshold (see Section 27.7.7) and pending MTF VM exits (see Section 27.7.8. The exception takes priority

over any pending non-maskable interrupt (NMI) or external interrupt and also over VM exits due to the 1-settings

of the “interrupt-window exiting” and “NMI-window exiting” VM-execution controls.

A pending debug exception delivered after VM entry causes a VM exit if the bit 1 (#DB) is 1 in the exception

bitmap. If it does not cause a VM exit, it updates DR6 normally.

27-24

Vol. 3C

VM ENTRIES

27.7.4 VMX-Preemption Timer

If the “activate VMX-preemption timer” VM-execution control is 1, VM entry starts the VMX-preemption timer with

the unsigned value in the VMX-preemption timer-value field.

It is possible for the VMX-preemption timer to expire during VM entry (e.g., if the value in the VMX-preemption

timer-value field is zero). If this happens (and if the VM entry was not to the wait-for-SIPI state), a VM exit occurs

with its normal priority after any event injection and before execution of any instruction following VM entry. For

example, any pending debug exceptions established by VM entry (see Section 27.7.3) take priority over a timer-

induced VM exit. (The timer-induced VM exit will occur after delivery of the debug exception, unless that exception

or its delivery causes a different VM exit.)

See Section 26.5.1 for details of the operation of the VMX-preemption timer in VMX non-root operation, including

the blocking and priority of the VM exits that it causes.

27.7.5 Interrupt-Window Exiting and Virtual-Interrupt Delivery

If “interrupt-window exiting” VM-execution control is 1, an open interrupt window may cause a VM exit immedi-

ately after VM entry (see Section 26.2 for details). If the “interrupt-window exiting” VM-execution control is 0 but

the “virtual-interrupt delivery” VM-execution control is 1, a virtual interrupt may be delivered immediately after

VM entry (see Section 27.3.2.5 and Section 30.2.1).

The following items detail the treatment of these events:

• These events occur after any event injection specified for VM entry.

• Non-maskable interrupts (NMIs) and higher priority events take priority over these events. These events take

priority over external interrupts and lower priority events.

• These events wake the logical processor if it just entered the HLT state because of a VM entry (see Section

27.7.2). They do not occur if the logical processor just entered the shutdown state or the wait-for-SIPI state.

27.7.6 NMI-Window Exiting

The “NMI-window exiting” VM-execution control may cause a VM exit to occur immediately after VM entry (see

Section 26.2 for details).

The following items detail the treatment of these VM exits:

• These VM exits follow event injection if such injection is specified for VM entry.

• Debug-trap exceptions (see Section 27.7.3) and higher priority events take priority over VM exits caused by

this control. VM exits caused by this control take priority over non-maskable interrupts (NMIs) and lower

priority events.

• VM exits caused by this control wake the logical processor if it just entered either the HLT state or the shutdown

state because of a VM entry (see Section 27.7.2). They do not occur if the logical processor just entered the

wait-for-SIPI state.

27.7.7 VM Exits Induced by the TPR Threshold

If the “use TPR shadow” and “virtualize APIC accesses” VM-execution controls are both 1 and the “virtual-interrupt

delivery” VM-execution control is 0, a VM exit occurs immediately after VM entry if the value of bits 3:0 of the TPR

threshold VM-execution control field is greater than the value of bits 7:4 of VTPR (see Section 30.1.1).¹

The following items detail the treatment of these VM exits:

• The VM exits are not blocked if RFLAGS.IF = 0 or by the setting of bits in the interruptibility-state field in guest-

state area.

• The VM exits follow event injection if such injection is specified for VM entry.

1. “Virtualize APIC accesses” and “virtual-interrupt delivery” are secondary processor-based VM-execution controls. If bit 31 of the pri-

mary processor-based VM-execution controls is 0, VM entry functions as if these controls were 0. See Section 25.6.2.

Vol. 3C

27-25

VM ENTRIES

• VM exits caused by this control take priority over system-management interrupts (SMIs), INIT signals, and

lower priority events. They thus have priority over the VM exits described in Section 27.7.5, Section 27.7.6,

and Section 27.7.8, as well as any interrupts or debug exceptions that may be pending at the time of VM entry.

• These VM exits wake the logical processor if it just entered the HLT state as part of a VM entry (see Section

27.7.2). They do not occur if the logical processor just entered the shutdown state or the wait-for-SIPI state.

If such a VM exit is suppressed because the processor just entered the shutdown state, it occurs after the

delivery of any event that cause the logical processor to leave the shutdown state while remaining in VMX

non-root operation (e.g., due to an NMI that occurs while the “NMI-exiting” VM-execution control is 0).

• The basic exit reason is “TPR below threshold.”

27.7.8 Pending MTF VM Exits

As noted in Section 27.6.2, VM entry may cause an MTF VM exit to be pending immediately after VM entry. The

following items detail the treatment of these VM exits:

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

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

• These VM exits wake the logical processor if it just entered the HLT state because of a VM entry (see Section

27.7.2). They do not occur if the logical processor just entered the shutdown state or the wait-for-SIPI state.

27.7.9 VM Entries and Advanced Debugging Features

VM entries are not logged with last-branch records, do not produce branch-trace messages, and do not update the

branch-trace store.

27.7.10 User-Interrupt Recognition After VM Entry

A VM entry results in recognition of a pending user interrupt if it completes with CR4.UINTR = IA32_EFER.LMA = 1

and with UIRR ≠ 0; otherwise, no pending user interrupt is recognized.

27.8

VM-ENTRY FAILURES DURING OR AFTER LOADING GUEST STATE

VM-entry failures due to the checks identified in Section 27.3.1 and failures during the MSR loading identified in

Section 27.4 are treated differently from those that occur earlier in VM entry. In these cases, the following steps

take place:

1. Information about the VM-entry failure is recorded in the VM-exit information fields:

- Exit reason.

• Bits 15:0 of this field contain the basic exit reason. It is loaded with a number indicating the general

cause of the VM-entry failure. The following numbers are used:

33. VM-entry failure due to invalid guest state. A VM entry failed one of the checks identified in Section

27.3.1.

34. VM-entry failure due to MSR loading. A VM entry failed in an attempt to load MSRs (see Section

27.4).

41. VM-entry failure due to machine-check event. A machine-check event occurred during VM entry

(see Section 27.9).

• Bit 31 is set to 1 to indicate a VM-entry failure.

• The remainder of the field (bits 30:16) is cleared.

27-26

Vol. 3C

VM ENTRIES

- Exit qualification. This field is set based on the exit reason.

• VM-entry failure due to invalid guest state. In most cases, the exit qualification is cleared to 0. The

following non-zero values are used in the cases indicated:

1. Not used.

2. Failure was due to a problem loading the PDPTEs (see Section 27.3.1.6).

3. Failure was due to an attempt to inject a non-maskable interrupt (NMI) into a guest that is blocking

events through the STI blocking bit in the interruptibility-state field.

4. Failure was due to an invalid VMCS link pointer (see Section 27.3.1.5).

VM-entry checks on guest-state fields may be performed in any order. Thus, an indication by exit

qualification of one cause does not imply that there are not also other errors. Different processors

may give different exit qualifications for the same VMCS.

• VM-entry failure due to MSR loading. The exit qualification is loaded to indicate which entry in the

VM-entry MSR-load area caused the problem (1 for the first entry, 2 for the second, etc.).

- All other VM-exit information fields are unmodified.

2. Processor state is loaded as would be done on a VM exit (see Section 28.5). If this results in

[CR4.PAE & CR0.PG & ~IA32_EFER.LMA] = 1, page-directory-pointer-table entries (PDPTEs) may be checked

and loaded (see Section 28.5.4).

3. The state of blocking by NMI is what it was before VM entry.

4. MSRs are loaded as specified in the VM-exit MSR-load area (see Section 28.6).

Although this process resembles that of a VM exit, many steps taken during a VM exit do not occur for these

VM-entry failures:

• Most VM-exit information fields are not updated (see step 1 above).

• The valid bit in the VM-entry interruption-information field is not cleared.

• The guest-state area is not modified.

• No MSRs are saved into the VM-exit MSR-store area.

27.9

MACHINE-CHECK EVENTS DURING VM ENTRY

If a machine-check event occurs during a VM entry, one of the following occurs:

• The machine-check event is handled as if it occurred before the VM entry:

- If CR4.MCE = 0, operation of the logical processor depends on whether the logical processor is in SMX

operation:¹

• If the logical processor is in SMX operation, an Intel^® TXT shutdown condition occurs. The error code

used is 000CH, indicating “unrecoverable machine-check condition.”

• If the logical processor is outside SMX operation, it goes to the shutdown state.

- If CR4.MCE = 1, a machine-check exception (#MC) is delivered through the IDT.

• The machine-check event is handled after VM entry completes:

- If the VM entry ends with CR4.MCE = 0, operation of the logical processor depends on whether the logical

processor is in SMX operation:

• If the logical processor is in SMX operation, an Intel^® TXT shutdown condition occurs with error code

000CH (unrecoverable machine-check condition).

• If the logical processor is outside SMX operation, it goes to the shutdown state.

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

27-27

CHAPTER 28

VM EXITS

VM exits occur in response to certain instructions and events in VMX non-root operation as detailed in Section 26.1

through Section 26.2. VM exits perform the following operations:

1. Information about the cause of the VM exit is recorded in the VM-exit information fields and VM-entry control

fields are modified as described in Section 28.2.

2. Processor state is saved in the guest-state area (Section 28.3).

3. MSRs may be saved in the VM-exit MSR-store area (Section 28.4). This step is not performed for SMM VM exits

that activate the dual-monitor treatment of SMIs and SMM.

4. The following may be performed in parallel and in any order (Section 28.5):

- Processor state is loaded based in part on the host-state area and some VM-exit controls. This step is not

performed for SMM VM exits that activate the dual-monitor treatment of SMIs and SMM. See Section

32.15.6 for information on how processor state is loaded by such VM exits.

- Address-range monitoring is cleared.

5. MSRs may be loaded from the VM-exit MSR-load area (Section 28.6). This step is not performed for SMM

VM exits that activate the dual-monitor treatment of SMIs and SMM.

VM exits are not logged with last-branch records, do not produce branch-trace messages, and do not update the

branch-trace store.

Section 28.1 clarifies the nature of the architectural state before a VM exit begins. The steps described above are

detailed in Section 28.2 through Section 28.6.

Section 32.15 describes the dual-monitor treatment of system-management interrupts (SMIs) and system-

management mode (SMM). Under this treatment, ordinary transitions to SMM are replaced by VM exits to a sepa-

rate SMM monitor. Called SMM VM exits, these are caused by the arrival of an SMI or the execution of VMCALL in

VMX root operation. SMM VM exits differ from other VM exits in ways that are detailed in Section 32.15.2.

28.1

ARCHITECTURAL STATE BEFORE A VM EXIT

This section describes the architectural state that exists before a VM exit, especially for VM exits caused by events

that would normally be delivered through the IDT. Note the following:

• An exception causes a VM exit directly if the bit corresponding to that exception is set in the exception bitmap.

A non-maskable interrupt (NMI) causes a VM exit directly if the “NMI exiting” VM-execution control is 1. An

external interrupt causes a VM exit directly if the “external-interrupt exiting” VM-execution control is 1. A start-

up IPI (SIPI) that arrives while a logical processor is in the wait-for-SIPI activity state causes a VM exit directly.

INIT signals that arrive while the processor is not in the wait-for-SIPI activity state cause VM exits directly.

• An exception, NMI, external interrupt, or software interrupt causes a VM exit indirectly if it does not do so

directly but delivery of the event causes a nested exception, double fault, task switch, APIC access (see Section

30.4), EPT violation, EPT misconfiguration, page-modification log-full event (see Section 29.3.6), or SPP-

related event (see Section 29.3.4) that causes a VM exit.

• An event results in a VM exit if it causes a VM exit (directly or indirectly).

The following bullets detail when architectural state is and is not updated in response to VM exits:

• If an event causes a VM exit directly, it does not update architectural state as it would have if it had it not

caused the VM exit:

- A debug exception does not update DR6, DR7, or IA32_DEBUGCTL. (Information about the nature of the

debug exception is saved in the exit qualification field.)

- A page fault does not update CR2. (The linear address causing the page fault is saved in the exit-qualifi-

cation field.)

Vol. 3C

28-1

VM EXITS

- An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes.

- An external interrupt does not acknowledge the interrupt controller and the interrupt remains pending,

unless the “acknowledge interrupt on exit” VM-exit control is 1. In such a case, the interrupt controller is

acknowledged and the interrupt is no longer pending.

- The flags L0 - L3 in DR7 (bit 0, bit 2, bit 4, and bit 6) are not cleared when a task switch causes a VM exit.

- If a task switch causes a VM exit, none of the following are modified by the task switch: old task-state

segment (TSS); new TSS; old TSS descriptor; new TSS descriptor; RFLAGS.NT¹; or the TR register.

- No last-exception record is made if the event that would do so directly causes a VM exit.

- If a machine-check exception causes a VM exit directly, this does not prevent machine-check MSRs from

being updated. These are updated by the machine-check event itself and not the resulting machine-check

exception.

- If the logical processor is in an inactive state (see Section 25.4.2) and not executing instructions, some

events may be blocked but others may return the logical processor to the active state. Unblocked events

may cause VM exits.² If an unblocked event causes a VM exit directly, a return to the active state occurs

only after the VM exit completes.³ The VM exit generates any special bus cycle that is normally generated

when the active state is entered from that activity state.

MTF VM exits (see Section 26.5.2 and Section 27.7.8) are not blocked in the HLT activity state. If an MTF

VM exit occurs in the HLT activity state, the logical processor returns to the active state only after the

VM exit completes. MTF VM exits are blocked the shutdown state and the wait-for-SIPI state.

• If an event causes a VM exit indirectly, the event does update architectural state:

- A debug exception updates DR6, DR7, and the IA32_DEBUGCTL MSR. No debug exceptions are considered

pending.

- A page fault updates CR2.

- An NMI causes subsequent NMIs to be blocked before the VM exit commences.

- An external interrupt acknowledges the interrupt controller and the interrupt is no longer pending.

- If the logical processor had been in an inactive state, it enters the active state and, before the VM exit

commences, generates any special bus cycle that is normally generated when the active state is entered

from that activity state.

- There is no blocking by STI or by MOV SS when the VM exit commences.

- Processor state that is normally updated as part of delivery through the IDT (CS, RIP, SS, RSP, RFLAGS) is

not modified. However, the incomplete delivery of the event may write to the stack.

- The treatment of last-exception records is implementation dependent:

• Some processors make a last-exception record when beginning the delivery of an event through the IDT

(before it can encounter a nested exception). Such processors perform this update even if the event

encounters a nested exception that causes a VM exit (including the case where nested exceptions lead

to a triple fault).

• Other processors delay making a last-exception record until event delivery has reached some event

handler successfully (perhaps after one or more nested exceptions). Such processors do not update the

last-exception record if a VM exit or triple fault occurs before an event handler is reached.

1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-

ation also support Intel 64 architecture. For processors that do not support Intel 64 architecture, this notation refers to the 32-bit

forms of those registers (EAX, EIP, ESP, EFLAGS, etc.). In a few places, notation such as EAX is used to refer specifically to lower 32

bits of the indicated register.

2. If a VM exit takes the processor from an inactive state resulting from execution of a specific instruction (HLT or MWAIT), the value

saved for RIP by that VM exit will reference the following instruction.

3. An exception is made if the logical processor had been inactive due to execution of MWAIT; in this case, it is considered to have

become active before the VM exit.

28-2

Vol. 3C

VM EXITS

•

If the “virtual NMIs” VM-execution control is 1, VM entry injects an NMI, and delivery of the NMI causes a

nested exception, double fault, task switch, EPT violation, EPT misconfiguration, page-modification log-full

event, or SPP-related event, or APIC access that causes a VM exit, virtual-NMI blocking is in effect before the

VM exit commences.

•

If a VM exit results from a fault, EPT violation, EPT misconfiguration, page-modification log-full event, or SPP-

related event that is encountered during execution of IRET and the “NMI exiting” VM-execution control is 0, any

blocking by NMI is cleared before the VM exit commences. However, the previous state of blocking by NMI may

be recorded in the exit qualification or in the VM-exit interruption-information field; see Section 28.2.3.

•

If a VM exit results from a fault, EPT violation, EPT misconfiguration, page-modification log-full event, or SPP-

related event that is encountered during execution of IRET and the “virtual NMIs” VM-execution control is 1,

virtual-NMI blocking is cleared before the VM exit commences. However, the previous state of blocking by NMI

may be recorded in the exit qualification or in the VM-exit interruption-information field; see Section 28.2.3.

•

Suppose that a VM exit is caused directly by an x87 FPU Floating-Point Error (#MF) or by any of the following

events if the event was unblocked due to (and given priority over) an x87 FPU Floating-Point Error: an INIT

signal, an external interrupt, an NMI, an SMI; or a machine-check exception. In these cases, there is no

blocking by STI or by MOV SS when the VM exit commences.

•

Normally, a last-branch record may be made when an event is delivered through the IDT. However, if such an

event results in a VM exit before delivery is complete, no last-branch record is made.

•

If machine-check exception results in a VM exit, processor state is suspect and may result in suspect state

being saved to the guest-state area. A VM monitor should consult the RIPV and EIPV bits in the

IA32_MCG_STATUS MSR before resuming a guest that caused a VM exit resulting from a machine-check

exception.

•

If a VM exit results from a fault, APIC access (see Section 30.4), EPT violation, EPT misconfiguration, page-

modification log-full event, or SPP-related event that is encountered while executing an instruction, data

breakpoints due to that instruction may have been recognized and information about them may be saved in the

pending debug exceptions field (unless the VM exit clears that field; see Section 28.3.4).

•

The following VM exits are considered to happen after an instruction is executed:

- VM exits resulting from debug traps (single-step, I/O breakpoints, and data breakpoints).

- VM exits resulting from debug exceptions (data breakpoints) whose recognition was delayed by blocking by

MOV SS.

- VM exits resulting from some machine-check exceptions.

- Trap-like VM exits due to execution of MOV to CR8 when the “CR8-load exiting” VM-execution control is 0

and the “use TPR shadow” VM-execution control is 1 (see Section 30.3). (Such VM exits can occur only from

64-bit mode and thus only on processors that support Intel 64 architecture.)

- Trap-like VM exits due to execution of WRMSR when the “use MSR bitmaps” VM-execution control is 1; the

value of ECX is in the range 800H-8FFH; and the bit corresponding to the ECX value in write bitmap for low

MSRs is 0; and the “virtualize x2APIC mode” VM-execution control is 1. See Section 30.5.

- VM exits caused by APIC-write emulation (see Section 30.4.3.2) that result from APIC accesses as part of

instruction execution.

For these VM exits, the instruction’s modifications to architectural state complete before the VM exit occurs.

Such modifications include those to the logical processor’s interruptibility state (see Table 25-3). If there had

been blocking by MOV SS, POP SS, or STI before the instruction executed, such blocking is no longer in effect.

A VM exit that occurs in enclave mode sets bit 27 of the exit-reason field and bit 4 of the guest interruptibility-state

field. Before such a VM exit is delivered, an Asynchronous Enclave Exit (AEX) occurs (see Chapter 37, “Enclave

Exiting Events”). An AEX modifies architectural state (Section 37.3). In particular, the processor establishes the

following architectural state as indicated:

• The following bits in RFLAGS are cleared: CF, PF, AF, ZF, SF, OF, and RF.

• FS and GS are restored to the values they had prior to the most recent enclave entry.

• RIP is loaded with the AEP of interrupted enclave thread.

• RSP is loaded from the URSP field in the enclave’s state-save area (SSA).

Vol. 3C

28-3

VM EXITS

28.2

RECORDING VM-EXIT INFORMATION AND UPDATING VM-ENTRY CONTROL

FIELDS

VM exits begin by recording information about the nature of and reason for the VM exit in the VM-exit information

fields. Section 28.2.1 to Section 28.2.5 detail the use of these fields.

In addition to updating the VM-exit information fields, the valid bit (bit 31) is cleared in the VM-entry interruption-

information field. If bit 5 of the IA32_VMX_MISC MSR (index 485H) is read as 1 (see Appendix A.6), the value of

IA32_EFER.LMA is stored into the “IA-32e mode guest” VM-entry control.¹

28.2.1 Basic VM-Exit Information

Section 25.9.1 defines the basic VM-exit information fields. The following items detail their use.

• Exit reason.

- Bits 15:0 of this field contain the basic exit reason. It is loaded with a number indicating the general cause

of the VM exit. Appendix C lists the numbers used and their meaning.

- Bit 25 is set if the “prematurely busy shadow stack” VM-exit control is 1 and the VM exit caused a shadow

stack become prematurely busy (see Section 26.4.3). Otherwise, the bit is cleared.

- Bit 26 of this field is set to 1 if the VM exit occurred after assertion of a bus lock while the “VMM bus-lock

detection” VM-execution control was 1. Such VM exits include those that occur due to the 1-setting of that

control as well as others that might occur during execution of an instruction that asserted a bus lock.

- Bit 27 of this field is set to 1 if the VM exit occurred while the logical processor was in enclave mode.

Such VM exits include those caused by interrupts, non-maskable interrupts, system-management

interrupts, INIT signals, and exceptions occurring in enclave mode as well as exceptions encountered

during the delivery of such events incident to enclave mode.

A VM exit also sets this bit if it is incident to delivery of an event injected by VM entry and the guest inter-

ruptibility-state field indicates an enclave interruption (bit 4 of the field is 1).

- The remainder of the field (bits 31:28 and bits 24:16) is cleared to 0 (certain SMM VM exits may set some

of these bits; see Section 32.15.2.3).²

• Exit qualification. This field is saved for VM exits due to the following causes: debug exceptions; page-fault

exceptions; start-up IPIs (SIPIs); system-management interrupts (SMIs) that arrive immediately after the

execution of I/O instructions; task switches; INVEPT; INVLPG; INVPCID; INVVPID; LGDT; LIDT; LLDT; LTR;

SGDT; SIDT; SLDT; STR; VMCLEAR; VMPTRLD; VMPTRST; VMREAD; VMWRITE; VMXON; WBINVD;

WBNOINVD; XRSTORS; XSAVES; control-register accesses; MOV DR; I/O instructions; MWAIT; accesses to the

APIC-access page (see Section 30.4); EPT violations (see Section 29.3.3.2); EOI virtualization (see Section

30.1.4); APIC-write emulation (see Section 30.4.3.3); page-modification log full (see Section 29.3.6); SPP-

related events (see Section 29.3.4); and instruction timeout (see Section 26.2). For all other VM exits, this field

is cleared. The following items provide details:

- For a debug exception, the exit qualification contains information about the debug exception. The

information has the format given in Table 28-1.

Table 28-1. Exit Qualification for Debug Exceptions

Bit Position(s)

Contents

3:0

B3 - B0. When set, each of these bits indicates that the corresponding breakpoint condition was met. Any of

these bits may be set even if its corresponding enabling bit in DR7 is not set.

10:4

Not currently defined.

1. Bit 5 of the IA32_VMX_MISC MSR is read as 1 on any logical processor that supports the 1-setting of the “unrestricted guest” VM-

execution control.

2. Bit 31 of this field is set on certain VM-entry failures; see Section 27.8.

28-4

Vol. 3C

VM EXITS

Table 28-1. Exit Qualification for Debug Exceptions (Contd.)

Bit Position(s)

Contents

BLD. When set, this bit indicates that a bus lock was asserted while OS bus-lock detection was enabled and

CPL > 0 (see Section 18.3.1.6 (‘‘OS Bus-Lock Detection”)).¹

Not currently defined.

BD. When set, this bit indicates that the cause of the debug exception is “debug register access detected.”

BS. When set, this bit indicates that the cause of the debug exception is either the execution of a single

instruction (if RFLAGS.TF = 1 and IA32_DEBUGCTL.BTF = 0) or a taken branch (if

RFLAGS.TF = DEBUGCTL.BTF = 1).

Not currently defined.

RTM. When set, this bit indicates that a debug exception (#DB) or a breakpoint exception (#BP) occurred

inside an RTM region while advanced debugging of RTM transactional regions was enabled (see Section

16.3.7, “RTM-Enabled Debugger Support,” of the Intel^® 64 and IA-32 Architectures Software Developer’s

Manual, Volume 1).²

63:17

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

NOTES:

1. In general, the format of this field matches that of DR6. However, DR6 clears bit 11 to indicate detection of a bus lock, while this field

sets the bit to indicate that condition.

2. In general, the format of this field matches that of DR6. However, DR6 clears bit 16 to indicate an RTM-related exception, while this

field sets the bit to indicate that condition.

- For a page-fault exception, the exit qualification contains the linear address that caused the page fault. On

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

bit mode before the VM exit.

If the page-fault exception occurred during execution of an instruction in enclave mode (and not during

delivery of an event incident to enclave mode), bits 11:0 of the exit qualification are cleared.

- For a start-up IPI (SIPI), the exit qualification contains the SIPI vector information in bits 7:0. Bits 63:8 of

the exit qualification are cleared to 0.

- For a task switch, the exit qualification contains details about the task switch, encoded as shown in

Table 28-2.

- For INVLPG, the exit qualification contains the linear-address operand of the instruction.

• On processors that support Intel 64 architecture, bits 63:32 are cleared if the logical processor was not

in 64-bit mode before the VM exit.

• If the INVLPG source operand specifies an unusable segment, the linear address specified in the exit

qualification will match the linear address that the INVLPG would have used if no VM exit occurred. This

address is not architecturally defined and may be implementation-specific.

Table 28-2. Exit Qualification for Task Switches

Bit Position(s)

Contents

15:0

Selector of task-state segment (TSS) to which the guest attempted to switch

29:16

Not currently defined

Vol. 3C

28-5

VM EXITS

Table 28-2. Exit Qualification for Task Switches (Contd.)

Bit Position(s)

Contents

31:30

Source of task switch initiation:

0: CALL instruction

1: IRET instruction

2: JMP instruction

3: Task gate in IDT

63:32

Not currently defined. These bits exist only on processors that support Intel 64 architecture.

- For INVEPT, INVPCID, INVVPID, LGDT, LIDT, LLDT, LTR, SGDT, SIDT, SLDT, STR, VMCLEAR, VMPTRLD,

VMPTRST, VMREAD, VMWRITE, VMXON, XRSTORS, and XSAVES, the exit qualification receives the value of

the instruction’s displacement field, which is sign-extended to 64 bits if necessary (32 bits on processors

that do not support Intel 64 architecture). If the instruction has no displacement (for example, has a

On processors that support Intel 64 architecture, an exception is made for RIP-relative addressing (used

only in 64-bit mode). Such addressing causes an instruction to use an address that is the sum of the

displacement field and the value of RIP that references the following instruction. In this case, the exit

qualification is loaded with the sum of the displacement field and the appropriate RIP value.

In all cases, bits of this field beyond the instruction’s address size are undefined. For example, suppose

that the address-size field in the VM-exit instruction-information field (see Section 25.9.4 and Section

28.2.5) reports an n-bit address size. Then bits 63:n (bits 31:n on processors that do not support Intel 64

architecture) of the instruction displacement are undefined.

- For a control-register access, the exit qualification contains information about the access and has the

format given in Table 28-3.

- For MOV DR, the exit qualification contains information about the instruction and has the format given in

Table 28-4.

- For an I/O instruction, the exit qualification contains information about the instruction and has the format

given in Table 28-5.

- For MWAIT, the exit qualification contains a value that indicates whether address-range monitoring

hardware was armed. The exit qualification is set either to 0 (if address-range monitoring hardware is not

armed) or to 1 (if address-range monitoring hardware is armed).

- WBINVD and WBNOINVD use the same basic exit reason (see Appendix C). For WBINVD, the exit qualifi-

cation is 0, while for WBNOINVD it is 1.

- For an APIC-access VM exit resulting from a linear access or a guest-physical access to the APIC-access

page (see Section 30.4), the exit qualification contains information about the access and has the format

given in Table 28-6.¹

If the access to the APIC-access page occurred during execution of an instruction in enclave mode (and not

during delivery of an event incident to enclave mode), bits 11:0 of the exit qualification are cleared.

Such a VM exit that set bits 15:12 of the exit qualification to 0000b (data read during instruction execution)

or 0001b (data write during instruction execution) set bit 12-which distinguishes data read from data

write-to that which would have been stored in bit 1-W/R-of the page-fault error code had the access

caused a page fault instead of an APIC-access VM exit. This implies the following:

• For an APIC-access VM exit caused by the CLFLUSH and CLFLUSHOPT instructions, the access type is

“data read during instruction execution.”

• For an APIC-access VM exit caused by the ENTER instruction, the access type is “data write during

instruction execution.”

1. The exit qualification is undefined if the access was part of the logging of a branch record or a processor-event-based-sampling

(PEBS) record to the DS save area. It is recommended that software configure the paging structures so that no address in the DS

save area translates to an address on the APIC-access page.

28-6

Vol. 3C

VM EXITS

Table 28-3. Exit Qualification for Control-Register Accesses

Bit Positions

Contents

3:0

Number of control register (0 for CLTS and LMSW). Bit 3 is always 0 on processors that do not support Intel 64

architecture as they do not support CR8.

5:4

Access type:

0 = MOV to CR

1 = MOV from CR

2 = CLTS

3 = LMSW

LMSW operand type:

0 = register

1 = memory

For CLTS and MOV CR, cleared to 0

Not currently defined

11:8

For MOV CR, the general-purpose register:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

For CLTS and LMSW, cleared to 0

15:12

Not currently defined

31:16

For LMSW, the LMSW source data

For CLTS and MOV CR, cleared to 0

63:32

Not currently defined. These bits exist only on processors that support Intel 64 architecture.

•

For an APIC-access VM exit caused by the MASKMOVQ instruction or the MASKMOVDQU instruction, the

access type is “data write during instruction execution.”

•

For an APIC-access VM exit caused by the MONITOR instruction, the access type is “data read during

instruction execution.”

•

For an APIC-access VM exit caused directly by an access to a linear address in the DS save area (BTS or

PEBS), the access type is “linear access for monitoring.”

•

For an APIC-access VM exit caused by a guest-physical access performed for an access to the DS save

area (e.g., to access a paging structure to translate a linear address), the access type is “guest-physical

access for monitoring or trace.”

•

For an APIC-access VM exit caused by trace-address pre-translation (TAPT) when the “Intel PT uses

guest physical addresses” VM-execution control is 1, the access type is “guest-physical access for

monitoring or trace.”

Such a VM exit stores 1 for bit 31 for IDT-vectoring information field (see Section 28.2.4) if and only if it

sets bits 15:12 of the exit qualification to 0011b (linear access during event delivery) or 1010b (guest-

physical access during event delivery).

Vol. 3C

28-7

VM EXITS

See Section 30.4.4 for further discussion of these instructions and APIC-access VM exits.

For APIC-access VM exits resulting from physical accesses to the APIC-access page (see Section 30.4.6),

the exit qualification is undefined.

- For an EPT violation, the exit qualification contains information about the access causing the EPT violation

and has the format given in Table 28-7.

As noted in that table, the format and meaning of the exit qualification depends on the setting of the

“mode-based execute control for EPT” VM-execution control and whether the processor supports advanced

VM-exit information for EPT violations.¹

An EPT violation that occurs during as a result of execution of a read-modify-write operation sets bit 1 (data

write). Whether it also sets bit 0 (data read) is implementation-specific and, for a given implementation,

may differ for different kinds of read-modify-write operations.

Table 28-4. Exit Qualification for MOV DR

Bit Position(s)

Contents

2:0

Number of debug register

Not currently defined

Direction of access (0 = MOV to DR; 1 = MOV from DR)

7:5

Not currently defined

11:8

General-purpose register:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8 -15 = R8 - R15, respectively

63:12

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

Table 28-5. Exit Qualification for I/O Instructions

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)

1. Software can determine whether advanced VM-exit information for EPT violations is supported by consulting the VMX capability

MSR IA32_VMX_EPT_VPID_CAP (see Appendix A.10).

28-8

Vol. 3C

VM EXITS

Table 28-5. Exit Qualification for I/O Instructions (Contd.)

Bit Position(s)

Contents

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

Operand encoding (0 = DX, 1 = immediate)

15:7

Not currently defined

31:16

Port number (as specified in DX or in an immediate operand)

63:32

Not currently defined. These bits exist only on processors that support Intel 64 architecture.

Table 28-6. Exit Qualification for APIC-Access VM Exits from Linear Accesses and Guest-Physical Accesses

Bit Position(s)

Contents

11:0

• If the APIC-access VM exit is due to a linear access, the offset of access within the APIC page.

• Undefined if the APIC-access VM exit is due a guest-physical access

15:12

Access type:

0 = linear access for a data read during instruction execution

1 = linear access for a data write during instruction execution

2 = linear access for an instruction fetch

3 = linear access (read or write) during event delivery

4 = linear access for monitoring

10 = guest-physical access during event delivery

11 = guest-physical access for monitoring or trace

15 = guest-physical access for an instruction fetch or during instruction execution

Other values not used

This bit is set for certain accesses that are asynchronous to instruction execution and not part of event delivery.

These includes guest-physical accesses related to trace output by Intel PT (see Section 26.5.4), accesses related

to PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5), and accesses that occur during

user-interrupt delivery (see Section 7.4.2).

63:17

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

Bit 12 reports “NMI unblocking due to IRET”; see Section 28.2.3.

Bit 16 is set for certain accesses that are asynchronous to instruction execution and not part of event

delivery. These include trace-address pre-translation (TAPT) for Intel PT (see Section 26.5.4), accesses

related to PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5), and accesses as

part of user-interrupt delivery (see Section 7.4.2).

- For VM exits caused as part of EOI virtualization (Section 30.1.4), bits 7:0 of the exit qualification are set

to vector of the virtual interrupt that was dismissed by the EOI virtualization. Bits above bit 7 are cleared.

- For APIC-write VM exits (Section 30.4.3.3), bits 11:0 of the exit qualification are set to the page offset of

the write access that caused the VM exit.¹ Bits above bit 11 are cleared.

- For a VM exit due to a page-modification log-full event (Section 29.3.6), bit 12 of the exit qualification

reports “NMI unblocking due to IRET” (see Section 28.2.3). Bit 16 is set if the VM exit occurs during TAPT,

EPT-friendly PEBS, or user-interrupt delivery. All other bits of the exit qualification are undefined.

- For a VM exit due to an SPP-related event (Section 29.3.4), bit 11 of the exit qualification indicates the type

of event: 0 indicates an SPP misconfiguration and 1 indicates an SPP miss. Bit 12 of the exit qualification

1. Execution of WRMSR with ECX = 83FH (self-IPI MSR) can lead to an APIC-write VM exit; the exit qualification for such an APIC-write

VM exit is 3F0H.

Vol. 3C

28-9

VM EXITS

reports “NMI unblocking due to IRET” (see Section 28.2.3). Bit 16 is set if the VM exit occurs during TAPT

EPT-friendly PEBS, or user-interrupt delivery. All other bits of the exit qualification are undefined.

- If the “PASID translation” VM-execution control, PASID translation is performed for executions of the

ENQCMD and ENQCMDS instructions (see Section 26.5.8). PASID translation may fail, resulting in a

VM exit. Such a VM exit saves an exit qualification specified in the following items:

• For ENQCMD, the exit qualification is IA32_PASID[19:0].

• For ENQCMDS, the exit qualification contains the low 32 bits of the instruction’s source operand (which

had been read from memory prior to PASID translation).

- For a VM exit due to an instruction timeout (Section 26.2), bit 0 indicates (if set) that the context of the

virtual machine is invalid and that the VM should not be resumed. Bit 12 of the exit qualification reports

“NMI unblocking due to IRET” (see Section 28.2.3). All other bits of the exit qualification are undefined.

• Guest linear address. For some VM exits, this field receives a linear address that pertains to the VM exit. The

field is set for different VM exits as follows:

- VM exits due to attempts to execute LMSW with a memory operand. In these cases, this field receives the

linear address of that operand. Bits 63:32 are cleared if the logical processor was not in 64-bit mode before

the VM exit.

- VM exits due to attempts to execute INS or OUTS for which the relevant segment is usable (if the relevant

segment is not usable, the value is undefined). (ES is always the relevant segment for INS; for OUTS, the

relevant segment is DS unless overridden by an instruction prefix.) The linear address is the base address

of relevant segment plus (E)DI (for INS) or (E)SI (for OUTS). Bits 63:32 are cleared if the logical processor

was not in 64-bit mode before the VM exit.

Table 28-7. Exit Qualification for EPT Violations

Bit Position(s)

Contents

Set if the access causing the EPT violation was a data read.¹

Set if the access causing the EPT violation was a data write.¹

Set if the access causing the EPT violation was an instruction fetch.

The logical-AND of bit 0 in the EPT paging-structure entries used to translate the guest-physical address of the

access causing the EPT violation (indicates whether the guest-physical address was readable).²

The logical-AND of bit 1 in the EPT paging-structure entries used to translate the guest-physical address of the

access causing the EPT violation (indicates whether the guest-physical address was writeable).²

The logical-AND of bit 2 in the EPT paging-structure entries used to translate the guest-physical address of the

access causing the EPT violation.²

If the “mode-based execute control for EPT” VM-execution control is 0, this indicates whether the guest-physical

address was executable. If that control is 1, this indicates whether the guest-physical address was executable

for supervisor-mode linear addresses.

If the “mode-based execute control” VM-execution control is 0, the value of this bit is undefined. If that control is

1, this bit is the logical-AND of bit 10 in the EPT paging-structure entries used to translate the guest-physical

address of the access causing the EPT violation. In this case, it indicates whether the guest-physical address was

executable for user-mode linear addresses.³

Set if the guest linear-address field is valid.

The guest linear-address field is valid for all EPT violations except those resulting from an attempt to load the

guest PDPTEs as part of the execution of the MOV CR instruction and those due to trace-address pre-translation

(TAPT; Section 26.5.4).

28-10

Vol. 3C

VM EXITS

Table 28-7. Exit Qualification for EPT Violations (Contd.)

Bit Position(s)

Contents

If bit 7 is 1:

• Set if the access causing the EPT violation is to a guest-physical address that is the translation of a linear

address.

• Clear if the access causing the EPT violation is to a paging-structure entry as part of a page walk or the

update of an accessed or dirty bit.

Reserved if bit 7 is 0 (cleared to 0).

If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,⁴ this bit is 0

if the linear address is a supervisor-mode linear address and 1 if it is a user-mode linear address. (If CR0.PG = 0,

the translation of every linear address is a user-mode linear address and thus this bit will be 1.) Otherwise, this

bit is undefined.

If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,⁴ this bit is 0

if paging translates the linear address to a read-only page and 1 if it translates to a read/write page. (If CR0.PG =

0, every linear address is read/write and thus this bit will be 1.) Otherwise, this bit is undefined.

If bit 7 is 1, bit 8 is 1, and the processor supports advanced VM-exit information for EPT violations,⁴ this bit is 0

if paging translates the linear address to an executable page and 1 if it translates to an execute-disable page. (If

CR0.PG = 0, CR4.PAE = 0, or IA32_EFER.NXE = 0, every linear address is executable and thus this bit will be 0.)

Otherwise, this bit is undefined.

NMI unblocking due to IRET (see Section 28.2.3).

Set if the access causing the EPT violation was a shadow-stack access.

If supervisor shadow-stack control is enabled (by setting bit 7 of EPTP), this bit is the same as bit 60 in the EPT

paging-structure entry that maps the page of the guest-physical address of the access causing the EPT violation.

Otherwise (or if translation of the guest-physical address terminates before reaching an EPT paging-structure

entry that maps a page), this bit is undefined.

This bit is set if the EPT violation was caused as a result of guest-paging verification. See Section 29.3.3.2.

This bit is set if the access was asynchronous to instruction execution not the result of event delivery. The bit is

set if the access is related to trace output by Intel PT (see Section 26.5.4), accesses related to PEBS on

processors with the “EPT-friendly” enhancement (see Section 20.9.5), or to user-interrupt delivery (see Section

7.4.2). Otherwise, this bit is cleared.

63:17

Not currently defined. Bits 63:32 exist only on processors that support Intel 64 architecture.

NOTES:

1. If accessed and dirty flags for EPT are enabled, processor accesses to guest paging-structure entries are treated as writes with

regard to EPT violations (see Section 29.3.3.2). If such an access causes an EPT violation, the processor sets both bit 0 and bit 1 of

the exit qualification.

2. Bits 5:3 are cleared to 0 if either (1) any of EPT paging-structure entries used to translate the guest-physical address of the access

causing the EPT violation is not present; or (2) 4-level EPT is in use and the guest-physical address sets any bits in the range 51:48

(see Section 29.3.2).

3. Bit 6 is cleared to 0 if (1) the “mode-based execute control” VM-execution control is 1; and (2) either (a) any of EPT paging-structure

entries used to translate the guest-physical address of the access causing the EPT violation is not present; or (b) 4-level EPT is in use

and the guest-physical address sets any bits in the range 51:48 (see Section 29.3.2).

4. Software can determine whether advanced VM-exit information for EPT violations is supported by consulting the VMX capability

MSR IA32_VMX_EPT_VPID_CAP (see Appendix A.10).

- VM exits due to EPT violations that set bit 7 of the exit qualification (see Table 28-7; these are all EPT

violations except those resulting from an attempt to load the PDPTEs as of execution of the MOV CR

instruction and those due to TAPT). The linear address may translate to the guest-physical address whose

access caused the EPT violation. Alternatively, translation of the linear address may reference a paging-

Vol. 3C

28-11

VM EXITS

structure entry whose access caused the EPT violation. Bits 63:32 are cleared if the logical processor was

not in 64-bit mode before the VM exit.

If the EPT violation occurred during execution of an instruction in enclave mode (and not during delivery of

an event incident to enclave mode), bits 11:0 of this field are cleared.

- VM exits due to SPP-related events.

- If the “prematurely busy shadow stack” VM-exit control is 1, certain VM exits (besides those noted above)

save the linear address that pertains to the VM exit if the VM exit caused a shadow stack to become

prematurely busy (see Section 26.4.3). This is true for VM exits due for these reasons: EPT misconfigu-

ration, page-modification log-full event, and instruction timeout. (A VM exit due to instruction timeout that

sets bit 0 of the exit qualification, indicating that VM context is invalid, does not save a valid linear address.)

- For all other VM exits, the field is undefined.

• Guest-physical address. For a VM exit due to an EPT violation, an EPT misconfiguration, or an SPP-related

event, this field receives the guest-physical address that caused the EPT violation or EPT misconfiguration. For

all other VM exits, the field is undefined.

If the EPT violation or EPT misconfiguration occurred during execution of an instruction in enclave mode (and

not during delivery of an event incident to enclave mode), bits 11:0 of this field are cleared.

28.2.2 Information for VM Exits Due to Vectored Events

Section 25.9.2 defines fields containing information for VM exits due to the following events: exceptions (including

those generated by the instructions INT1, INT3, INTO, BOUND, UD0, UD1, and UD2); external interrupts that occur

while the “acknowledge interrupt on exit” VM-exit control is 1; and non-maskable interrupts (NMIs).¹ Such

VM exits include those that occur on an attempt at a task switch that causes an exception before generating the

VM exit due to the task switch that causes the VM exit.

The following items detail the use of these fields:

• VM-exit interruption information (format given in Table 25-19). The following items detail how this field is

established for VM exits due to these events:

- For an exception, bits 7:0 receive the exception vector (at most 31). For an NMI, bits 7:0 are set to 2. For

an external interrupt, bits 7:0 receive the vector.

- Bits 10:8 are set to 0 (external interrupt), 2 (non-maskable interrupt), 3 (hardware exception), 5

(privileged software exception), or 6 (software exception). Hardware exceptions comprise all exceptions

except the following:

• Debug exceptions (#DB) generated by the INT1 instruction; these are privileged software exceptions.

(Other debug exceptions are considered hardware exceptions, as are those caused by executions of

INT1 in enclave mode.)

• Breakpoint exceptions (#BP; generated by INT3) and overflow exceptions (#OF; generated by INTO);

these are software exceptions. (A #BP that occurs in enclave mode is considered a hardware

exception.)

BOUND-range exceeded exceptions (#BR; generated by BOUND) and invalid opcode exceptions (#UD)

generated by UD0, UD1, and UD2 are hardware exceptions.

- Bit 11 is set to 1 if the VM exit is caused by a hardware exception that would have delivered an error code

on the stack. This bit is always 0 if the VM exit occurred while the logical processor was in real-address

mode (CR0.PE=0).² If bit 11 is set to 1, the error code is placed in the VM-exit interruption error code (see

below).

- Bit 12 reports “NMI unblocking due to IRET”; see Section 28.2.3. The value of this bit is undefined if the

VM exit is due to a double fault (the interruption type is hardware exception and the vector is 8).

1. INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively, and not to INT n with value 1 or 3 for n.

2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, a logical processor cannot be in real-

address mode unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution con-

trols are both 1.

28-12

Vol. 3C

VM EXITS

- Bits 30:13 are always set to 0.

- Bit 31 is always set to 1.

For other VM exits (including those due to external interrupts when the “acknowledge interrupt on exit” VM-exit

control is 0), the field is marked invalid (by clearing bit 31) and the remainder of the field is undefined.

• VM-exit interruption error code.

- For VM exits that set both bit 31 (valid) and bit 11 (error code valid) in the VM-exit interruption-information

field, this field receives the error code that would have been pushed on the stack had the event causing the

VM exit been delivered normally through the IDT. The EXT bit is set in this field exactly when it would be set

normally. For exceptions that occur during the delivery of double fault (if the IDT-vectoring information field

indicates a double fault), the EXT bit is set to 1, assuming that (1) that the exception would produce an

error code normally (if not incident to double-fault delivery) and (2) that the error code uses the EXT bit

(not for page faults, which use a different format).

- For other VM exits, the value of this field is undefined.

28.2.3 Information About NMI Unblocking Due to IRET

A VM exit may occur during execution of the IRET instruction for reasons including the following: faults, EPT viola-

tions, page-modification log-full events, SPP-related events, or instruction timeouts.

An execution of IRET that commences while non-maskable interrupts (NMIs) are blocked will unblock NMIs even if

a fault or VM exit occurs; the state saved by such a VM exit will indicate that NMIs were not blocked.

VM exits for the reasons enumerated above provide more information to software by saving a bit called “NMI

unblocking due to IRET.” This bit is defined if (1) either the “NMI exiting” VM-execution control is 0 or the “virtual

NMIs” VM-execution control is 1; (2) the VM exit does not set the valid bit in the IDT-vectoring information field

(see Section 28.2.4); and (3) the VM exit is not due to a double fault. In these cases, the bit is defined as follows:

• The bit is 1 if the VM exit resulted from a memory access as part of execution of the IRET instruction and one

of the following holds:

- The “virtual NMIs” VM-execution control is 0 and blocking by NMI (see Table 25-3) was in effect before

execution of IRET.

- The “virtual NMIs” VM-execution control is 1 and virtual-NMI blocking was in effect before execution of

IRET.

• The bit is 0 for all other relevant VM exits.

For VM exits due to faults, NMI unblocking due to IRET is saved in bit 12 of the VM-exit interruption-information

field (Section 28.2.2). For VM exits due to EPT violations, page-modification log-full events, SPP-related events,

and instruction timeouts, NMI unblocking due to IRET is saved in bit 12 of the exit qualification (Section 28.2.1).

(Executions of IRET may also incur VM exits due to APIC accesses and EPT misconfigurations. These VM exits do

not report information about NMI unblocking due to IRET.)

28.2.4 Information for VM Exits During Event Delivery

Section 25.9.3 defined fields containing information for VM exits that occur while delivering an event through the

IDT and as a result of any of the following cases:¹

• A fault occurs during event delivery and causes a VM exit (because the bit associated with the fault is set to 1

in the exception bitmap).

• A task switch is invoked through a task gate in the IDT. The VM exit occurs due to the task switch only after the

initial checks of the task switch pass (see Section 26.4.2).

• Event delivery causes an APIC-access VM exit (see Section 30.4).

1. This includes the case in which a VM exit occurs while delivering a software interrupt (INT n) through the 16-bit IVT (interrupt vec-

tor table) that is used in virtual-8086 mode with virtual-machine extensions (if RFLAGS.VM = CR4.VME = 1).

Vol. 3C

28-13

VM EXITS

• An EPT violation, EPT misconfiguration, page-modification log-full event, or SPP-related event that occurs

during event delivery.

• Any of the above VM exits that occur during user-interrupt notification processing (see Section 7.5.2). Such

VM exits will be treated as if they occurred during delivery of an external interrupt with the vector UINV.

These fields are used for VM exits that occur during delivery of events injected as part of VM entry (see Section

27.6.1.2).

A VM exit is not considered to occur during event delivery in any of the following circumstances:

• The original event causes the VM exit directly (for example, because the original event is a non-maskable

interrupt (NMI) and the “NMI exiting” VM-execution control is 1).

• The original event results in a double-fault exception that causes the VM exit directly.

• The VM exit occurred as a result of fetching the first instruction of the handler invoked by the event delivery.

• The VM exit is caused by a triple fault.

• The original event was a software interrupt (INT n) executed in virtual-8086 mode with EFLAGS.IOPL < 3 and

the VM exit was due to a general-protection exception (#GP) that occurred because either CR4.VME = 0 or bit

n of the software interrupt redirection bit map in the TSS is set.

The following items detail the use of these fields:

• IDT-vectoring information (format given in Table 25-20). The following items detail how this field is established

for VM exits that occur during event delivery:

- If the VM exit occurred during delivery of an exception, bits 7:0 receive the exception vector (at most 31).

If the VM exit occurred during delivery of an NMI, bits 7:0 are set to 2. If the VM exit occurred during

delivery of an external interrupt, bits 7:0 receive the vector.

- Bits 10:8 are set to indicate the type of event that was being delivered when the VM exit occurred: 0

(external interrupt), 2 (non-maskable interrupt), 3 (hardware exception), 4 (software interrupt), 5

(privileged software interrupt), or 6 (software exception).

Hardware exceptions comprise all exceptions except the following:¹

• Debug exceptions (#DB) generated by the INT1 instruction; these are privileged software exceptions.

(Other debug exceptions are considered hardware exceptions, as are those caused by executions of

INT1 in enclave mode.)

• Breakpoint exceptions (#BP; generated by INT3) and overflow exceptions (#OF; generated by INTO);

these are software exceptions. (A #BP that occurs in enclave mode is considered a hardware

exception.)

BOUND-range exceeded exceptions (#BR; generated by BOUND) and invalid opcode exceptions (#UD)

generated by UD0, UD1, and UD2 are hardware exceptions.

- Bit 11 is set to 1 if the VM exit occurred during delivery of a hardware exception that would have delivered

an error code on the stack. This bit is always 0 if the VM exit occurred while the logical processor was in

real-address mode (CR0.PE=0).² If bit 11 is set to 1, the error code is placed in the IDT-vectoring error

code (see below).

- Bit 12 is undefined.

- Bits 30:13 are always set to 0.

- Bit 31 is always set to 1.

For other VM exits, the field is marked invalid (by clearing bit 31) and the remainder of the field is undefined.

• IDT-vectoring error code.

1. In the following items, INT1 and INT3 refer to the instructions with opcodes F1 and CC, respectively, and not to INT n with value 1 or

3 for n.

2. If the capability MSR IA32_VMX_CR0_FIXED0 reports that CR0.PE must be 1 in VMX operation, a logical processor cannot be in real-

address mode unless the “unrestricted guest” VM-execution control and bit 31 of the primary processor-based VM-execution con-

trols are both 1.

28-14

Vol. 3C

VM EXITS

- For VM exits that set both bit 31 (valid) and bit 11 (error code valid) in the IDT-vectoring information field,

this field receives the error code that would have been pushed on the stack by the event that was being

delivered through the IDT at the time of the VM exit. The EXT bit is set in this field when it would be set

normally.

- For other VM exits, the value of this field is undefined.

28.2.5 Information for VM Exits Due to Instruction Execution

Section 25.9.4 defined fields containing information for VM exits that occur due to instruction execution. (The VM-

exit instruction length is also used for VM exits that occur during the delivery of a software interrupt or software

exception.) The following items detail their use.

•

VM-exit instruction length. This field is used in the following cases:

- For fault-like VM exits due to attempts to execute one of the following instructions that cause VM exits

unconditionally (see Section 26.1.2) or based on the settings of VM-execution controls (see Section

26.1.3): CLTS, CPUID, ENCLS, GETSEC, HLT, IN, INS, INVD, INVEPT, INVLPG, INVPCID, INVVPID, LGDT,

LIDT, LLDT, LMSW, LOADIWKEY, LTR, MONITOR, MOV CR, MOV DR, MWAIT, OUT, OUTS, PAUSE, PCONFIG,

RDMSR, RDPMC, RDRAND, RDSEED, RDTSC, RDTSCP, RSM, SGDT, SIDT, SLDT, STR, TPAUSE, UMWAIT,

VMCALL, VMCLEAR, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXOFF, VMXON,

WBINVD, WBNOINVD, WRMSR, XRSTORS, XSETBV, and XSAVES.¹

- For VM exits due to software exceptions (those generated by executions of INT3 or INTO) or privileged

software exceptions (those generated by executions of INT1).

- For VM exits due to faults encountered during delivery of a software interrupt, privileged software

exception, or software exception.

- For VM exits due to attempts to effect a task switch via instruction execution. These are VM exits that

produce an exit reason indicating task switch and either of the following:

• An exit qualification indicating execution of CALL, IRET, or JMP instruction.

• An exit qualification indicating a task gate in the IDT and an IDT-vectoring information field indicating

that the task gate was encountered during delivery of a software interrupt, privileged software

exception, or software exception.

- For APIC-access VM exits and for VM exits caused by EPT violations, page-modification log-full events, and

SPP-related events encountered during delivery of a software interrupt, privileged software exception, or

software exception.²

- For VM exits due executions of VMFUNC that fail because one of the following is true:

• EAX indicates a VM function that is not enabled (the bit at position EAX is 0 in the VM-function controls;

see Section 26.5.6.2).

• EAX = 0 and either ECX ≥ 512 or the value of ECX selects an invalid tentative EPTP value (see Section

26.5.6.3).

In all the above cases, this field receives the length in bytes (1-15) of the instruction (including any instruction

prefixes) whose execution led to the VM exit (see the next paragraph for one exception).

The cases of VM exits encountered during delivery of a software interrupt, privileged software exception, or

software exception include those encountered during delivery of events injected as part of VM entry (see

Section 27.6.1.2). If the original event was injected as part of VM entry, this field receives the value of the VM-

entry instruction length.

All VM exits other than those listed in the above items leave this field undefined.

This item applies only to fault-like VM exits. It does not apply to trap-like VM exits following executions of the MOV to CR8 instruc-

tion when the “use TPR shadow” VM-execution control is 1 or to those following executions of the WRMSR instruction when the

“virtualize x2APIC mode” VM-execution control is 1.

The VM-exit instruction-length field is not defined following APIC-access VM exits resulting from physical accesses (see Section

30.4.6) even if encountered during delivery of a software interrupt, privileged software exception, or software exception.

Vol. 3C

28-15

VM EXITS

If the VM exit occurred in enclave mode, this field is cleared (none of the previous items apply).

Table 28-8. Format of the VM-Exit Instruction-Information Field as Used for INS and OUTS

Bit Position(s)

Content

6:0

Undefined.

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used.

14:10

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used. Undefined for VM exits due to execution of INS.

31:18

Undefined.

• VM-exit instruction information. For VM exits due to attempts to execute INS, INVEPT, INVPCID, INVVPID,

LIDT, LGDT, LLDT, LOADIWKEY, LTR, OUTS, RDRAND, RDSEED, SIDT, SGDT, SLDT, STR, TPAUSE, UMWAIT,

VMCLEAR, VMPTRLD, VMPTRST, VMREAD, VMWRITE, VMXON, XRSTORS, or XSAVES, this field receives

information about the instruction that caused the VM exit. The format of the field depends on the identity of the

instruction causing the VM exit:

- For VM exits due to attempts to execute INS or OUTS, the field has the format is given in Table 28-8.¹

- For VM exits due to attempts to execute INVEPT, INVPCID, or INVVPID, the field has the format is given in

Table 28-9.

- For VM exits due to attempts to execute LIDT, LGDT, SIDT, or SGDT, the field has the format is given in

Table 28-10.

- For VM exits due to attempts to execute LLDT, LTR, SLDT, or STR, the field has the format is given in

Table 28-11.

- For VM exits due to attempts to execute RDRAND or RDSEED, the field has the format is given in

Table 28-12.

- For VM exits due to attempts to execute TPAUSE or UMWAIT, the field has the format is given in

Table 28-13.

- For VM exits due to attempts to execute VMCLEAR, VMPTRLD, VMPTRST, VMXON, XRSTORS, or XSAVES,

the field has the format is given in Table 28-14.

- For VM exits due to attempts to execute VMREAD or VMWRITE, the field has the format is given in

Table 28-15.

- For VM exits due to attempts to execute LOADIWKEY, the field has the format is given in Table 28-16.

For all other VM exits, the field is undefined, unless the VM exit occurred in enclave mode, in which case the

field is cleared.

1. The format of the field was undefined for these VM exits on the first processors to support the virtual-machine extensions. Soft-

ware can determine whether the format specified in Table 28-8 is used by consulting the VMX capability MSR IA32_VMX_BASIC

(see Appendix A.1).

28-16

Vol. 3C

VM EXITS

• I/O RCX, I/O RSI, I/O RDI, I/O RIP. These fields are undefined except for SMM VM exits due to system-

management interrupts (SMIs) that arrive immediately after retirement of I/O instructions. See Section

32.15.2.3. Note that, if the VM exit occurred in enclave mode, these fields are all cleared.

Table 28-9. Format of the VM-Exit Instruction-Information Field as Used for INVEPT, INVPCID, and INVVPID

Bit Position(s)

Content

1:0

Scaling:

0: no scaling

1: scale by 2

2: scale by 4

3: scale by 8 (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

6:2

Undefined.

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used.

Cleared to 0.

14:11

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used.

21:18

IndexReg:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

IndexReg invalid (0 = valid; 1 = invalid)

26:23

BaseReg (encoded as IndexReg above)

Undefined for memory instructions with no base register (bit 27 is set).

BaseReg invalid (0 = valid; 1 = invalid)

31:28

Reg2 (same encoding as IndexReg above)

Vol. 3C

28-17

VM EXITS

Table 28-10. Format of the VM-Exit Instruction-Information Field as Used for LIDT, LGDT, SIDT, or SGDT

Bit Position(s)

Content

1:0

Scaling:

0: no scaling

1: scale by 2

2: scale by 4

3: scale by 8 (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

6:2

Undefined.

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used.

Cleared to 0.

Operand size:

0: 16-bit

1: 32-bit

Undefined for VM exits from 64-bit mode.

14:12

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used.

21:18

IndexReg:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

IndexReg invalid (0 = valid; 1 = invalid)

26:23

BaseReg (encoded as IndexReg above)

Undefined for instructions with no base register (bit 27 is set).

BaseReg invalid (0 = valid; 1 = invalid)

29:28

Instruction identity:

0: SGDT

1: SIDT

2: LGDT

3: LIDT

28-18

Vol. 3C

VM EXITS

Table 28-10. Format of the VM-Exit Instruction-Information Field as Used for LIDT, LGDT, SIDT, or SGDT (Contd.)

Bit Position(s)

Content

31:30

Undefined.

Table 28-11. Format of the VM-Exit Instruction-Information Field as Used for LLDT, LTR, SLDT, and STR

Bit Position(s)

Content

1:0

Scaling:

0: no scaling

1: scale by 2

2: scale by 4

3: scale by 8 (used only on processors that support Intel 64 architecture)

Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear

and bit 22 is set).

Undefined.

6:3

Reg1:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

Undefined for memory instructions (bit 10 is clear).

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used. Undefined for register instructions (bit 10 is set).

Mem/Reg (0 = memory; 1 = register).

14:11

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used. Undefined for register instructions (bit 10 is set).

21:18

IndexReg (encoded as Reg1 above)

Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear

and bit 22 is set).

IndexReg invalid (0 = valid; 1 = invalid)

Undefined for register instructions (bit 10 is set).

26:23

BaseReg (encoded as Reg1 above)

Undefined for register instructions (bit 10 is set) and for memory instructions with no base register (bit 10 is clear

and bit 27 is set).

Vol. 3C

28-19

VM EXITS

Table 28-11. Format of the VM-Exit Instruction-Information Field as Used for LLDT, LTR, SLDT, and STR (Contd.)

Bit Position(s)

Content

BaseReg invalid (0 = valid; 1 = invalid)

Undefined for register instructions (bit 10 is set).

29:28

Instruction identity:

0: SLDT

1: STR

2: LLDT

3: LTR

31:30

Undefined.

Table 28-12. Format of the VM-Exit Instruction-Information Field as Used for RDRAND and RDSEED

Bit Position(s)

Content

2:0

Undefined.

6:3

Operand register (destination register):

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

10:7

Undefined.

12:11

Operand size:

0: 16-bit

1: 32-bit

2: 64-bit

The value 3 is not used.

31:13

Undefined.

Table 28-13. Format of the VM-Exit Instruction-Information Field as Used for TPAUSE and UMWAIT

Bit Position(s)

Content

2:0

Undefined.

6:3

Operand register (source register):

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

31:7

Undefined.

28-20

Vol. 3C

VM EXITS

Table 28-14. Format of the VM-Exit Instruction-Information Field as Used for VMCLEAR, VMPTRLD, VMPTRST,

VMXON, XRSTORS, and XSAVES

Bit Position(s)

Content

1:0

Scaling:

0: no scaling

1: scale by 2

2: scale by 4

3: scale by 8 (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

6:2

Undefined.

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used.

Cleared to 0.

14:11

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used.

21:18

IndexReg:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

Undefined for instructions with no index register (bit 22 is set).

IndexReg invalid (0 = valid; 1 = invalid)

26:23

BaseReg (encoded as IndexReg above)

Undefined for instructions with no base register (bit 27 is set).

BaseReg invalid (0 = valid; 1 = invalid)

31:28

Undefined.

28.3

SAVING GUEST STATE

VM exits save certain components of processor state into corresponding fields in the guest-state area of the VMCS

(see Section 25.4). On processors that support Intel 64 architecture, the full value of each natural-width field (see

Section 25.11.2) is saved regardless of the mode of the logical processor before and after the VM exit.

Vol. 3C

28-21

VM EXITS

Table 28-15. Format of the VM-Exit Instruction-Information Field as Used for VMREAD and VMWRITE

Bit Position(s)

Content

1:0

Scaling:

0: no scaling

1: scale by 2

2: scale by 4

3: scale by 8 (used only on processors that support Intel 64 architecture)

Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear

and bit 22 is set).

Undefined.

6:3

Reg1:

0 = RAX

1 = RCX

2 = RDX

3 = RBX

4 = RSP

5 = RBP

6 = RSI

7 = RDI

8-15 represent R8-R15, respectively (used only on processors that support Intel 64 architecture)

Undefined for memory instructions (bit 10 is clear).

9:7

Address size:

0: 16-bit

1: 32-bit

2: 64-bit (used only on processors that support Intel 64 architecture)

Other values not used. Undefined for register instructions (bit 10 is set).

Mem/Reg (0 = memory; 1 = register).

14:11

Undefined.

17:15

Segment register:

0: ES

1: CS

2: SS

3: DS

4: FS

5: GS

Other values not used. Undefined for register instructions (bit 10 is set).

21:18

IndexReg (encoded as Reg1 above)

Undefined for register instructions (bit 10 is set) and for memory instructions with no index register (bit 10 is clear

and bit 22 is set).

IndexReg invalid (0 = valid; 1 = invalid)

Undefined for register instructions (bit 10 is set).

26:23

BaseReg (encoded as Reg1 above)

Undefined for register instructions (bit 10 is set) and for memory instructions with no base register (bit 10 is clear

and bit 27 is set).

BaseReg invalid (0 = valid; 1 = invalid)

Undefined for register instructions (bit 10 is set).

31:28

Reg2 (same encoding as Reg1 above)

In general, the state saved is that which was in the logical processor at the time the VM exit commences. See

Section 28.1 for a discussion of which architectural updates occur at that time.

28-22

Vol. 3C

VM EXITS

Table 28-16. Format of the VM-Exit Instruction-Information Field as Used for LOADIWKEY

Bit Position(s)

Content

2:0

Undefined.

6:3

Reg1: identifies the first XMM register operand (XMM0-XMM15; values 8-15 are used only on processors that

support Intel 64 architecture).

30:7

Undefined.

31:28

Reg2: identifies the second XMM register operand (see above).

Section 28.3.1 through Section 28.3.4 provide details for how various components of processor state are saved.

These sections reference VMCS fields that correspond to processor state. Unless otherwise stated, these refer-

ences are to fields in the guest-state area.

28.3.1 Saving Control Registers, Debug Registers, and MSRs

Contents of certain control registers, debug registers, and MSRs are saved as follows:

•

The contents of CR0, CR3, CR4, and the IA32_SYSENTER_CS, IA32_SYSENTER_ESP, and IA32_SYSENTER_EIP

MSRs are saved into the corresponding fields. Bits 63:32 of the IA32_SYSENTER_CS MSR are not saved. On

processors that do not support Intel 64 architecture, bits 63:32 of the IA32_SYSENTER_ESP and

IA32_SYSENTER_EIP MSRs are not saved.

•

If the “save debug controls” VM-exit control is 1, the contents of DR7 and the IA32_DEBUGCTL MSR are saved

into the corresponding fields. The first processors to support the virtual-machine extensions supported only the

1-setting of this control and thus always saved data into these fields.

•

If the “save IA32_PAT” VM-exit control is 1, the contents of the IA32_PAT MSR are saved into the corresponding

field.

•

If the “save IA32_EFER” VM-exit control is 1, the contents of the IA32_EFER MSR are saved into the corre-

sponding field.

•

If the processor supports either the 1-setting of the “load IA32_BNDCFGS” VM-entry control or that of the

“clear IA32_BNDCFGS” VM-exit control, the contents of the IA32_BNDCFGS MSR are saved into the corre-

sponding field.

•

If the processor supports either the 1-setting of the “load IA32_RTIT_CTL” VM-entry control or that of the

“clear IA32_RTIT_CTL” VM-exit control, the contents of the IA32_RTIT_CTL MSR are saved into the corre-

sponding field.

•

If the processor supports the 1-setting of the “load CET” VM-entry control, the contents of the IA32_S_CET and

IA32_INTERRUPT_SSP_TABLE_ADDR MSRs are saved into the corresponding fields. On processors that do not

support Intel 64 architecture, bits 63:32 of these MSRs are not saved.

•

If the processor supports either the 1-setting of the “load guest IA32_LBR_CTL” VM-entry control or that of the

“clear IA32_LBR_CTL” VM-exit control, the contents of the IA32_LBR_CTL MSR are saved into the corre-

sponding field.

•

If the processor supports the 1-setting of the “load PKRS” VM-entry control, the contents of the IA32_PKRS

MSR are saved into the corresponding field.

•

If a processor supports user interrupts, every VM exit saves UINV into the guest UINV field in the VMCS

(bits 15:8 of the field are cleared).

•

If the “save IA32_PERF_GLOBAL_CTL” VM-exit control is 1, the contents of the IA32_PERF_GLOBAL_CTL MSR

are saved into the corresponding field.

•

The value of the SMBASE field is undefined after all VM exits except SMM VM exits. See Section 32.15.2.

28.3.2 Saving Segment Registers and Descriptor-Table Registers

For each segment register (CS, SS, DS, ES, FS, GS, LDTR, or TR), the values saved for the base-address, segment-

limit, and access rights are based on whether the register was unusable (see Section 25.4.1) before the VM exit:

Vol. 3C

28-23

VM EXITS

• If the register was unusable, the values saved into the following fields are undefined: (1) base address;

(2) segment limit; and (3) bits 7:0 and bits 15:12 in the access-rights field. The following exceptions apply:

- CS.

• The base-address and segment-limit fields are saved.

• The L, D, and G bits are saved in the access-rights field.

- SS.

• DPL is saved in the access-rights field.

• On processors that support Intel 64 architecture, bits 63:32 of the value saved for the base address are

always zero.

- DS and ES. On processors that support Intel 64 architecture, bits 63:32 of the values saved for the base

addresses are always zero.

- FS and GS. The base-address field is saved.

- LDTR. The value saved for the base address is always canonical.

• If the register was not unusable, the values saved into the following fields are those which were in the register

before the VM exit: (1) base address; (2) segment limit; and (3) bits 7:0 and bits 15:12 in access rights.

• Bits 31:17 and 11:8 in the access-rights field are always cleared. Bit 16 is set to 1 if and only if the segment is

unusable.

The contents of the GDTR and IDTR registers are saved into the corresponding base-address and limit fields.

28.3.3 Saving RIP, RSP, RFLAGS, and SSP

The contents of the RIP, RSP, RFLAGS, and SSP (shadow-stack pointer) registers are saved as follows:

• The value saved in the RIP field is determined by the nature and cause of the VM exit:

- If the VM exit occurred in enclave mode, the value saved is the AEP of interrupted enclave thread (the

remaining items do not apply).

- If the VM exit occurs due to by an attempt to execute an instruction that causes VM exits unconditionally or

that has been configured to cause a VM exit via the VM-execution controls, the value saved references that

instruction.

- If the VM exit is caused by an occurrence of an INIT signal, a start-up IPI (SIPI), or system-management

interrupt (SMI), the value saved is that which was in RIP before the event occurred.

- If the VM exit occurs due to the 1-setting of either the “interrupt-window exiting” VM-execution control or

the “NMI-window exiting” VM-execution control, the value saved is that which would be in the register had

the VM exit not occurred.

- If the VM exit is due to an external interrupt, non-maskable interrupt (NMI), or hardware exception (as

defined in Section 28.2.2), the value saved is the return pointer that would have been saved (either on the

stack had the event been delivered through a trap or interrupt gate,¹ or into the old task-state segment had

the event been delivered through a task gate).

- If the VM exit is due to a triple fault, the value saved is the return pointer that would have been saved

(either on the stack had the event been delivered through a trap or interrupt gate, or into the old task-state

segment had the event been delivered through a task gate) had delivery of the double fault not

encountered the nested exception that caused the triple fault.

- If the VM exit is due to a software exception (due to an execution of INT3 or INTO) or a privileged software

exception (due to an execution of INT1), the value saved references the INT3, INTO, or INT1 instruction

that caused that exception.

1. The reference here is to the full value of RIP before any truncation that would occur had the stack width been only 32 bits or 16

bits.

28-24

Vol. 3C

VM EXITS

- Suppose that the VM exit is due to a task switch that was caused by execution of CALL, IRET, or JMP or by

execution of a software interrupt (INT n), software exception (due to execution of INT3 or INTO), or

privileged software exception (due to execution of INT1) that encountered a task gate in the IDT. The value

saved references the instruction that caused the task switch (CALL, IRET, JMP, INT n, INT3, INTO, INT1).

- Suppose that the VM exit is due to a task switch that was caused by a task gate in the IDT that was

encountered for any reason except the direct access by a software interrupt or software exception. The

value saved is that which would have been saved in the old task-state segment had the task switch

completed normally.

- If the VM exit is due to an execution of MOV to CR8 or WRMSR that reduced the value of bits 7:4 of VTPR

(see Section 30.1.1) below that of TPR threshold VM-execution control field (see Section 30.1.2), the value

saved references the instruction following the MOV to CR8 or WRMSR.

- If the VM exit was caused by APIC-write emulation (see Section 30.4.3.2) that results from an APIC access

as part of instruction execution, the value saved references the instruction following the one whose

execution caused the APIC-write emulation.

•

The contents of the RSP register are saved into the RSP field.

•

With the exception of the resume flag (RF; bit 16), the contents of the RFLAGS register is saved into the

RFLAGS field. RFLAGS.RF is saved as follows:

- If the VM exit occurred in enclave mode, the value saved is 0 (the remaining items do not apply).

- If the VM exit is caused directly by an event that would normally be delivered through the IDT, the value

saved is that which would appear in the saved RFLAGS image (either that which would be saved on the

stack had the event been delivered through a trap or interrupt gate¹ or into the old task-state segment had

the event been delivered through a task gate) had the event been delivered through the IDT. See below for

VM exits due to task switches caused by task gates in the IDT.

- If the VM exit is caused by a triple fault, the value saved is that which the logical processor would have in

RF in the RFLAGS register had the triple fault taken the logical processor to the shutdown state.

- If the VM exit is caused by a task switch (including one caused by a task gate in the IDT), the value saved

is that which would have been saved in the RFLAGS image in the old task-state segment (TSS) had the task

switch completed normally without exception.

- If the VM exit is caused by an attempt to execute an instruction that unconditionally causes VM exits or one

that was configured to do with a VM-execution control, the value saved is 0.²

- For APIC-access VM exits and for VM exits caused by EPT violations, EPT misconfigurations, page-modifi-

cation log-full events, or SPP-related events, the value saved depends on whether the VM exit occurred

during delivery of an event through the IDT:

• If the VM exit stored 0 for bit 31 for IDT-vectoring information field (because the VM exit did not occur

during delivery of an event through the IDT; see Section 28.2.4), the value saved is 1.

• If the VM exit stored 1 for bit 31 for IDT-vectoring information field (because the VM exit did occur

during delivery of an event through the IDT), the value saved is the value that would have appeared in

the saved RFLAGS image had the event been delivered through the IDT (see above).

- For all other VM exits, the value saved is the value RFLAGS.RF had before the VM exit occurred.

•

If the processor supports the 1-setting of the “load CET” VM-entry control, the contents of the SSP register are

saved into the SSP field.

1. The reference here is to the full value of RFLAGS before any truncation that would occur had the stack width been only 32 bits or

16 bits.

2. This is true even if RFLAGS.RF was 1 before the instruction was executed. If, in response to such a VM exit, a VM monitor re-enters

the guest to re-execute the instruction that caused the VM exit (for example, after clearing the VM-execution control that caused

the VM exit), the instruction may encounter a code breakpoint that has already been processed. A VM monitor can avoid this by set-

ting the guest value of RFLAGS.RF to 1 before resuming guest software.

Vol. 3C

28-25

VM EXITS

28.3.4 Saving Non-Register State

Information corresponding to guest non-register state is saved as follows:

•

The activity-state field is saved with the logical processor’s activity state before the VM exit.¹ See Section 28.1

for details of how events leading to a VM exit may affect the activity state. If the VM exit occurred during user-

interrupt notification processing (see Section 7.5.2) and the logical processor would have entered the HLT state

following user-interrupt notification processing, the saved activity state is “HLT”.

•

The interruptibility-state field is saved to reflect the logical processor’s interruptibility before the VM exit.

- See Section 28.1 for details of how events leading to a VM exit may affect this state.

- VM exits that end outside system-management mode (SMM) save bit 2 (blocking by SMI) as 0 regardless

of the state of such blocking before the VM exit.

- Bit 3 (blocking by NMI) is treated specially if the “virtual NMIs” VM-execution control is 1. In this case, the

value saved for this field does not indicate the blocking of NMIs but rather the state of virtual-NMI blocking.

- Bit 4 (enclave interruption) is set to 1 if the VM exit occurred while the logical processor was in enclave

mode.

Such VM exits includes those caused by interrupts, non-maskable interrupts, system-management

interrupts, INIT signals, and exceptions occurring in enclave mode as well as exceptions encountered

during the delivery of such events incident to enclave mode.

A VM exit that is incident to delivery of an event injected by VM entry leaves this bit unmodified.

•

The pending debug exceptions field is saved as clear for all VM exits except the following:

- A VM exit caused by an INIT signal, a machine-check exception, or a system-management interrupt (SMI).

- A VM exit with basic exit reason “TPR below threshold”,² “virtualized EOI”, “APIC write”, “monitor trap flag,”

or “bus-lock detected.”

- A VM exit due to trace-address pre-translation (TAPT; see Section 26.5.4) or due to accesses related to

PEBS on processors with the “EPT-friendly” enhancement (see Section 20.9.5). Such VM exits can have

basic exit reason “APIC access,” “EPT violation,” “EPT misconfiguration,” “page-modification log full,” or

“SPP-related event.” When due to TAPT or PEBS, these VM exits (with the exception of those due to EPT

misconfigurations) set bit 16 of the exit qualification, indicating that they are asynchronous to instruction

execution and not part of event delivery.

- VM exits that are not caused by debug exceptions and that occur while there is MOV-SS blocking of debug

exceptions.

For VM exits that do not clear the field, the value saved is determined as follows:

- Each of bits 3:0 may be set if it corresponds to a matched breakpoint. This may be true even if the corre-

sponding breakpoint is not enabled in DR7.

- Suppose that a VM exit is due to an INIT signal, a machine-check exception, or an SMI; or that a VM exit

has basic exit reason “TPR below threshold” or “monitor trap flag.” In this case, the value saved sets bits

corresponding to the causes of any debug exceptions that were pending at the time of the VM exit.

If the VM exit occurs immediately after VM entry, the value saved may match that which was loaded on

VM entry (see Section 27.7.3). Otherwise, the following items apply:

• Bit 12 (enabled breakpoint) is set to 1 in any of the following cases:

- If there was at least one matched data or I/O breakpoint that was enabled in DR7.

- If it had been set on VM entry, causing there to be valid pending debug exceptions (see Section

27.7.3) and the VM exit occurred before those exceptions were either delivered or lost.

- If the XBEGIN instruction was executed immediately before the VM exit and advanced debugging of

RTM transactional regions had been enabled (see Section 16.3.7, “RTM-Enabled Debugger

If this activity state was an inactive state resulting from execution of a specific instruction (HLT or MWAIT), the value saved for RIP

by that VM exit will reference the following instruction.

This item includes VM exits that occur as a result of certain VM entries (Section 27.7.7).

28-26

Vol. 3C

VM EXITS

Support,” of Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1). (This does

not apply to VM exits with basic exit reason “monitor trap flag.”)

- If a bus lock was asserted while CPL > 0 and OS bus-lock detection was enabled.

In other cases, bit 12 is cleared to 0.

• Bit 14 (BS) is set if RFLAGS.TF = 1 in either of the following cases:

- IA32_DEBUGCTL.BTF = 0 and the cause of a pending debug exception was the execution of a single

instruction.

- IA32_DEBUGCTL.BTF = 1 and the cause of a pending debug exception was a taken branch.

• Bit 16 (RTM) is set if a debug exception (#DB) or a breakpoint exception (#BP) occurred inside an RTM

region while advanced debugging of RTM transactional regions had been enabled. (This does not apply

to VM exits with basic exit reason “monitor trap flag.”)

- Suppose that a VM exit is due to another reason (but not a debug exception) and occurs while there is MOV-

SS blocking of debug exceptions. In this case, the value saved sets bits corresponding to the causes of any

debug exceptions that were pending at the time of the VM exit. If the VM exit occurs immediately after

VM entry (no instructions were executed in VMX non-root operation), the value saved may match that

which was loaded on VM entry (see Section 27.7.3). Otherwise, the following items apply:

• Bit 12 (enabled breakpoint) is set to 1 if there was at least one matched data or I/O breakpoint that was

enabled in DR7. Bit 12 is also set if it had been set on VM entry, causing there to be valid pending debug

exceptions (see Section 27.7.3) and the VM exit occurred before those exceptions were either delivered

or lost. In other cases, bit 12 is cleared to 0.

• The setting of bit 14 (BS) is implementation-specific. However, it is not set if RFLAGS.TF = 0 or

IA32_DEBUGCTL.BTF = 1.

- The reserved bits in the field are cleared.

•

If the “save VMX-preemption timer value” VM-exit control is 1, the value of timer is saved into the VMX-

preemption timer-value field. This is the value loaded from this field on VM entry as subsequently decremented

(see Section 26.5.1). VM exits due to timer expiration save the value 0. Other VM exits may also save the value

0 if the timer expired during VM exit. (If the “save VMX-preemption timer value” VM-exit control is 0, VM exit

does not modify the value of the VMX-preemption timer-value field.)

•

If the logical processor supports the 1-setting of the “enable EPT” VM-execution control, values are saved into

the four (4) PDPTE fields as follows:

- If the “enable EPT” VM-execution control is 1 and the logical processor was using PAE paging at the time of

the VM exit, the PDPTE values currently in use are saved:¹

• The values saved into bits 11:9 of each of the fields is undefined.

• If the value saved into one of the fields has bit 0 (present) clear, the value saved into bits 63:1 of that

field is undefined. That value need not correspond to the value that was loaded by VM entry or to any

value that might have been loaded in VMX non-root operation.

• If the value saved into one of the fields has bit 0 (present) set, the value saved into bits 63:12 of the

field is a guest-physical address.

- If the “enable EPT” VM-execution control is 0 or the logical processor was not using PAE paging at the time

of the VM exit, the values saved are undefined.

1. A logical processor uses PAE paging if CR0.PG = 1, CR4.PAE = 1 and IA32_EFER.LMA = 0. See Section 4.4 in the Intel^®64 and IA-32

Architectures Software Developer’s Manual, Volume 3A. “Enable EPT” is a secondary processor-based VM-execution control. If bit 31

of the primary processor-based VM-execution controls is 0, VM exit functions as if the “enable EPT” VM-execution control were 0.

See Section 25.6.2.

Vol. 3C

28-27

VM EXITS

28.4

SAVING MSRS

After processor state is saved to the guest-state area, values of MSRs may be stored into the VM-exit MSR-store

area (see Section 25.7.2). Specifically each entry in that area (up to the number specified in the VM-exit MSR-store

count) is processed in order by storing the value of the MSR indexed by bits 31:0 (as they would be read by

RDMSR) into bits 127:64. Processing of an entry fails in either of the following cases:

• The value of bits 31:8 is 000008H, meaning that the indexed MSR is one that allows access to an APIC register

when the local APIC is in x2APIC mode.

• The value of bits 31:0 indicates an MSR that can be read only in system-management mode (SMM) and the

VM exit will not end in SMM. (IA32_SMBASE is an MSR that can be read only in SMM.)

• The value of bits 31:0 indicates an MSR that cannot be saved on VM exits for model-specific reasons. A

processor may prevent certain MSRs (based on the value of bits 31:0) from being stored on VM exits, even if

they can normally be read by RDMSR. Such model-specific behavior is documented in Chapter 2, “Model-

Specific Registers (MSRs)‚” in the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4.

• Bits 63:32 of the entry are not all 0.

• An attempt to read the MSR indexed by bits 31:0 would cause a general-protection exception if executed via

RDMSR with CPL = 0.

A VMX abort occurs if processing fails for any entry. See Section 28.7.

28.5

LOADING HOST STATE

Processor state is updated on VM exits in the following ways:

• Some state is loaded from or otherwise determined by the contents of the host-state area.

• Some state is determined by VM-exit controls.

• Some state is established in the same way on every VM exit.

• The page-directory pointers are loaded based on the values of certain control registers.

This loading may be performed in any order.

On processors that support Intel 64 architecture, the full values of each 64-bit field loaded (for example, the base

address for GDTR) is loaded regardless of the mode of the logical processor before and after the VM exit.

The loading of host state is detailed in Section 28.5.1 to Section 28.5.5. These sections reference VMCS fields that

correspond to processor state. Unless otherwise stated, these references are to fields in the host-state area.

A logical processor is in IA-32e mode after a VM exit only if the “host address-space size” VM-exit control is 1. If the

logical processor was in IA-32e mode before the VM exit and this control is 0, a VMX abort occurs. See Section

28.7.

In addition to loading host state, VM exits clear address-range monitoring (Section 28.5.6).

After the state loading described in this section, VM exits may load MSRs from the VM-exit MSR-load area (see

Section 28.6). This loading occurs only after the state loading described in this section.

28.5.1 Loading Host Control Registers, Debug Registers, MSRs

VM exits load new values for controls registers, debug registers, and some MSRs:

• CR0, CR3, and CR4 are loaded from the CR0 field, the CR3 field, and the CR4 field, respectively, with the

following exceptions:

- The following bits are not modified:

• For CR0, ET, CD, NW; bits 63:32 (on processors that support Intel 64 architecture), 28:19, 17, and

15:6; and any bits that are fixed in VMX operation (see Section 24.8).¹

• For CR3, bits 63:52 and bits in the range 51:32 beyond the processor’s physical-address width (they

are cleared to 0).² (This item applies only to processors that support Intel 64 architecture.)

28-28

Vol. 3C

VM EXITS

• For CR4, any bits that are fixed in VMX operation (see Section 24.8).

- CR4.PAE is set to 1 if the “host address-space size” VM-exit control is 1.

- CR4.PCIDE is set to 0 if the “host address-space size” VM-exit control is 0.

•

DR7 is set to 400H.

•

If the “clear UINV” VM-exit control is 1, VM exit clears UINV.

•

The following MSRs are established as follows:

- The IA32_DEBUGCTL MSR is cleared to 00000000_00000000H.

- The IA32_SYSENTER_CS MSR is loaded from the IA32_SYSENTER_CS field. Since that field has only 32

bits, bits 63:32 of the MSR are cleared to 0.

- The IA32_SYSENTER_ESP and IA32_SYSENTER_EIP MSRs are loaded from the IA32_SYSENTER_ESP and

IA32_SYSENTER_EIP fields, respectively.

If the processor does not support the Intel 64 architecture, these fields have only 32 bits; bits 63:32 of the

MSRs are cleared to 0.

If the processor supports the Intel 64 architecture with N < 64 linear-address bits, each of bits 63:N is set

to the value of bit N-1.¹

- The following steps are performed on processors that support Intel 64 architecture:

• The MSRs FS.base and GS.base are loaded from the base-address fields for FS and GS, respectively

(see Section 28.5.2).

• The LMA and LME bits in the IA32_EFER MSR are each loaded with the setting of the “host address-

space size” VM-exit control.

- If the “load IA32_PERF_GLOBAL_CTRL” VM-exit control is 1, the IA32_PERF_GLOBAL_CTRL MSR is loaded

from the IA32_PERF_GLOBAL_CTRL field. Bits that are reserved in that MSR are maintained with their

reserved values.

- If the “load IA32_PAT” VM-exit control is 1, the IA32_PAT MSR is loaded from the IA32_PAT field. Bits that

are reserved in that MSR are maintained with their reserved values.

- If the “load IA32_EFER” VM-exit control is 1, the IA32_EFER MSR is loaded from the IA32_EFER field. Bits

that are reserved in that MSR are maintained with their reserved values.

- If the “clear IA32_BNDCFGS” VM-exit control is 1, the IA32_BNDCFGS MSR is cleared to

00000000_00000000H; otherwise, it is not modified.

- If the “clear IA32_RTIT_CTL” VM-exit control is 1, the IA32_RTIT_CTL MSR is cleared to

00000000_00000000H; otherwise, it is not modified.

- If the “load CET” VM-exit control is 1, the IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR MSRs are

loaded from the IA32_S_CET and IA32_INTERRUPT_SSP_TABLE_ADDR fields, respectively.

If the processor does not support the Intel 64 architecture, these fields have only 32 bits; bits 63:32 of the

MSRs are cleared to 0.

If the processor supports the Intel 64 architecture with N < 64 linear-address bits, each of bits 63:N is set

to the value of bit N-1.

- If the “load PKRS” VM-exit control is 1, the IA32_PKRS MSR is loaded from the IA32_PKRS field. Bits 63:32

of that MSR are maintained with zeroes.

With the exception of FS.base and GS.base, any of these MSRs is subsequently overwritten if it appears in the

VM-exit MSR-load area. See Section 28.6.

Bits 28:19, 17, and 15:6 of CR0 and CR0.ET are unchanged by executions of MOV to CR0. CR0.ET is always 1 and the other bits are

always 0.

Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address

width is returned in bits 7:0 of EAX.

Software can determine the number N by executing CPUID with 80000008H in EAX. The number of linear-address bits supported is

returned in bits 15:8 of EAX.

Vol. 3C

28-29

VM EXITS

28.5.2 Loading Host Segment and Descriptor-Table Registers

Each of the registers CS, SS, DS, ES, FS, GS, and TR is loaded as follows (see below for the treatment of LDTR):

•

The selector is loaded from the selector field. The segment is unusable if its selector is loaded with zero. The

checks specified in Section 27.2.3 limit the selector values that may be loaded. In particular, CS and TR are

never loaded with zero and are thus never unusable. SS can be loaded with zero only on processors that

support Intel 64 architecture and only if the VM exit is to 64-bit mode (64-bit mode allows use of segments

marked unusable).

•

The base address is set as follows:

- CS. Cleared to zero.

- SS, DS, and ES. Undefined if the segment is unusable; otherwise, cleared to zero.

- FS and GS. Undefined (but, on processors that support Intel 64 architecture, canonical) if the segment is

unusable and the VM exit is not to 64-bit mode; otherwise, loaded from the base-address field.

If the processor supports the Intel 64 architecture and the processor supports N < 64 linear-address bits,

each of bits 63:N is set to the value of bit N-1.¹ The values loaded for base addresses for FS and GS are

also manifest in the FS.base and GS.base MSRs.

- TR. Loaded from the host-state area. If the processor supports the Intel 64 architecture and the processor

supports N < 64 linear-address bits, each of bits 63:N is set to the value of bit N-1.

•

The segment limit is set as follows:

- CS. Set to FFFFFFFFH (corresponding to a descriptor limit of FFFFFH and a G-bit setting of 1).

- SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to FFFFFFFFH.

- TR. Set to 00000067H.

•

The type field and S bit are set as follows:

- CS. Type set to 11 and S set to 1 (execute/read, accessed, non-conforming code segment).

- SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, type set to 3 and S set to 1

(read/write, accessed, expand-up data segment).

- TR. Type set to 11 and S set to 0 (busy 32-bit task-state segment).

•

The DPL is set as follows:

- CS, SS, and TR. Set to 0. The current privilege level (CPL) will be 0 after the VM exit completes.

- DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 0.

•

The P bit is set as follows:

- CS, TR. Set to 1.

- SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.

•

On processors that support Intel 64 architecture, CS.L is loaded with the setting of the “host address-space

size” VM-exit control. Because the value of this control is also loaded into IA32_EFER.LMA (see Section 28.5.1),

no VM exit is ever to compatibility mode (which requires IA32_EFER.LMA = 1 and CS.L = 0).

•

D/B.

- CS. Loaded with the inverse of the setting of the “host address-space size” VM-exit control. For example, if

that control is 0, indicating a 32-bit guest, CS.D/B is set to 1.

- SS. Set to 1.

- DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.

- TR. Set to 0.

•

Software can determine the number N by executing CPUID with 80000008H in EAX. The number of linear-address bits supported is

returned in bits 15:8 of EAX.

28-30

Vol. 3C

VM EXITS

- CS. Set to 1.

- SS, DS, ES, FS, and GS. Undefined if the segment is unusable; otherwise, set to 1.

- TR. Set to 0.

The host-state area does not contain a selector field for LDTR. LDTR is established as follows on all VM exits: the

selector is cleared to 0000H, the segment is marked unusable and is otherwise undefined (although the base

address is always canonical).

The base addresses for GDTR and IDTR are loaded from the GDTR base-address field and the IDTR base-address

field, respectively. If the processor supports the Intel 64 architecture and the processor supports N < 64 linear-

address bits, each of bits 63:N of each base address is set to the value of bit N-1 of that base address. The GDTR

and IDTR limits are each set to FFFFH.

28.5.3 Loading Host RIP, RSP, RFLAGS, and SSP

RIP and RSP are loaded from the RIP field and the RSP field, respectively. RFLAGS is cleared, except bit 1, which is

always set.

If the “load CET” VM-exit control is 1, SSP (shadow-stack pointer) is loaded from the SSP field.

28.5.4 Checking and Loading Host Page-Directory-Pointer-Table Entries

If CR0.PG = 1, CR4.PAE = 1, and IA32_EFER.LMA = 0, the logical processor uses PAE paging. See Section 4.4 of

the Intel^®64 and IA-32 Architectures Software Developer’s Manual, Volume 3A.¹ When in PAE paging is in use, the

physical address in CR3 references a table of page-directory-pointer-table entries (PDPTEs). A MOV to CR3

when PAE paging is in use checks the validity of the PDPTEs and, if they are valid, loads them into the processor

(into internal, non-architectural registers).

A VM exit is to a VMM that uses PAE paging if (1) bit 5 (corresponding to CR4.PAE) is set in the CR4 field in the

host-state area of the VMCS; and (2) the “host address-space size” VM-exit control is 0. Such a VM exit may check

the validity of the PDPTEs referenced by the CR3 field in the host-state area of the VMCS. Such a VM exit must

check their validity if either (1) PAE paging was not in use before the VM exit; or (2) the value of CR3 is changing

as a result of the VM exit. A VM exit to a VMM that does not use PAE paging must not check the validity of the

PDPTEs.

A VM exit that checks the validity of the PDPTEs uses the same checks that are used when CR3 is loaded with

MOV to CR3 when PAE paging is in use. If MOV to CR3 would cause a general-protection exception due to the

PDPTEs that would be loaded (e.g., because a reserved bit is set), a VMX abort occurs (see Section 28.7). If a

VM exit to a VMM that uses PAE does not cause a VMX abort, the PDPTEs are loaded into the processor as would

MOV to CR3, using the value of CR3 being load by the VM exit.

28.5.5 Updating Non-Register State

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

• A logical processor is always in the active state after a VM exit.

• Event blocking is affected as follows:

- There is no blocking by STI or by MOV SS after a VM exit.

- VM exits caused directly by non-maskable interrupts (NMIs) cause blocking by NMI (see Table 25-3). Other

VM exits do not affect blocking by NMI. (See Section 28.1 for the case in which an NMI causes a VM exit

indirectly.)

• There are no pending debug exceptions after a VM exit.

1. On processors that support Intel 64 architecture, the physical-address extension may support more than 36 physical-address bits.

Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address

width is returned in bits 7:0 of EAX.

Vol. 3C

28-31

VM EXITS

Section 29.4 describes how the VMX architecture controls how a logical processor manages information in the TLBs

and paging-structure caches. The following items detail how VM exits invalidate cached mappings:

• If the “enable VPID” VM-execution control is 0, the logical processor invalidates 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).

• VM exits are not required to invalidate any guest-physical mappings, nor are they required to invalidate any

linear mappings or combined mappings if the “enable VPID” VM-execution control is 1.

28.5.6 Clearing Address-Range Monitoring

The Intel 64 and IA-32 architectures allow software to monitor a specified address range using the MONITOR and

MWAIT instructions. See Section 9.10.4 in the Intel^®64 and IA-32 Architectures Software Developer’s Manual,

Volume 3A. VM exits clear any address-range monitoring that may be in effect.

28.6

LOADING MSRS

VM exits may load MSRs from the VM-exit MSR-load area (see Section 25.7.2). Specifically each entry in that area

(up to the number specified in the VM-exit MSR-load count) is processed in order by loading the MSR indexed by

bits 31:0 with the contents of bits 127:64 as they would be written by WRMSR.

Processing of an entry fails in any of the following cases:

• The value of bits 31:0 is either C0000100H (the IA32_FS_BASE MSR) or C0000101H (the IA32_GS_BASE

MSR).

• The value of bits 31:8 is 000008H, meaning that the indexed MSR is one that allows access to an APIC register

when the local APIC is in x2APIC mode.

• The value of bits 31:0 indicates an MSR that can be written only in system-management mode (SMM) and the

VM exit will not end in SMM. (IA32_SMM_MONITOR_CTL is an MSR that can be written only in SMM.)

• The value of bits 31:0 indicates an MSR that cannot be loaded on VM exits for model-specific reasons. A

processor may prevent loading of certain MSRs even if they can normally be written by WRMSR. Such model-

specific behavior is documented in Chapter 2, “Model-Specific Registers (MSRs)‚” in the Intel^® 64 and IA-32

Architectures Software Developer’s Manual, Volume 4.

• Bits 63:32 are not all 0.

• An attempt to write bits 127:64 to the MSR indexed by bits 31:0 of the entry would cause a general-protection

exception if executed via WRMSR with CPL = 0.¹

If processing fails for any entry, a VMX abort occurs. See Section 28.7.

If any MSR is being loaded in such a way that would architecturally require a TLB flush, the TLBs are updated so

that, after VM exit, the logical processor does not use any translations that were cached before the transition.

28.7

VMX ABORTS

A problem encountered during a VM exit leads to a VMX abort. A VMX abort takes a logical processor into a shut-

down state as described below.

A VMX abort does not modify the VMCS data in the VMCS region of any active VMCS. The contents of these data are

thus suspect after the VMX abort.

On a VMX abort, a logical processor saves a nonzero 32-bit VMX-abort indicator field at byte offset 4 in the VMCS

region of the VMCS whose misconfiguration caused the failure (see Section 25.2). The following values are used:

1. Note the following about processors that support Intel 64 architecture. If CR0.PG = 1, WRMSR to the IA32_EFER MSR causes a gen-

eral-protection exception if it would modify the LME bit. Since CR0.PG is always 1 in VMX operation, the IA32_EFER MSR should not

be included in the VM-exit MSR-load area for the purpose of modifying the LME bit.

28-32

Vol. 3C

VM EXITS

1. There was a failure in saving guest MSRs (see Section 28.4).

2. Host checking of the page-directory-pointer-table entries (PDPTEs) failed (see Section 28.5.4).

3. The current VMCS has been corrupted (through writes to the corresponding VMCS region) in such a way that

the logical processor cannot complete the VM exit properly.

4. There was a failure on loading host MSRs (see Section 28.6).

5. There was a machine-check event during VM exit (see Section 28.8).

6. The logical processor was in IA-32e mode before the VM exit and the “host address-space size” VM-exit control

was 0 (see Section 28.5).

Some of these causes correspond to failures during the loading of state from the host-state area. Because the

loading of such state may be done in any order (see Section 28.5) a VM exit that might lead to a VMX abort for

multiple reasons (for example, the current VMCS may be corrupt and the host PDPTEs might not be properly

configured). In such cases, the VMX-abort indicator could correspond to any one of those reasons.

A logical processor never reads the VMX-abort indicator in a VMCS region and writes it only with one of the non-

zero values mentioned above. The VMX-abort indicator allows software on one logical processor to diagnose the

VMX-abort on another. For this reason, it is recommended that software running in VMX root operation zero the

VMX-abort indicator in the VMCS region of any VMCS that it uses.

After saving the VMX-abort indicator, operation of a logical processor experiencing a VMX abort depends on

whether the logical processor is in SMX operation:¹

• If the logical processor is in SMX operation, an Intel^® TXT shutdown condition occurs. The error code used is

000DH, indicating “VMX abort.” See the Intel^® Trusted Execution Technology Measured Launched Environment

Programming Guide.

• If the logical processor is outside SMX operation, it issues a special bus cycle (to notify the chipset) and enters

the VMX-abort shutdown state. RESET is the only event that wakes a logical processor from the VMX-abort

shutdown state. The following events do not affect a logical processor in this state: machine-check events;

INIT signals; external interrupts; non-maskable interrupts (NMIs); start-up IPIs (SIPIs); and system-

management interrupts (SMIs).

28.8

MACHINE-CHECK EVENTS DURING VM EXIT

If a machine-check event occurs during VM exit, one of the following occurs:

• The machine-check event is handled as if it occurred before the VM exit:

- If CR4.MCE = 0, operation of the logical processor depends on whether the logical processor is in SMX

operation:¹

• If the logical processor is in SMX operation, an Intel^® TXT shutdown condition occurs. The error code

used is 000CH, indicating “unrecoverable machine-check condition.”

• If the logical processor is outside SMX operation, it goes to the shutdown state.

- If CR4.MCE = 1, a machine-check exception (#MC) is generated:

• If bit 18 (#MC) of the exception bitmap is 0, the exception is delivered through the guest IDT.

• If bit 18 of the exception bitmap is 1, the exception causes a VM exit.

• The machine-check event is handled after VM exit completes:

- If the VM exit ends with CR4.MCE = 0, operation of the logical processor 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 Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volume 2D.

Vol. 3C

28-33

VM EXITS

• If the logical processor is in SMX operation, an Intel^® TXT shutdown condition occurs with error code

000CH (unrecoverable machine-check condition).

• If the logical processor is outside SMX operation, it goes to the shutdown state.

- If the VM exit ends with CR4.MCE = 1, a machine-check exception (#MC) is delivered through the host IDT.

• A VMX abort is generated (see Section 28.7). The logical processor blocks events as done normally in

VMX abort. The VMX abort indicator is 5, for “machine-check event during VM exit.”

The first option is not used if the machine-check event occurs after any host state has been loaded. The second

option is used only if VM entry is able to load all host state.

28.9

USER-INTERRUPT RECOGNITION AFTER VM EXIT

A VM exit results in recognition of a pending user interrupt if it completes with CR4.UINTR = IA32_EFER.LMA = 1

and with UIRR ≠ 0; otherwise, no pending user interrupt is recognized.

28-34

Vol. 3C

CHAPTER 32

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).

32.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 32.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 32.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 32-4). (This does not apply if the dual-monitor treatment of SMIs

and SMM is active; see Section 32.15.)

Vol. 3C

32-1

SYSTEM MANAGEMENT MODE

32.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 32.2 through Section 32.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 32.14, “Default Treatment of SMIs and SMM with VMX Operation and

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

and SMM.”

32.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.

32.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.

32.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 32.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.

32-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 32.5 for a detailed description of the execution environment when in SMM.

32.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.

NOTE

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

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

loading it into SSP.

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 32.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.

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 32.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 32.10). Also, the SMBASE address can be changed on a return from SMM (see Section

32.11).

Vol. 3C

32-3

SYSTEM MANAGEMENT MODE

32.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 32-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 32.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 32.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 32.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.

32.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 32-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.

SMRAM

SMBASE + FFFFH

Start of State Save Area

SMI Handler Entry Point

SMBASE + 8000H

SMBASE

Figure 32-1. SMRAM Usage

32-4

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 32-1. SMRAM State Save Map

Offset

Writable?

(Added to SMBASE + 8000H)

7FFCH

CR0

7FF8H

CR3

7FF4H

EFLAGS

Yes

7FF0H

EIP

Yes

7FECH

EDI

Yes

7FE8H

ESI

Yes

7FE4H

EBP

Yes

7FE0H

ESP

Yes

7FDCH

EBX

Yes

7FD8H

EDX

Yes

7FD4H

ECX

Yes

7FD0H

EAX

Yes

7FCCH

DR6

7FC8H

DR7

7FC4H

TR¹

7FC0H

Reserved

7FBCH

GS¹

7FB8H

FS¹

7FB4H

DS¹

7FB0H

SS¹

7FACH

CS¹

7FA8H

ES¹

7FA4H

I/O State Field, see Section 32.7

7FA0H

I/O Memory Address Field, see Section 32.7

7F9FH-7F03H

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 - 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:

Vol. 3C

32-5

SYSTEM MANAGEMENT MODE

• 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.

32.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 32-3.

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

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

Table 32-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

32-6

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 32-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

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

Vol. 3C

32-7

SYSTEM MANAGEMENT MODE

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

Offset

Writable?

(Added to SMBASE + 8000H)

7EF7H - 7EE4H

Reserved

7EE0H

Setting of “enable EPT” VM-execution control

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.

32.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

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

32-8

Vol. 3C

SYSTEM MANAGEMENT MODE

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.

32.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 12.11.2.4.

32.5

SMI HANDLER EXECUTION ENVIRONMENT

Section 32.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 32.5.2 discusses modifications an SMI

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

(CET) interactions in the environment.

32.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 32-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 32-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)

Vol. 3C

32-9

SYSTEM MANAGEMENT MODE

Table 32-4. Processor Register Initialization in SMM

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 32.6).

32.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 10, “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 32.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.

32-10

Vol. 3C

SYSTEM MANAGEMENT MODE

32.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.

32.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 32.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).

• 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.

Vol. 3C

32-11

SYSTEM MANAGEMENT MODE

32.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.

32.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 32-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 32-5. I/O Instruction Information in the SMM State Save Map

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

Format

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 32-6)

Table 32-6. I/O Instruction Type Encodings

Instruction

Encoding

IN Immediate

1001

IN DX

0001

OUT Immediate

1000

32-12

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 32-6. I/O Instruction Type Encodings (Contd.)

Instruction

Encoding

OUT DX

0000

INS

0011

OUTS

0010

REP INS

0111

REP OUTS

0110

32.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.

32.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 32-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.

7EFCH

18 17 16 15

Reserved

SMM Revision Identifier

SMBASE Relocation

I/O Instruction Restart

Figure 32-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 32.12); if the SMBASE relocation flag

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

Vol. 3C

32-13

SYSTEM MANAGEMENT MODE

32.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 32-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 32-3. Auto HALT Restart Field

These options are summarized in Table 32-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 32-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

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

for the same HLT instruction.

32.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.

32.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 32-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

32-14

Vol. 3C

SYSTEM MANAGEMENT MODE

+ 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 32-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 32.9).

32.12 I/O INSTRUCTION RESTART

If the I/O instruction restart flag in the SMM revision identifier field is set (see Section 32.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 32-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.)

I/O Instruction Restart Field

7F00H

Figure 32-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 32-8 summarizes the states of the I/O instruction restart field.

Vol. 3C

32-15

SYSTEM MANAGEMENT MODE

Table 32-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.

32.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.

32.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.

• 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 32.11).

32.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.

32-16

Vol. 3C

SYSTEM MANAGEMENT MODE

32.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 29.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 25-3 in Section 25.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 26.5.2). These data may be saved internal to the processor or in the VMCS region of the current

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 32-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.

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

2. Section 32.14 and Section 32.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.

3. “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 25.6.2.

Vol. 3C

32-17

SYSTEM MANAGEMENT MODE

32.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 29.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 32.14.1;

set to their fixed values any bits in CR0 and CR4 whose values must be fixed in VMX operation (see Section 24.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;

RSM unblocks SMIs. It restores the state of blocking by NMI (see Table 25-3 in Section 25.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 26.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:

1. 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.

2. “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 25.6.2.

32-18

Vol. 3C

SYSTEM MANAGEMENT MODE

• 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 32.10). They do not occur if the logical processor just entered the shutdown state.

32.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.

32.14.4 VMXOFF and SMI Unblocking

The VMXOFF instruction can be executed only with the default treatment (see Section 32.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 32.15.5 for details regarding this MSR).¹ Section 32.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.

32.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.

32.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 32.15.2. SMM

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 32.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 32.15.4.

Initially, there is no STM and the default treatment (Section 32.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 32.15.5 and Section 32.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 32.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.

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

32-19

SYSTEM MANAGEMENT MODE

32.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

32.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 32.15.6).

Differences between SMM VM exits and other VM exits are detailed in Sections 32.15.2.1 through 32.15.2.5.

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

in Section 32.15.6.

32.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.

32.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.

32.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.

- 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 25-18 in Section 25.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 32-9.

• 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

32-20

Vol. 3C

SYSTEM MANAGEMENT MODE

Table 32-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.

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.

32.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.

32.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 32.15.4).

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 28.3.1), which must be the case if the “Intel PT uses guest physi-

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

Vol. 3C

32-21

SYSTEM MANAGEMENT MODE

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 29.4). (Ordinary VM exits are not required to perform such invalidation if the “enable VPID” VM-

execution control is 1; see Section 28.5.5.)

32.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 32.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 26.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 32.15.4).

32.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 32.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 32.15.4.1 through

32.15.4.10.

32.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.^1,2

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

VMCS revision identifier (see Section 25.2).

The checks above are performed before the checks described in Section 32.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 25.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 32.15.7).³

32.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 27.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:

1. Software can determine a processor’s physical-address width by executing CPUID with 80000008H in EAX. The physical-address

width is returned in bits 7:0 of EAX.

2. 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.

3. 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.

32-22

Vol. 3C

SYSTEM MANAGEMENT MODE

• 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.

32.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 27.2.1.3.

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

operation), the VM-entry interruption-information field must not indicate injection of a pending MTF VM exit (see

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

• the valid bit (bit 31) is 1

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

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

32.15.4.4 Checks on the Guest State Area

Section 27.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).

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).

32.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

29.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 27.3.2.5.)

32.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.

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.

Vol. 3C

32-23

SYSTEM MANAGEMENT MODE

32.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.

32.15.4.8 VM Exits Induced by VM Entry

Section 27.6.1.2 describes how the event-delivery process invoked by event injection may lead to a VM exit.

Section 27.7.3 to Section 27.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 32.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.

32.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.

- 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.

32.15.4.10 Failures of VM Entries That Return from SMM

Section 27.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.

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.

32-24

Vol. 3C

SYSTEM MANAGEMENT MODE

32.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 32.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 32.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_SMM_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.

The 32 bytes located at the MSEG base address are called the MSEG header. The format of the MSEG header is

given in Table 32-10 (each field is 32 bits).

Table 32-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

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

32-25

SYSTEM MANAGEMENT MODE

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 32.15.6).

• Bytes 31:8 contain fields that determine how processor state is loaded when the STM is activated (see Section

32.15.6.5). SMM code should establish these fields so that activating of the STM invokes the STM’s initialization

code.

32.15.6 Activating the Dual-Monitor Treatment

The dual-monitor treatment may be enabled by SMM code as described in Section 32.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 32.15.6.1 through 32.15.6.6. See also “VMCALL-Call to

VM Monitor” in Chapter 31.

32.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

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 32.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).

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.

2. Software should consult the VMX capability MSR IA32_VMX_BASIC (see Appendix A.1) to determine whether the dual-monitor

treatment is supported.

32-26

Vol. 3C

SYSTEM MANAGEMENT MODE

• 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.

32.15.6.2 Updating the Current-VMCS and Executive-VMCS Pointers

Before performing the steps in Section 32.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.

32.15.6.3 Saving Guest State

As noted in Section 32.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.

• 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.

32.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.

32.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 28.5. Instead, state is set to fixed

values or loaded based on the content of the MSEG header (see Table 32-10):

• CR0 is set to as follows:

- PG, NE, ET, MP, and PE are all set to 1.

- CD and NW are left unchanged.

Vol. 3C

32-27

SYSTEM MANAGEMENT MODE

- 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, and LA57 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.

• 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 corresponding

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).

32-28

Vol. 3C

SYSTEM MANAGEMENT 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).

32.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.

32.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 32.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 27.2.1.3 and Section 32.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 32.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:¹

• 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 32.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.

32.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.

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

32-29

SYSTEM MANAGEMENT MODE

32.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.

32.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 32.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.

32.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

32.17.3 Blocked SMI Reporting

A logical processor may have entered into a state and blocked from servicing other interrupts (including SMI).

Logical processors in a physical processor that are blocked in serving SMI can be queried in a package-scope

cause a #GP.

Details of the interface of MSR_SMM_BLOCKED is 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.

32-30

Vol. 3C

CHAPTER 1

ABOUT THIS MANUAL

The Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 4: Model-Specific Registers (order

number 335592) is part of a set that describes the architecture and programming environment of Intel^® 64 and IA-

32 architecture processors. Other volumes in this set are:

• Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture (order number

253665).

• Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 2A, 2B, 2C, & 2D: Instruction Set

Reference (order numbers 253666, 253667, 326018, and 334569).

• The Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C, & 3D: System

Programming Guide (order numbers 253668, 253669, 326019, and 332831).

The Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, describes the basic architecture

and programming environment of Intel 64 and IA-32 processors. The Intel^® 64 and IA-32 Architectures Software

Developer’s Manual, Volumes 2A, 2B, 2C, & 2D, describe the instruction set of the processor and the opcode struc-

ture. These volumes apply to application programmers and to programmers who write operating systems or exec-

utives. The Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volumes 3A, 3B, 3C, & 3D, describe

the operating-system support environment of Intel 64 and IA-32 processors. These volumes target operating-

system and BIOS designers. In addition, the Intel^® 64 and IA-32 Architectures Software Developer’s Manual,

Volume 3B, and the Intel^® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3C, address the

programming environment for classes of software that host operating systems. The Intel^® 64 and IA-32 Architec-

tures Software Developer’s Manual, Volume 4, describes the model-specific registers of Intel 64 and IA-32 proces-

sors.

1.1

INTEL® 64 AND IA-32 PROCESSORS COVERED IN THIS MANUAL

This manual set includes information pertaining primarily to the most recent Intel 64 and IA-32 processors, which

include:

• Pentium^® processors

• P6 family processors

• Pentium^® 4 processors

• Pentium^® M processors

• Intel^® Xeon^® processors

• Pentium^® D processors

• Pentium^® processor Extreme Editions

•

64-bit Intel^® Xeon^® processors

• Intel^® Core™ Duo processor

• Intel^® Core™ Solo processor

• Dual-Core Intel^® Xeon^® processor LV

• Intel^® Core™ 2 Duo processor

• Intel^® Core™ 2 Quad processor Q6000 series

• Intel^® Xeon^® processor 3000, 3200 series

• Intel^® Xeon^® processor 5000 series

• Intel^® Xeon^® processor 5100, 5300 series

• Intel^® Core™ 2 Extreme processor X7000 and X6800 series

• Intel^® Core™ 2 Extreme QX6000 series

Vol. 4

1-1

Intel 64 and IA-32 Architectures. Software Developer’s Manual (Collection, 2023) - page 7