Vol. 3C 34-29
SYSTEM MANAGEMENT MODE
sary for changes that would not affect paging due to the settings of other bits (for example, changes to CR4.PSE if
IA32_EFER.LMA was 1 before and after the transition).
34.15.6.7 Loading MSRs
The VM-exit MSR-load area is not used by SMM VM exits that activate the dual-monitor treatment. No MSRs are
loaded from that area.
34.15.7 Deactivating the Dual-Monitor Treatment
The SMM-transfer monitor may deactivate the dual-monitor treatment and return the processor to default treat-
ment of SMIs and SMM (see Section 34.14). It does this by executing a VM entry with the “deactivate dual-monitor
treatment” VM-entry control set to 1.
As noted in Section 26.2.1.3 and Section 34.15.4.1, an attempt to deactivate the dual-monitor treatment fails in
the following situations: (1) the processor is not in SMM; (2) the “entry to SMM” VM-entry control is 1; or (3) the
executive-VMCS pointer does not contain the VMXON pointer (the VM entry is to VMX non-root operation).
As noted in Section 34.15.4.9, VM entries that deactivate the dual-monitor treatment ignore the SMI bit in the
interruptibility-state field of the guest-state area. Instead, the blocking of SMIs following such a VM entry depends
on whether the logical processor is in SMX operation:
1
•
If the logical processor is in SMX operation, SMIs are blocked after VM entry. SMIs may later be unblocked by
the VMXOFF instruction (see Section 34.14.4) or by certain leaf functions of the GETSEC instruction (see
Chapter 6, “Safer Mode Extensions Reference,” in Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 2D).
•
If the logical processor is outside SMX operation, SMIs are unblocked after VM entry.
34.16 SMI AND PROCESSOR EXTENDED STATE MANAGEMENT
On processors that support processor extended states using XSAVE/XRSTOR (see Chapter 13, “Managing State
Using the XSAVE Feature Set” of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1),
the processor does not save any XSAVE/XRSTOR related state on an SMI. It is the responsibility of the SMI handler
code to properly preserve the state information (including CR4.OSXSAVE, XCR0, and possibly processor extended
states using XSAVE/XRSTOR). Therefore, the SMI handler must follow the rules described in Chapter 13,
“Managing State Using the XSAVE Feature Set” of the Intel® 64 and IA-32 Architectures Software Developer’s
Manual, Volume 1.
34.17 MODEL-SPECIFIC SYSTEM MANAGEMENT ENHANCEMENT
This section describes enhancement of system management features that apply only to the 4th generation Intel
Core processors. These features are model-specific. BIOS and SMM handler must use CPUID to enumerate
DisplayFamily_DisplayModel signature when programming with these interfaces.
34.17.1 SMM Handler Code Access Control
The BIOS may choose to restrict the address ranges of code that SMM handler executes. When SMM handler code
execution check is enabled, an attempt by the SMM handler to execute outside the ranges specified by SMRR (see
Section 34.4.2.1) will cause the assertion of an unrecoverable machine check exception (MCE).
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 6, “Safer Mode Extensions Reference,” in Intel® 64 and IA-32 Architectures Software