33-8 Vol. 3C

HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR

depending on the VMM event priority policies, the VMM may need to queue the external virtual interrupt if a 
higher priority event is to be delivered on the next VM entry. Since the VMM has masked this particular interrupt 
source (if it was level triggered) and done EOI to the platform interrupt controller, other platform interrupts can 
be serviced while this virtual interrupt event is queued for later delivery to the VM.

5. Update the virtual interrupt controller state. When the above checks have passed, before generating the virtual 

interrupt to the guest, the VMM updates the virtual interrupt controller state (Local-APIC, IO-APIC and/or PIC) 
to reflect assertion of the virtual interrupt. This involves updating the various interrupt capture registers, and 
priority registers as done by the respective hardware interrupt controllers. Updating the virtual interrupt 
controller state is required for proper interrupt event processing by guest software.

6. Inject the virtual interrupt on VM entry. To inject an external virtual interrupt to a guest VM, the VMM sets up 

the VM-entry interruption-information field in the guest controlling-VMCS before entry to guest using 
VMRESUME. Upon VM entry, the processor will use this vector to access the gate in guest’s IDT and the value of 
RFLAGS and EIP in guest-state area of controlling-VMCS is pushed on the guest stack. If the guest RFLAGS.IF 
is clear, the STI-masking bit is set, or the MOV- SS/POP-SS-masking bit is set, the VM entry will fail and the 
processor will load state from the host-state area of the working VMCS as if a VM exit had occurred (see Section 
26.7).

33.4 

ERROR HANDLING BY VMM

Error conditions may occur during VM entries and VM exits and a few other situations. This section describes how 
VMM should handle these error conditions, including triple faults and machine-check exceptions.

33.4.1 VM-Exit 

Failures

All VM exits load processor state from the host-state area of the VMCS that was the controlling VMCS before the VM 
exit. This state is checked for consistency while being loaded. Because the host-state is checked on VM entry, these 
checks will generally succeed. Failure is possible only if host software is incorrect or if VMCS data in the VMCS 
region in memory has been written by guest software (or by I/O DMA) since the last VM entry. VM exits may fail for 
the following reasons:

•

There was a failure on storing guest MSRs.

•

There was failure in loading a PDPTR.

•

The controlling VMCS has been corrupted (through writes to the corresponding VMCS region) in such a way that 
the implementation cannot complete the VM exit.

•

There was a failure on loading host MSRs.

•

A machine-check event occurred.

If one of these problems occurs on a VM exit, a VMX abort results. 

33.4.2 Machine-Check 

Considerations

The following sequence determine how machine-check events are handled during VMXON, VMXOFF, VM entries, 
and VM exits:

•

VMXOFF and VMXON: 
If a machine-check event occurs during VMXOFF or VMXON and CR4.MCE = 1, a machine-check exception 
(#MC) is generated. If CR4.MCE = 0, the processor goes to shutdown state.

•

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

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