Terminology

The following terms are used throughout the QNX hypervisor documentation.

Blob

The guest as seen by the hypervisor host. The term blob is used to emphasize that fact that the hypervisor can't know any more about its guests than a board can know about the OS running on its hardware.

CPU privilege level

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 (see CPU privilege levels in the Understanding QNX Virtual Environments chapter).

DMA

Direct Memory Access

Exception level (EL)

ARM-defined levels of permissions at which processes can run, with EL0 having the least privileges, and EL3 having the most (used for security).

Emulation

Emulation refers to the capability to mimic a particular type of hardware for an operating system regardless of the underlying host operating system. In a QNX environment, emulation refers to emulated hardware devices that a guest will see as real hardware.

In a virtualized environment, a hypervisor includes virtual devices (vdevs) that emulate physical devices. From the perspective of a guest, these vdevs look like the physical devices they emulate. The guest needs drivers to manage them, and receives interrupts and sends signals to the vdevs, just as it would to a physical device in non-virtualized system.

For example, the hypervisor host domain typically emulates an interrupt controller for each guest. An emulated driver may communicate with the underlying hardware, but the guest doesn't need to know if this is the case. In fact, the physical device being emulated doesn't even have to exist on the hardware (see Virtual devices in the Understanding QNX Virtual Environments chapter).

EOI

End of Interrupt

Execute, Execution

The act of completing an instruction on a physical CPU. Contrast with Run below. In a QNX hypervisor system, the hypervisor host runs directly on the hardware, while a guest OS runs in a virtual machine (VM) which has virtual CPUs (vCPUs). Ultimately, however, both the hypervisor and the guest execute on the physical CPUs (see also Lahav Line below).

FIQ

Fast interrupt request: a feature of some ARM boards, FIQs are higher-priority interrupt requests, prioritized by disabling IRQ and other FIQ handlers during request servicing; no other interrupts are processed until processing of the active FIQ interrupt is complete.

Guest

A guest is an OS running in a QNX hypervisor qvm process; this process presents the virtual machine (VM) in which the guest runs (see A note about nomenclature in the Understanding QNX Virtual Environments chapter).

Guest-physical address

A memory address in guest-physical memory (see Guest-physical memory below).

Guest-physical memory

The memory assembled for a VM by the qvm process that creates and configures the VM. ARM calls this assembled memory intermediate physical memory; Intel calls it guest physical memory. For simplicity, regardless of the platform, we will use the term Bugnion, Nieh and Tsafrir use in Hardware and Software Support for Virtualization (Morgan & Claypool, 2017): guest-physical memory, and the corresponding term: guest-physical address.

Host

Either the development host (the desktop or laptop, which you can connect to your target system to load a new image or debug), or the hypervisor host domain. Unless otherwise specified (as in the instructions for building a hypervisor system or transferring it to a target), in the hypervisor documentation host refers to the hypervisor host domain (see below).

Host-physical address

A memory address in host-physical memory (see Host-physical memory below).

Host-physical memory

The physical memory; this is the memory seen by the hypervisor host, or any other entity running in a non-virtualized environment (see Guest-physical memory above).

Hypervisor

In the QNX context, a software system consisting of a QNX OS microkernel with its hypervisor host mode enabled and one or more virtual machines.

Hypervisor host domain

The hypervisor and all its components. The hypervisor host domain (or simply hypervisor host or host domain) is the lowest layer of the software stack that boots first after a board power-up or reset, and must be running before any guests can be launched.

The hypervisor host domain includes the qvm processes that present VMs in which guests run and can also include drivers that support para-virtualization, and components that monitor VMs and perform other system monitoring and maintenance tasks.

IOMMU

Input/Output Memory Management Unit. A memory management unit (MMU) that connects a DMA–capable I/O bus to the main memory. Like a traditional MMU, which translates CPU-visible intermediate addresses to physical addresses, an IOMMU maps device-visible intermediate addresses (also called device addresses or I/O addresses in this context) to physical addresses. This mapping ensures that DMA devices cannot interact with memory outside their bounded areas.

