Vol. 3C 34-23

SYSTEM MANAGEMENT MODE

•

the valid bit (bit 31) in the VM-entry interruption-information field is 1

•

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

•

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

34.15.4.4   Checks on the Guest State Area

Section 26.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:

1

•

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).

34.15.4.5   Loading Guest State

VM entries that return from SMM load the SMBASE register from the SMBASE field.
VM entries that return from SMM invalidate linear mappings and combined mappings associated with all VPIDs. 
Combined mappings are invalidated for all EP4TA values (EP4TA is the value of bits 51:12 of EPTP; see Section 
28.3). (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 26.3.2.5.)

34.15.4.6   VMX-Preemption Timer

A VM entry that returns from SMM activates the VMX-preemption timer only if the executive-VMCS pointer field 
does not contain the VMXON pointer (the VM entry enters VMX non-root operation) and the “activate VMX-preemp-
tion timer” VM-execution control is 1 in the executive VMCS (the VMCS referenced by the executive-VMCS pointer 
field). In this case, VM entry starts the VMX-preemption timer with the value in the VMX-preemption timer-value 
field in the current VMCS.

34.15.4.7   Updating the Current-VMCS and SMM-Transfer VMCS Pointers

Successful VM entries (returning from SMM) load the SMM-transfer VMCS pointer with the current-VMCS pointer. 
Following this, they load the current-VMCS pointer from a field in the current VMCS:

•

If the executive-VMCS pointer field contains the VMXON pointer (the VM entry remains in VMX root operation), 
the current-VMCS pointer is loaded from the VMCS-link pointer field.

•

If the executive-VMCS pointer field does not contain the VMXON pointer (the VM entry enters VMX non-root 
operation), the current-VMCS pointer is loaded with the value of the executive-VMCS pointer field.

If the VM entry successfully enters VMX non-root operation, the VM-execution controls in effect after the VM entry 
are those from the new current VMCS. This includes any structures external to the VMCS referenced by VM-execu-
tion control fields.
The updating of these VMCS pointers occurs before event injection. Event injection is determined, however, by the 
VM-entry control fields in the VMCS that was current when the VM entry commenced.

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.