Superfluous interrupts can significantly compromise guest and system performance.
In a hypervisor system, the guest configures the interrupt controller hardware, but it is the hypervisor that manages the hardware to fulfill the needs of the guest. Thus, when a hardware device asserts an interrupt for a guest, the hypervisor must always intervene; this means that on an interrupt the guest must exit at least once to allow the hypervisor to examine the interrupt and decide what to do with it.
Even if the device that asserts an interrupt is configured as a pass-through device (see “Pass-through devices” in the “Understanding QNX Virtual Environments” chapter), it is the hypervisor that manages the interrupt controller hardware. The hypervisor must mask the interrupt, pass it up to the guest by updating the vCPU thread with the interrupt information, and, finally, on the physical EOI unmask the interrupt.
The hypervisor's intervention in the interrupt delivery to the guest, even for pass-through devices, prevents interrupt storms from compromising the system behavior, and allows for a proper cleanup of pending interrupts in the case of a guest failure.
Since interrupts trigger guest exits, eliminating actions that trigger superfluous interrupts is one of the most effective ways to improve guest and overall system performance. However, since interrupts are essential to any functioning system, they can't be eliminated. What you can do, though, is design and configure your system to handle interrupts efficiently.
If the hardware provides no special support for interrupts in a virtualized system, the hypervisor host looks after everything. It traps the interrupt and updates the appropriate vCPU thread structure with the interrupt information. This software-only method is available on all hardware and is the default method if no other methods are offered by the hardware. It requires at least one guest exit and incurs the greatest overhead.
Many ARM and x86 platforms provide virtualization support that reduces the work required to deliver an interrupt to a guest in a virtualized system. When planning your system, consider the performance benefits of these hardware features.
To take advantage of hardware assistance with interrupts you need:
On supported ARM platforms, the hypervisor provides two techniques for reducing the guest exits required to handle interrupts.
If the hardware allows, the hypervisor can set the guest's IRQ requested bit even if interrupts are disabled in the guest. Setting this bit doesn't cause a guest exit.
See your ARM hardware documentation for more information about implementing this hardware feature.
Many ARM platforms with GICv2 and more recent GIC hardware optionally provide hardware assist capabilities for interrupt handling.
GIC hardware assist doesn't eliminate guest exits on physical interrupts, but it does help with the guest manipulations of the virtual GIC state in response to guest interrupt delivery (pass-through or from a vdev).
On supported x86 platforms, hardware assistance for handling interrupts in a virtualized system currently includes LAPIC hardware assist and posted interrupts.
LAPIC hardware assist helps reduce the number of guest exit-guest entry cycles required to handle an interrupt.
Systems that use LAPIC include data structures with information about the LAPIC. To reduce the number of guest exits required to handle an interrupt delivery to a guest your device driver can turn on the bit associated with the hardware-assisted LAPIC, then signal the guest to run.
This method can only be used if the hardware supports posted interrupts (see below), or if the guest's vCPU is already stopped (i.e., the vCPU that has been scheduled to receive the interrupt is already in the stop state). If the hardware doesn't support posted interrupts and the vCPU isn't already in a stopped state, the vCPU must be stopped, which requires a guest exit and re-entry.
This method affects only the vCPU targeted by the interrupt. The VM's other vCPUs can continue to run.
If the hardware supports posted interrupts, this capacity can be used to eliminate the need for a guest to exit to receive an interrupt.
As always, the hypervisor must examine the interrupt to determine its destination, which requires a guest exit-entrance cycle. With posted interrupt support, however, when it has determined what to do with an interrupt, the hypervisor doesn't need to force the guest to exit so that the guest will notice an interrupt waiting in its virtual LAPIC:
For example, a guest with a single vCPU is performing some task such as calculating the value of pi. A hardware device asserts an interrupt for the guest. The hardware forces the guest to exit so the hypervisor can examine the interrupt. The guest re-enters and continues running to calculate pi.
Remember that the hypervisor qvm process instance for the VM hosting the guest has at least two threads: the thread for the vCPU and the qvm main thread. With posted interrupt support, the above could be achieved as follows: the main thread instructs the virtualization support hardware to post the interrupt to the guest; the hardware updates the guest's virtual LAPIC, delivering the interrupt to the guest without forcing another guest exit.