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).
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.
Design Safe States
The QNX Hypervisor supports two Design Safe States (DSSs).

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.
- 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.
  - Protection strategies
    The QNX Hypervisor implements multiple strategies to protect itself and its guest OSs, and to mitigate the undesired effects of faults.
  - Design Safe States
    The QNX Hypervisor supports two Design Safe States (DSSs).
  - Checking whether an OS is in a virtualized environment
    The hypervisor provides a mechanism for an OS to determine if it is running in a virtualized environment and in particular, a QNX hypervisor environment.
  - DMA device containment
    The hypervisor uses an IOMMU/SMMU Manager to ensure that no pass-through DMA device can access host-physical memory to which it has not been explicitly granted access.
  - Watchdogs
    QNX hypervisors provides virtual watchdog devices that you can use in a VM just as you would a hardware watchdog on a board in a non-hypervisor system.
  - Handling a qvm termination
    You can register to be informed if a qvm process instance terminates, so you can take appropriate action in response to the termination.
- 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.

Design Safe States

The QNX Hypervisor supports two Design Safe States (DSSs).

CAUTION:

When you are running the non-safety QNX Hypervisor variant and not adhering to the safety manual, there is no guarantee that the hypervisor will enter into one of its DSSs following an undefined condition in a VM or the hypervisor itself.

If an internal or external detection mechanism alerts the hypervisor of a condition it is not designed to handle in any other way, the hypervisor should do one of the following:

VM DSS (local DSS): If an undefined condition is confined to a VM, the hypervisor terminates that qvm process instance (e.g., with a SIGSEGV signal). Terminating the hosting qvm process instance terminates its guest.
The hypervisor host continues to run normally after it terminates a qvm process instance. You can design your system to take appropriate action after moving a guest to its local DSS; for example, you can reconstruct the VM and reboot the guest.
Hypervisor host DSS (global DSS): Since the QNX Hypervisor comprises qvm integrated with the QNX OS microkernel, any abnormal conditions that cause the QNX OS microkernel to move to its DSS are viewed as causing the hypervisor to move to its global DSS. That is, if the undefined condition isn't confined to a VM, the hypervisor shuts down.
Warning:
The hypervisor host kernel initiates a shutdown sequence on the CPU where the undefined condition is found. The last thing the kernel's shutdown sequence does is to trigger the kernel reboot callout, which must be provided in the BSP. This callout must ensure that it places the entire system in a safe state. Typically, this means rebooting the system, which will reset all processors and peripherals.

Page updated: March 05, 2025