33-2 Vol. 3C
HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR
INIT and SIPI events are treated specially. INIT assertions are always blocked in VMX root operation and while
in SMM, and unblocked otherwise. SIPI events are always blocked in VMX root operation.
The interruptibility state is loaded from the VMCS guest-state area on every VM entry and saved into the VMCS
on every VM exit.
•
Event injection. VMX operation allows injecting interruptions to a guest virtual machine through the use of
VM-entry interrupt-information field in VMCS. Injectable interruptions include external interrupts, NMI,
processor exceptions, software generated interrupts, and software traps. If the interrupt-information field
indicates a valid interrupt, exception or trap event upon the next VM entry; the processor will use the
information in the field to vector a virtual interruption through the guest IDT after all guest state and MSRs are
loaded. Delivery through the guest IDT emulates vectoring in non-VMX operation by doing the normal privilege
checks and pushing appropriate entries to the guest stack (entries may include RFLAGS, EIP and exception
error code). A VMM with host control of NMI and external interrupts can use the event-injection facility to
forward virtual interruptions to various guest virtual machines.
•
Interrupt-window exiting. When set to 1, the “interrupt-window exiting” VM-execution control (Section
24.6.2) causes VM exits when guest RFLAGS.IF is 1 and no other conditions block external interrupts. A VM exit
occurs at the beginning of any instruction at which RFLAGS.IF = 1 and on which the interruptibility state of the
guest would allow delivery of an interrupt. For example: when the guest executes an STI instruction,
RFLAGS = 1, and if at the completion of next instruction the interruptibility state masking due to STI is
removed; a VM exit occurs if the “interrupt-window exiting” VM-execution control is 1. This feature allows a
VMM to queue a virtual interrupt to the guest when the guest is not in an interruptible state. The VMM can set
the “interrupt-window exiting” VM-execution control for the guest and depend on a VM exit to know when the
guest becomes interruptible (and, therefore, when it can inject a virtual interrupt). The VMM can detect such
VM exits by checking for the basic exit reason “interrupt-window” (value = 7). If this feature is not used, the
VMM will need to poll and check the interruptibility state of the guest to deliver virtual interrupts.
•
NMI-window exiting. If the “virtual NMIs” VM-execution is set, the processor tracks virtual-NMI blocking.
The “NMI-window exiting” VM-execution control (Section 24.6.2) causes VM exits when there is no virtual-NMI
blocking. For example, after execution of the IRET instruction, a VM exit occurs if the “NMI-window exiting” VM-
execution control is 1. This feature allows a VMM to queue a virtual NMI to a guest when the guest is not ready
to receive NMIs. The VMM can set the “NMI-window exiting” VM-execution control for the guest and depend on
a VM exit to know when the guest becomes ready for NMIs (and, therefore, when it can inject a virtual NMI).
The VMM can detect such VM exits by checking for the basic exit reason “NMI window” (value = 8). If this
feature is not used, the VMM will need to poll and check the interruptibility state of the guest to deliver virtual
NMIs.
•
VM-exit information. The VM-exit information fields provide details on VM exits due to exceptions and
interrupts. This information is provided through the exit-qualification, VM-exit-interruption-information,
instruction-length and interruption-error-code fields. Also, for VM exits that occur in the course of vectoring
through the guest IDT, information about the event that was being vectored through the guest IDT is provided
in the IDT-vectoring-information and IDT-vectoring-error-code fields. These information fields allow the VMM to
identify the exception cause and to handle it properly.
33.3
EXTERNAL INTERRUPT VIRTUALIZATION
VMX operation allows both host and guest control of external interrupts. While guest control of external interrupts
might be suitable for partitioned usages (different CPU cores/threads and I/O devices partitioned to independent
virtual machines), most VMMs built upon VMX are expected to utilize host control of external interrupts. The rest of
this section describes a general host-controlled interrupt virtualization architecture for standard PC platforms
through the use of VMX supported features.
With host control of external interrupts, the VMM (or the host OS in a hosted VMM model) manages the physical
interrupt controllers in the platform and the interrupts generated through them. The VMM exposes software-
emulated virtual interrupt controller devices (such as PIC and APIC) to each guest virtual machine instance.