Vol. 3C 33-1
CHAPTER 33
HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR
33.1 OVERVIEW
This chapter describes what a VMM must consider when handling exceptions, interrupts, error conditions, and tran-
sitions between activity states.
33.2
INTERRUPT HANDLING IN VMX OPERATION
The following bullets summarize VMX support for handling interrupts:
•
Control of processor exceptions. The VMM can get control on specific guest exceptions through the
exception-bitmap in the guest controlling VMCS. The exception bitmap is a 32-bit field that allows the VMM to
specify processor behavior on specific exceptions (including traps, faults, and aborts). Setting a specific bit in
the exception bitmap implies VM exits will be generated when the corresponding exception occurs. Any
exceptions that are programmed not to cause VM exits are delivered directly to the guest through the guest
IDT. The exception bitmap also controls execution of relevant instructions such as BOUND, INTO and INT3. VM
exits on page-faults are treated in such a way the page-fault error code is qualified through the page-fault-
error-code mask and match fields in the VMCS.
•
Control over triple faults. If a fault occurs while attempting to call a double-fault handler in the guest and
that fault is not configured to cause a VM exit in the exception bitmap, the resulting triple fault causes a
VM exit.
•
Control of external interrupts. VMX allows both host and guest control of external interrupts through the
“external-interrupt exiting” VM execution control. If the control is 0, external-interrupts do not cause VM exits
and the interrupt delivery is masked by the guest programmed RFLAGS.IF value.
1
If the control is 1, external-
interrupts causes VM exits and are not masked by RFLAGS.IF. The VMM can identify VM exits due to external
interrupts by checking the exit reason for an “external interrupt” (value = 1).
•
Control of other events. There is a pin-based VM-execution control that controls system behavior (exit or no-
exit) for NMI events. Most VMM usages will need handling of NMI external events in the VMM and hence will
specify host control of these events.
Some processors also support a pin-based VM-execution control called “virtual NMIs.” When this control is set,
NMIs cause VM exits, but the processor tracks guest readiness for virtual NMIs. This control interacts with the
“NMI-window exiting” VM-execution control (see below).
INIT and SIPI events always cause VM exits.
•
Acknowledge interrupt on exit. The “acknowledge interrupt on exit” VM-exit control in the controlling VMCS
controls processor behavior for external interrupt acknowledgement. If the control is 1, the processor acknowl-
edges the interrupt controller to acquire the interrupt vector upon VM exit, and stores the vector in the VM-exit
interruption-information field. If the control is 0, the external interrupt is not acknowledged during VM exit.
Since RFLAGS.IF is automatically cleared on VM exits due to external interrupts, VMM re-enabling of interrupts
(setting RFLAGS.IF = 1) initiates the external interrupt acknowledgement and vectoring of the external
interrupt through the monitor/host IDT.
•
Event-masking Support. VMX captures the masking conditions of specific events while in VMX non-root
operation through the interruptibility-state field in the guest-state area of the VMCS.
This feature allows proper virtualization of various interrupt blocking states, such as: (a) blocking of external
interrupts for the instruction following STI; (b) blocking of interrupts for the instruction following a MOV-SS or
POP-SS instruction; (c) SMI blocking of subsequent SMIs until the next execution of RSM; and (d) NMI/SMI
blocking of NMIs until the next execution of IRET or RSM.
1. This chapter uses the notation RAX, RIP, RSP, RFLAGS, etc. for processor registers because most processors that support VMX oper-
ation also support Intel 64 architecture. For processors that do not support Intel 64 architecture, this notation refers to the 32-bit
forms of those registers (EAX, EIP, ESP, EFLAGS, etc.).