Intel Virtualization Technology for Directed I/O (VT-d) is an Intel IOMMU implementation. Both x86 (VT-d) and ARMv8 (SMMU) provide hardware support for IOMMU. In a QNX environment, IOMMU is enabled when using pass-through mode in a guest (see your hardware documentation).

IPI

Interprocessor interrupts. Used by the hypervisor to communicate between its own cores, or to interrupt VMs.

Lahav Line

A line that describes how a hypervisor host runs directly on the hardware, while a guest runs in hypervisor virtual machine with virtual CPUs, but both execute on physical CPUs (see Two representations of a QNX hypervisor system).

NUC

Next Unit of Computing, an Intel embedded platform.

Para-virtualization

A virtualized environment in which a guest knows that it is a guest, and acts accordingly; for example, the guest uses a para-virtualized device (for which no hardware equivalent exists) instead of an emulation vdev (which emulates a hardware device).

Pass-through

Pass-through is a technique for giving a guest direct access to hardware. Pass-through allows a device driver located in a guest to control a hardware interface directly (see Pass-through devicesin the Understanding QNX Virtual Environments chapter).

pCPU

Physical CPU. Each pCPU corresponds to one hardware core. For example, a quad-core SoC will have four pCPUs (compare with vCPU).

PIC

Programmable Interrupt Controller

PPI

Per-processor interrupt

PSCI

Power State Coordination Interface: an ARM API used to coordinate power control among supervisory systems running concurrently on an ARM board.

QNX guest

A guest system running a supported QNX OS variant.

QNX Hypervisor (QH)

A non-safety hypervisor product from QNX. When built into an image and deployed to a target board, a QH system consists of a running instance of the QNX OS that has hypervisor host mode enabled.

QNX Hypervisor for Safety (QHS)

A safety-certified variant of a QNX hypervisor. When running on a target board, a QHS system consists of a running instance of the QNX OS for Safety that has hypervisor host mode enabled.

QNX OS

A non-safety variant of the operating system from QNX.

QNX OS for Safety (QOS)

A safety-certified variant of the QNX OS.

QNX Software Development Platform (SDP)

Our cross-compiling and debugging toolset for building binary images and programs for ARM and x86_64 targets running the QNX OS.

QNX virtual machine (qvm)

A process in the hypervisor that hosts a guest by presenting a virtual machine (VM) in which a guest can run.

Ring

x86 levels of permissions at which processes can run, with Ring3 having the least privileges, and Ring0 having the most.

Run

In a QNX hypervisor system, the hypervisor host runs directly on the hardware, while a guest OS runs in a virtual machine (VM) which has virtual CPUs (vCPUs). Ultimately, however, both the hypervisor and the guest execute on the physical CPUs (see also Lahav Line above).

SMP

Symmetrical Multiprocessing.

vCPU

Virtual CPU: a hypervisor qvm process thread that emulates a pCPU (see pCPU above). The guest hosted in the qvm process sees the vCPU as a pCPU. As the hypervisor schedules VMs to run, it can attach vCPUs to a pCPU or detach them from a pCPU. You can configure your vCPUs to float between pCPUs, leaving the decision of where the vCPU should run to the hypervisor, or you can restrict vCPUs to individual pCPUs.

vdev

Virtual device (see Devices).

VIRTIO

A standard for virtual devices that by design ... look like physical devices to the guest within the virtual machine (see the OASIS specification: Virtual I/O Device (VIRTIO) Version 1.0). A guest's VIRTIO device driver is aware that it is running in a virtual environment, and cooperates with the hypervisor to allow the sharing of an interface.

The hypervisor and the guest must both be configured for VIRTIO support. Typical use cases for VIRTIO devices involve sharing (between guests) of Ethernet, of block devices (storage), of memory, and of consoles. A VIRTIO driver in the host domain can also be shared between the host domain and the guest, if required.

The QNX virtualized environment supports versions 0.95 and 1.0 of VIRTIO.

Virtualized system

A software system that includes a QNX hypervisor hosting one or more guests.

VM

Virtual machine. In a QNX hypervisor virtualized environment, the hypervisor creates a qvm process instance for each guest it hosts. Each qvm process presents a VM to its guest.