A QNX hypervisor comprises the hypervisor microkernel, virualization extensions, and one or more instances of the qvm process.
Two representations of a QNX hypervisor system
The figure below presents a high-level view of the QNX hypervisor architecture and some of the configurations available for accessing both virtual and physical devices. Not all possible guest-device configurations are shown; those shown are only to illustrate some of the possible configurations.
Figure 1. An overview of the hypervisor, showing VMs and some of the ways guests can
access virtual and physical devices.The diagram above presents a static view of a hypervisor system. Unfortunately, it is necessarily misleading, in that it can be interpreted as suggesting that guests actually run in VMs or on the host system; to make matters worse, when describing a hypervisor system, we often say that a guest is running in a VM.
In fact, a guest doesn't actually run in a VM. The hypervisor isn't an intermediary that translates the guest's instructions for the CPU. The VM defines virtual hardware (see “Virtual devices”) and presents it and pass-through hardware (see “Pass-through devices”) to the guest, which doesn't need to know it is running “in” a VM rather than in an environment defined directly by the hardware.
That is, when a guest is running its instructions execute on a physical CPU, just as if the guest were running without a hypervisor. Only when the guest attempts to execute an instruction that it is not permitted to execute or when it accesses guest memory that the hypervisor is monitoring does the virtualization hardware trap the attempt and force the guest to exit.
On the trap, the hardware notifies the hypervisor, which saves the guest's context (guest exit) and completes the task the guest had begun but was unable to complete for itself. On completion of the task, the hypervisor restores the guest's context and hands execution back to the guest (guest entrance).
The Lahav Line below presents a more dynamic view of the interaction between the hypervisor and one of its guests. For simplicity, it assumes an execution path on a single CPU.
Figure 2. A Lahav Line showing how execution in a QNX hypervisor system alternates
between the hypervisor and its guests. On a trap, the hypervisor manages the
guest exit, saving the guest's context, then restoring it before the guest
entrance.For information about what the hypervisor does to mitigate time drift in the guest (caused by the need to have the guest exit), see “Time” in this chapter.