In a QNX hypervisor system, guests configure their virtual PICs, and the hypervisor manages interrupts in accordance with these configurations.
The hypervisor host must intervene to manage any interrupts asserted by the hardware, regardless of whose action triggered the interrupt or who owns the device asserting the interrupt, or of the interrupt's ultimate destination. This means that a guest exit is required so that the hypervisor can look after identifying the interrupt's destination, do any required processing, and pass the interrupt along to its destination.
For information about how to reduce the overhead required to handle interrupts in a hypervisor system, see the “Performance Tuning” chapter.
Interrupts destined only for the hypervisor host include interrupts from devices owned by the hypervisor, and IPIs between physical CPUs. These interrupts are handled by the hypervisor microkernel interrupt handling mechanisms, just like interrupts in a non-virtualized QOS or QNX Neutrino OS (see “Interrupts” in Getting Started with QNX Neutrino). There is nothing you need to do with these interrupts that is specific to a hypervisor system.
Handling of interrupts destined for guests is shared between the QOS or QNX Neutrino microkernel (procnto-safety, procnto) and the VMs (qvm process instances) hosting the guests.
The microkernel looks after the following:
The relevant qvm process instance looks after the following:
Note that the qvm process doesn't unmask interrupts until the guest has looked after them. This design ensures that if a guest makes an error when handling an interrupt the error can't affect the hypervisor itself or other guests. In short, the hypervisor is protected from an interrupt storm caused by a guest error.
Note also, however, that the hypervisor can't protect a guest from itself. If a guest doesn't clear an interrupt condition properly, or if the interrupt rate is too high, the guest will spend its time in its own interrupt handling code and will not be able to run user threads on the vCPU. This behavior is exactly the behavior that would occur if the guest were running in an unvirtualized environment.
Guest OSs configure their own interrupt priorities and destinations, just as they would if they were running in an unvirtualized environment. The hypervisor presents a virtual GIC (ARM) or APIC (x86) in the VM hosting the guest (see vdev gic and vdev ioapic in the “Virtual Device Reference” chapter).
To the guest these virtual interrupt controllers are indistinguishable from hardware GICs or APICs. The hypervisor delivers interrupts to the vCPUs according to the priorities and to the destinations configured by the guest. For example, a QNX Neutrino OS guest expects interrupts to go to physical CPU 0, so the hypervisor delivers the interrupt to vCPU 0 in the VM hosting the guest.
The qvm process instance hosting a guest masks interrupts destined for that guest until the guest has successfully started, and started the appropriate device drivers. Similarly, when a guest begins its shutdown procedure, the hosting qvm process instance masks interrupts intended for that guest.