A note about nomenclature

Terminology

Please note the following about the terminology used in this guide:

device

We use device or to mean a hardware device that exists as a physical component on the system. Contrast vdev.

guest

A guest is a guest OS and any applications that are running on this OS; a qvm process instance (see below) hosts a guest. The guest runs in a qvm.

If we need to make the distinction between the guest OS and the applications, we spell it out (e.g., “To stop an application without stopping the guest OS ...”).

host

In most cases, the term host refers not to a host computer (the desktop or laptop, which you can connect to your target system to load a new image or debug), but to the hypervisor or something in the hypervisor (e.g., the CPU instructs the guest thread to exit guest mode and continue in host mode).

When the context doesn't make the meaning of host clear, we'll use development host to refer to the laptop or desktop, and host domain or hypervisor host to indicate the hypervisor and all its components.

When discussing privilege or exception levels, we'll use hypervisor host or hypervisor host domain (e.g., processes running in the hypervisor host domain sometimes run at EL2 on ARM boards, or at VMX root mode on x86 boards).

hypervisor

For simplicity, we may use the terms QNX hypervisor or hypervisor to refer to both the QHS and the QNX Hypervisor. If you are using the QHS, see the “QNX Hypervisor for Safety” chapter and the QNX Hypervisor for Safety 2.0 Safety Manual.

qvm

A qvm (or qvm process) is a process in the hypervisor that hosts guests.

The hypervisor starts qvm process instances; each qvm process instance presents a virtual machine (VM) in which a guest can run.

A qvm process runs at times at the permission level of the hypervisor host domain (it is part of the hypervisor), and at times at the lower privilege level of the guest it is hosting.

vdev

We use virtual device (or vdev) to mean any device that the hypervisor virtualizes in some way (see “Devices” in this chapter). Examples of vdevs include an interrupt controller (virtualized), or an Ethernet device controller (para-virtualized).

If we ever refer to a virtual device simply as a device, that is confusing and an error, so let us know about it.

VM

A virtual machine or VM is presented by a qvm process instance to a guest, which runs in the VM; the VM hosts the guest.

File names

We use the following nomenclature to name the files in a QNX virtualized environment:

Prefixes

Prefixes identify where a file is used:

hypervisor

The file includes or is used to build and/or configure the hypervisor host domain. The prefix is followed by a release number.

vdev-

The file is a virtual device.

Infixes

Infixes identify a component variant:

-safety

The hypervisor or supporting component may be used in a system that will require safety certification.

Suffixes

Suffixes identify the type of file:

.build

The file is a buildfile, for the QNX hypervisor host domain, or for a QNX guest.

For Linux and other non-QNX guests, see the documentation for those types of OSs.

.img

The file is a bootable image. This image may include only the hypervisor host domain, only a guest, or the host domain and one or more guests.

.qvmconf

The file is a configuration file for a VM; it is parsed by a qvm process instance to assemble the VM.

Examples

The following illustrates how we compose file names:

Hypervisor build and image files

Names of buildfiles and image files for the hypervisor host domain are composed as follows: hypervisorrelease-board.type, where release is the hypervisor release, board is the hardware platform, and type is the type of file (either build or img). For example: hypervisor2.0-fooboard.build and hypervisor2.0-fooboard.img.

Guest (QNX) build and image files

Names of guest buildfiles and images are composed as follows: guestos.type, where guestos is the guest OS (e.g., qnx70, qnx66, linux44), and type is the type of file (either build or img). If your QNX hypervisor system will have more than one instance of the same OS, add a letter to each instance. For example: qnx7a.build and qnx7b.img.

Linux and other types of guest OS use their own nomenclature.

QHS components

If a hypervisor component or a supporting component has a safety-certified variant and a garden-variety variant, the safety variant includes the -safety infix. For example: smmuman-safety.so and vdev-foo-safety.so.

VM configuration files

Names of configuration files for the qvm process are composed as follows: guest.qvmconf, where guest is the guest OS (e.g., qos21, qnx70, linux44) that will run in the VM configured by this file. If your QNX Hypervisor system will have more than one instance of the same OS, add a letter to each instance; for example: qnx70a.qvmconf and qnx70b.qvmconf.