Configuring the hypervisor host

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

Flag for enabling hypervisor features at startup

The QNX OS microkernel includes built-in support for virtualization and, thus, QNX hypervisor. To enable the hypervisor features, pass the -Q enable flag setting into the startup program. This setting enables the best supported hardware virtualization mode. For AArch64 platforms, you can explicitly specify the exception level (EL) at which the host should run. This is done by modifying the bootstrap portion of the buildfile:

[image=0x40100000]
[uid=0 gid=0]
[virtual=aarch64le,raw] boot = {
   [+keeplinked] startup-iMX8QM -P 1 -Q enable,el2-host -W -vv
   [+keeplinked] 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
}

In the example above, el2-host is included to turn on Virtualization Host Extensions (VHE) support, which means the host runs at EL2 at all times. If you specify el1-host instead, the startup enables virtualization without VHE and runs the host OS at EL1. Note that ARMv8.1 and later CPUs support el2-host and VHE; it would be unusual to specify el1-host for such systems.

On x86 platforms, you simply specify -Q enable; there's no need to request a specific exception level.

The startup program then passes the necessary information onto the microkernel process (procnto) so it can enable its hypervisor host mode and, hence, support the qvm processes that the hypervisor host creates.

For more information about this flag, see the startup-* entry in the QNX OS Utilities Reference.

Host domain code

The buildfile contains instructions to include the necessary binaries and start the processes that will host guests, and other code that will also run in the hypervisor host domain. For example, the following command includes the qvm binary and starts a qvm process instance, which assembles a VM:

qvm

There are different variants of the qvm binary that support different target platforms. For AArch64 targets, it is called simply qvm. For x86-64 hardware, there are two vendor-specific variants: qvm-svm, which is for AMD targets, and qvm-vmx, which is for Intel targets.

For your hypervisor system to function, your buildfile must include the correct binary variant. Information on including a particular binary variant is given in the Building the host section in the Building a QNX Hypervisor System chapter.

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/qnx80.qvmconf = guests/qnx80/qnx80.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 components

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

You should remove all components that aren't required, so 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 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).