Configuring the hypervisor host

Updated: October 28, 2024

The hypervisor host domain is configured through a buildfile, exactly like a QNX OS image.

For details about how to write QNX buildfiles, including buildfile structure, contents, and syntax, see the “OS Image Buildfiles” chapter in the QNX Neutrino Building Embedded Systems guide.

The buildfile for a hypervisor host differs from buildfiles for standard QNX OS images in the following sections:

Virtualization extension module
The virtualization extension module (libmod_qvm.a) is included. For example, a buildfile for the hypervisor host for a supported ARM platform would begin as follows:
[+compress]
[image=0x40100000]
[uid=0 gid=0]
[virtual=aarch64le,raw] boot = {
  [+keeplinked] startup-rcar_h3 -P1 -W -vv
  [+keeplinked module=qvm] PATH=/proc/boot:/sbin:/bin:/usr/bin:/opt/bin/sbin:/usr/sbin
  LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib procnto-smp-instr -ae -v
}

Of particular interest in this example is module=qvm, which brings the virtualization module into the build.

DANGER
You can use the non-safety variant of the kernel module in systems that don't need to be safety-certified. But if you're building a safety-related system, you must load the safety variant of the kernel module by adding [module=qvm-safety] instead of [module=qvm]. In this case, you shouldn't read this guide but instead read the QNX Hypervisor for Safety 2.2 User's Guide and the QNX Hypervisor for Safety 2.2 Safety Manual.
Host domain code
The buildfile contains instructions to include and start the qvm, and other code that will run in the hypervisor host domain. For example, the following command includes and starts a qvm process instance, which assembles a VM:
qvm
VM (qvm) configuration files
The buildfile includes the paths to the configuration files that different qvm process instances use when creating and assembling VMs, and indicates where to place these configuration files in the image. For example:
/vm/config/qnx71.qvmconf = guests/qnx71/qnx71.qvmconf
Virtual device (vdev) shared objects
The virtual device modules (vdev-*.so) are included in the shared objects list. For example:
vdev-8259.so
vdev-ser8250.so
vdev-timer8254.so
vdev-mc146818.so
vdev-virtio-console.so
vdev-virtio-blk.so
vdev-virtio-net.so
vdev-shmem.so
vdev-pckeyboard.so
vdev-ioapic.so
vdev-pci-dummy.so
vdev-hpet.so
vdev-pl011.so
vdev-vgpu-gvtg.so
vdev-progress.so

Unused component removal

The buildfile should include only components required by the hypervisor host.

You should remove all components that aren't required, so that they don't get included in the hypervisor host image. For example, if a device (e.g., USB) is passed through to a guest, the hypervisor host (or another guest) may not also have access to the device, so you should remove the driver from the hypervisor host buildfile (see pass in the “VM Configuration Reference” chapter).

Support for PCI pass-through devices

If your hypervisor system will pass through PCI devices, you must include the pci_server-qvm_support.so module in your hypervisor host. For instructions, see pci-server in the QNX Neutrino Utilities Reference.