background image

31-8 Vol. 3C

VIRTUAL-MACHINE MONITOR PROGRAMMING CONSIDERATIONS

•

Depending on the exit reason, fetch other relevant fields from the VMCS. Appendix C lists the various exit 
reasons.

•

Handle the VM-exit condition appropriately in the VMM. This may involve the VMM emulating one or more guest 
instructions, programming the underlying host hardware resources, and then re-entering the VM to continue 
execution. 

31.7.1 

Handling VM Exits Due to Exceptions

As noted in Section 25.2, an exception causes a VM exit if the bit corresponding to the exception’s vector is set in 
the exception bitmap. (For page faults, the error code also determines whether a VM exit occurs.) This section 
provide some guidelines of how a VMM might handle such exceptions.
Exceptions result when a logical processor encounters an unusual condition that software may not have expected. 
When guest software encounters an exception, it may be the case that the condition was caused by the guest soft-
ware. For example, a guest application may attempt to access a page that is restricted to supervisor access. Alter-
natively, the condition causing the exception may have been established by the VMM. For example, a guest OS may 
attempt to access a page that the VMM has chosen to make not present.
When the condition causing an exception was established by guest software, the VMM may choose to reflect the 
exception to guest software. When the condition was established by the VMM itself, the VMM may choose to 
resume guest software after removing the condition.

31.7.1.1   Reflecting Exceptions to Guest Software

If the VMM determines that a VM exit was caused by an exception due to a condition established by guest software, 
it may reflect that exception to guest software. The VMM would cause the exception to be delivered to guest soft-
ware, where it can be handled as it would be if the guest were running on a physical machine. This section 
describes how that may be done.
In general, the VMM can deliver the exception to guest software using VM-entry event injection as described in 
Section 26.5. The VMM can copy (using VMREAD and VMWRITE) the contents of the VM-exit interruption-informa-
tion field (which is valid, since the VM exit was caused by an exception) to the VM-entry interruption-information 
field (which, if valid, will cause the exception to be delivered as part of the next VM entry). The VMM would also 
copy the contents of the VM-exit interruption error-code field to the VM-entry exception error-code field; this need 
not be done if bit 11 (error code valid) is clear in the VM-exit interruption-information field. After this, the VMM can 
execute VMRESUME.
The following items provide details that may qualify the general approach:

•

Care should be taken to ensure that reserved bits 30:12 in the VM-entry interruption-information field are 0. In 
particular, some VM exits may set bit 12 in the VM-exit interruption-information field to indicate NMI 
unblocking due to IRET. If this bit is copied as 1 into the VM-entry interruption-information field, the next 
VM entry will fail because that bit should be 0.

•

Bit 31 (valid) of the IDT-vectoring information field indicates, if set, that the exception causing the VM exit 
occurred while another event was being delivered to guest software. If this is the case, it may not be 
appropriate simply to reflect that exception to guest software. To provide proper virtualization of the exception 
architecture, a VMM should handle nested events as a physical processor would. Processor handling is 
described in Chapter 6, “Interrupt 8—Double Fault Exception (#DF)” iIntel® 64 and IA-32 Architectures 
Software Developer’s Manual, Volume 3A
.
— The VMM should reflect the exception causing the VM exit to guest software in any of the following cases:

•

The value of bits 10:8 (interruption type) of the IDT-vectoring information field is anything other than 3 

(hardware exception).

•

The value of bits 7:0 (vector) of the IDT-vectoring information field indicates a benign exception (1, 2, 

3, 4, 5, 6, 7, 9, 16, 17, 18, or 19).

•

The value of bits 7:0 (vector) of the VM-exit interruption-information field indicates a benign exception.