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.

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.

Understanding QNX Virtual Environments

QNX hypervisors are designed to meet the expectations of a hypervisor specified by the Popek/Goldberg Theorem.

CAUTION:

Read this chapter and understand its contents before you attempt to use the hypervisor. A few minutes spent with this chapter now will save you a great deal of time in the future.

The Popek/Goldberg Theorem

The Popek/Goldberg Theorem specifies that a hypervisor should meet the following three criteria:

Equivalence: Virtual machines (VMs) running in the hypervisor are essentially the same as the underlying hardware. A guest does not need to be aware that it is running in a VM in order to function properly.; The above statement does not preclude the use of para-virtualized devices (see Para-virtualized devices) or other strategies that require virtualization awareness. Such strategies may be used to provide functionality and improve performance.
Safety: With the exception of guest access to pass-through device memory, the hypervisor maintains control of the hardware at all times, regardless of what the guests are doing. It controls guests' abilities to access hardware devices, limits guests' ability to access host-physical memory to their assigned memory regions, has ultimate control over scheduling, manages interrupt routing, and has the ability to terminate a guest, regardless of what the guest may be attempting to do.
Performance: Execution of programs running in VMs is only minimally slower than when running directly on the hardware.

See The Popek/Goldberg Theorem in Edouard Bugnion, Jason Nieh and Dan Tsafrir, Hardware and Software Support for Virtualization (Morgan & Claypool, 2017).

Page updated: March 05, 2025