Home
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
Understanding QNX Virtual Environments
QNX hypervisors are designed to meet the expectations of a hypervisor specified by the Popek/Goldberg Theorem.
Supported architectures and guest OSs

QNX Momentics IDE User's Guide
This User's Guide describes version 8.0 of the Integrated Development Environment (IDE) that's part of the QNX Tool Suite.
QNX Software Development Platform
QNX SDP is a cross-compiling and debugging environment, including an IDE and command-line tools, for building binary images and programs for target boards running the QNX OS 8.0.
QNX Software in the Cloud
QNX Software in the Cloud enables developers to use the QNX OS in the Amazon cloud environment.
QNX Toolkit for Visual Studio Code
This User's Guide describes the QNX^® Toolkit for Visual Studio Code. The guide introduces you to the QNX Toolkit by explaining the QNX development environment and how to build, run, and debug your QNX^® Operating System (OS) applications and systems.
QNX Hypervisor User's Guide
This User's Guide explains the QNX hypervisor architecture and provides instructions for installing and running a QNX Hypervisor system, changing system components and configuration, and using hypervisor features such as virtual devices (vdevs).
- Understanding QNX Virtual Environments
  QNX hypervisors are designed to meet the expectations of a hypervisor specified by the Popek/Goldberg Theorem.
  - A note about nomenclature
    Before starting to work with the QNX Hypervisor (QH) (the hypervisor), it is useful to understand the terminology we use to describe QNX virtual environments, the hypervisor, and its guests, as well as the nomenclature we use for filenames.
  - Supported architectures and guest OSs
  - Architecture
    A QNX hypervisor comprises the QNX OS microkernel, which contains built-in support for virtualization, and one or more instances of the qvm process.
  - Virtual machines
    A running hypervisor comprises a QNX OS microkernel and one or more instances of the QNX virtual machine process (qvm).
  - Memory
    In a QNX virtualized environment, the guest-physical memory that a guest sees as contiguous physical memory may in fact be discontiguous host-physical memory assembled by the virtualization.
  - Devices
    A QNX hypervisor provides guests with access to physical devices, including pass-through and shared devices, and virtual devices, including emulation and para-virtualized devices.
  - Scheduling
    It is important to understand how scheduling affects system behavior in a QNX virtualized environment.
  - Interrupts
    In a QNX hypervisor system, guests configure their virtual Progammable Interrupt Controllers (PICs), and the hypervisor manages interrupts in accordance with these configurations.
  - Time
    The flow of time in a QNX hypervisor system is more complicated than in a non-virtualized system, and is critical to many functions of the host OS and guest OS. The different pieces of time-related hardware in a hypervisor system interact in complex ways, and emulating them needs to go beyond the functionalities of each separate piece.
  - Sharing resources
    In a hypervisor system, with the exception of small areas of shared memory, memory and devices are exclusively owned by a single entity (guest or hypervisor host).
- QNX Hypervisor: Protection Features
  This chapter explains the main features used by the QNX Hypervisor to protect itself and its guests. Many of these features are part of the design, while others are configurable.
- Configuration
  A QNX hypervisor, its qvm processes that create the VMs in which guests run, and these guests must be configured to work together.
- Building a QNX Hypervisor System
  This chapter explains how to build (assemble) a QNX Hypervisor system and transfer a bootable image to a supported target platform.
- Booting and Shutting Down
  This chapter describes how to boot and shut down a QNX hypervisor system.
- Using Virtual Devices, Networking, and Memory Sharing
  This chapter describes how guests can discover and connect to vdevs and how they can use important hypervisor capabilities, such as networking and memory sharing.
- Monitoring and Troubleshooting
  This chapter describes some tools and techniques you can use to monitor and troubleshoot your hypervisor system.
- Performance Tuning
  This chapter describes common sources of overhead in a QNX hypervisor system, and strategies for reducing this overhead and optimizing system performance.
- VM Configuration Reference
  When you specify options to configure a qvm process, you are assembling and configuring the components of a virtual machine (VM) in which a guest will run.
- Virtual Device Reference
  This chapter presents the virtual devices (vdevs) delivered with QNX hypervisors, and describes how to configure these vdevs.
- Utilities and Drivers Reference
  This chapter describes the utilities and drivers delivered with the QNX hypervisor.
- Terminology
  The following terms are used throughout the QNX hypervisor documentation.
Typographical Conventions, Support, and Licensing
This section describes the typographical conventions used throughout the documentation, explains how to obtain technical support, and provides some information about licensing.

Supported architectures and guest OSs

Supported hardware architectures

This release of the hypervisor uses a 64-bit kernel and supports the following 64-bit architectures:

AArch64 on ARMv8 hardware
x86-64 on x86 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 QNX OS microkernel, and applications running in that guest run at an even lower privilege. This architecture provides hardware-level safety from untrusted software components.

See also Exception Level (EL) and Ring in the Terminology appendix.

PCI support

The QNX PCI vendor ID is 7173 (0x1C05). For more information about PCI Vendor IDs, see the PCI SIG website at https://pcisig.com/. For more information about the QNX PCI Vendor ID, please contact your QNX representative.

Supported guest OSs

This hypervisor release supports QNX OS and Linux guests for the hardware architectures specified above. The supported guests include:

QNX OS 8.0
Linux Ubuntu 20.04

Other guest OSs (e.g., Android, older QNX guests) are possible. For information about supporting these guests, contact QNX Engineering Services.

Guest OSs must be compiled for the hardware architecture on which the hypervisor host is running. For example, AArch64 guests can run on ARMv8 hardware only.

For both ARM and x86 platforms, the hypervisor host domain requires 64-bit hardware and supports 64-bit guests. Guests may run as single-core or multi-core; that is, a guest may run in a VM configured with a single virtual CPU (vCPU), or in a VM configured with multiple vCPUs.

Note:

32-bit guests are no longer supported. The QNX Hypervisor supports 64-bit guest OS environments such as Linux that can run 32-bit applications, but only on ARM targets.

The number of vCPUs in a VM affects performance. Adding vCPUs adds vCPU threads to the qvm process instance for the VM hosting the guest. Although independent of the number of hardware CPU cores, the number of vCPUs chosen by the system designer is often related to this number of physical cores. Increasing the number of vCPUs can improve performance, but there are circumstances where additional vCPUs may reduce performance. This is explained further in the vCPUs and hypervisor performance section.

Page updated: March 05, 2025