Architecture

Overview

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.

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 virtual machines 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 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 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.

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”.

Supported architectures and hardware

The QNX Hypervisor supports the following architectures and hardware:

ARM

ARMv8 with Aarch64 hardware.

x86

x86 with x86-64 hardware.

CPU privilege levels

A CPU privilege level controls the access of the program currently running on a processor to resources such as memory regions, I/O ports, and special instructions. A guest runs at a lower privilege than the hypervisor microkernel, and applications running in that guest run at an even lower privilege. This architecture provides hardware-level safety from untrusted software components.

Design Safe State

The hypervisor supports two Design Safe States (DSSs). If an internal or external detection mechanism alerts it of a condition it is not designed to handle in any other way, the hypervisor will do one of the following:

VM DSS

If an undefined condition is confined to a VM (a qvm process instance hosting a guest), the hypervisor terminates that qvm process instance, (e.g., with a SIGSEGV signal). Terminating the hosting qvm process instance terminates its guest.

Hypervisor host DSS

The hypervisor is composed of the QNX Neutrino OS plus a virtualization extension; the same conditions that cause the OS to move to its DSS cause the hypervisor host to move to its DSS.

That is, if the undefined condition isn't confined to a VM, the hypervisor shuts down. This DSS is the same as the QOS 2.0 DSS.