Vol. 3C 33-9

HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR

b. Normal delivery after VM entry. If CR4.MCE = 1 after VM entry, delivery of a machine-check exception 

(#MC) through the guest IDT occurs (alternatively, this exception may cause a VM exit). If CR4.MCE = 0, 
the processor goes to shutdown state.

c. Load state from the host-state area of the working VMCS as if a VM exit had occurred (see Section 26.7). 

The basic exit reason will be “VM-entry failure due to machine-check event.” 

If the machine-check event occurs after any guest state has been loaded, option a above will not be used; it 
may be used if the machine-check event occurs while checking host state and VMX controls (or while reporting 
a failure due to such checks). An implementation may use option b only if all guest state has been loaded 
properly.

•

VM exit: 
If a machine-check event occurs during VM exit, one of the following three treatments must occur:
a. Normal delivery before VM exit. If CR4.MCE = 1 before the VM exit, delivery of a machine-check exception 

(#MC) through the guest IDT (alternatively, this may cause a VM exit). If CR4.MCE = 0, the processor goes 
to shutdown state.

b. Normal delivery after VM exit. If CR4.MCE = 1 after the VM exit, delivery of a machine-check exception 

(#MC) through the host IDT. If CR4.MCE = 0, the processor goes to shutdown state.

c. Fail the VM exit. If the VM exit is to VMX root operation, a VMX abort will result; it will block events as done 

normally in VMX abort. The VMX abort indicator will show that a machine-check event induced the abort 
operation.

If a machine-check event is induced by an action in VMX non-root operation before any determination is made 
that the inducing action may cause a VM exit, that machine-check event should be considered as happening 
during guest execution in VMX non-root operation. This is the case even if the part of the action that caused the 
machine-check event was VMX-specific (for example, the processor’s consulting an I/O bitmap). If a machine-
check exception occurs and if bit 12H of the exception bitmap is cleared to 0, the exception is delivered to the 
guest through gate 12H of its IDT; if the bit is set to 1, the machine-check exception causes a VM exit.

NOTE

The state saved in the guest-state area on VM exits due to machine-check exceptions should be 
considered suspect. A VMM should consult the RIPV and EIPV bits in the IA32_MCG_STATUS MSR 
before resuming a guest that caused a VM exit due to a machine-check exception.

33.4.3 

MCA Error Handling Guidelines for VMM

Section 33.4.2 covers general requirements for VMMs to handle machine-check exceptions, when normal operation 
of the guest machine and/or the VMM is no longer possible. enhancements of machine-check architecture in newer 
processors may support software recovery of uncorrected MC errors (UCR) signaled through either machine-check 
exceptions or corrected machine-check interrupt (CMCI). Section 15.5 and Section 15.6 describes details of these 
more recent enhancements of machine-check architecture.
In general, Virtual Machine Monitor (VMM) error handling should follow the recommendations for OS error handling 
described in Section 15.3, Section 15.6, Section 15.9, and Section 15.10. This section describes additional guide-
lines for hosted and native hypervisor-based VMM implementations to support corrected MC errors and recoverable 
uncorrected MC errors.
Because a hosted VMM provides virtualization services in the context of an existing standard host OS, the host OS 
controls platform hardware through the host OS services such as the standard OS device drivers. In hosted VMMs. 
MCA errors will be handled by the host OS error handling software.
In native VMMs, the hypervisor runs on the hardware directly, and may provide only a limited set of platform 
services for guest VMs. Most platform services may instead be provided by a “control OS”. In hypervisor-based 
VMMs, MCA errors will either be delivered directly to the VMM MCA handler (when the error is signaled while in the 
VMM context) or cause by a VM exit from a guest VM or be delivered to the MCA intercept handler. There are two 
general approaches the hypervisor can use to handle the MCA error: either within the hypervisor itself or by 
forwarding the error to the control OS.