Vol. 3C 33-7
HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR
33.3.3.3 Processing of External Interrupts by VMM
Upon VM exit, the VMM can determine the exit cause of an external interrupt by checking the exit-reason field
(value = 1) in VMCS. If the acknowledge-interrupt-on-exit control (see Section 24.7.1) is enabled, the VMM can
use the saved host vector (in the exit-interruption-information field) to switch to the appropriate interrupt handler.
If the “acknowledge interrupt on exit” VM-exit control is 0, the VMM may re-enable interrupts (by setting
RFLAGS.IF) to allow vectoring of external interrupts through the monitor/host IDT.
The following steps may need to be performed by the VMM to process an external interrupt:
•
Host Owned I/O Devices: For host-owned I/O devices, the interrupting device is owned by the VMM (or
hosting OS in a hosted VMM). In this model, the interrupt service routine in the VMM/host driver is invoked and,
upon ISR completion, the appropriate write sequences (TPR updates, EOI etc.) to respective interrupt
controllers are performed as normal. If the work completion indicated by the driver implies virtual device
activity, the VMM runs the virtual device emulation. Depending on the device class, physical device activity
could imply activity by multiple virtual devices mapped over the device. For each affected virtual device, the
VMM injects a virtual external interrupt event to respective guest virtual machines. The guest driver interacts
with the emulated virtual device to process the virtual interrupt. The interrupt controller emulation in the VMM
supports various guest accesses to the VMM’s virtual interrupt controller.
•
Guest Assigned I/O Devices: For assigned I/O devices, either the VMM uses a software proxy or it can
directly map the physical device to the assigned VM. In both cases, servicing of the interrupt condition on the
physical device is initiated by the driver running inside the guest VM. With host control of external interrupts,
interrupts from assigned physical devices cause VM exits to the VMM and vectoring through the host IDT to the
registered VMM interrupt handler. To unblock delivery of other low priority platform interrupts, the VMM
interrupt handler must mask the interrupt source (for level triggered interrupts) and issue the appropriate EOI
write sequences.
Once the physical interrupt source is masked and the platform EOI generated, the VMM can map the host vector to
its corresponding guest vector to inject the virtual interrupt into the assigned VM. The guest software does EOI
write sequences to its virtual interrupt controller after completing interrupt processing. For level triggered inter-
rupts, these EOI writes to the virtual interrupt controller may be trapped by the VMM which may in turn unmask
the previously masked interrupt source.
33.3.3.4 Generation of Virtual Interrupt Events by VMM
The following provides some of the general steps that need to be taken by VMM designs when generating virtual
interrupts:
1. Check virtual processor interruptibility state. The virtual processor interruptibility state is reflected in the guest
RFLAGS.IF flag and the processor interruptibility-state saved in the guest state area of the controlling-VMCS. If
RFLAGS.IF is set and the interruptibility state indicates readiness to take external interrupts (STI-masking and
MOV-SS/POP-SS-masking bits are clear), the guest virtual processor is ready to take external interrupts. If the
VMM design supports non-active guest sleep states, the VMM needs to make sure the current guest sleep state
allows injection of external interrupt events.
2. If the guest virtual processor state is currently not interruptible, a VMM may utilize the “interrupt-window
exiting” VM-execution to notify the VMM (through a VM exit) when the virtual processor state changes to inter-
ruptible state.
3. Check the virtual interrupt controller state. If the guest VM exposes a virtual local APIC, the current value of its
processor priority register specifies if guest software allows dispensing an external virtual interrupt with a
specific priority to the virtual processor. If the virtual interrupt is routed through the local vector table (LVT)
entry of the local APIC, the mask bits in the corresponding LVT entry specifies if the interrupt is currently
masked. Similarly, the virtual interrupt controller’s current mask (IO-APIC or PIC) and priority settings reflect
guest state to accept specific external interrupts. The VMM needs to check both the virtual processor and
interrupt controller states to verify its guest interruptibility state. If the guest is currently interruptible, the
VMM can inject the virtual interrupt. If the current guest state does not allow injecting a virtual interrupt, the
interrupt needs to be queued by the VMM until it can be delivered.
4. Prioritize the use of VM-entry event injection. A VMM may use VM-entry event injection to deliver various
virtual events (such as external interrupts, exceptions, traps, and so forth). VMM designs may prioritize use of
virtual-interrupt injection between these event types. Since each VM entry allows injection of one event,