Using your own board-specific BSP for the host

You can build a hypervisor system for boards that meet the hardware and firmware requirements of a QNX Hypervisor system, but for which QNX doesn't provide reference images.

CAUTION:

Before you begin to work, check that your board's hardware and firmware support virtualization.

Even if your board hardware supports all the virtualization capabilities needed to run a QNX virtualized system, the firmware on the board may not enable or may even expressly disable some of these capabilities, in which case you won't be able to run the hypervisor.

You may wish to contact your board vendor to confirm that the board you are considering supports all the virtualization capabilities you'll need, and that you have the appropriate firmware on the board.

Finally, you must ensure that your board's startup driver supports the hypervisor (“Modifying the startup driver” below).

You can build your hypervisor system independently (i.e., without using the HHBSP). After you have downloaded the QNX Hypervisor product package, all the components (except shmem-host) that you will need to build your host should be on your development host system at $QNX_TARGET, .

Thus, to build a hypervisor system with your own host BSP rather than from inside the HHBSP framework:

Download to your work area on your development host the BSP for your board.
Modify your BSP buildfile to include:
- the libmod_qvm.a kernel module, by adding a [module=qvm] prefix to the buildfile line that includes procnto*. For example, change:
```
LD_LIBRARY_PATH=/usr/lib:/lib:/lib/dll procnto-smp-instr
```
  to:
```
[module=qvm] LD_LIBRARY_PATH=/usr/lib:/lib:/lib/dll procnto-smp-instr
```
  If you are using QOS 2.0, you must include the libmod_qvm-qos_capable.a variant by adding [module=qvm-qos_capable] instead of [module=qvm].
  
  DANGER
  
  QNX Hypervisor 2.0 is not a safety-certified product. Adding libmod_qvm-qos_capable.a to a QOS 2.0 build compromises the QOS 2.0 safety certification.
- the hypervisor files: qvm, qvm-check and the IOMMU/SMMU Manager (smmuman). For example:
```
/sbin/qvm = qvm
/bin/qvm-check = qvm-check
/bin/smmuman = smmuman
```
- the vdev-*.so file for every vdev you want to make available for your guests. For example:
```
vdev-8259.so
vdev-hpet.so
vdev-ioapic.so
...
vdev-virtio-console.so
vdev-virtio-input.so
vdev-virtio-net.so
```
If you will use the shmem-host shared memory sample application for testing, copy it from the HHBSP's prebuilt/ directory to your BSP's prebuilt/ directory.
Include the images for the guests you will run (i.e., IFSs for QNX guests; kernels, initrd files, disks, etc. for Linux), along with the VM configuration files (*.qvmconf) for their hosting VMs.

Refer to the HHBSP to see how all of the above components should be organized in your BSP (see “The HHBSP” in this chapter.
From your BSP's root directory, run make to build the host.

You should now be ready to build the guests (see “Building the guests”, then assemble the host and its guest into an image you can transfer to your target.

Modifying the startup driver

In addition to adding to your BSP's buildfile the components needed to support virtualization, you must ensure that your board's startup driver supports the hypervisor. This driver is usually found under the following directory: src/hardware/startup/boards/your_board.

For x86 architectures, you shouldn't have to make any modifications to your startup driver. For ARM architectures, you need to make sure that your IPL (firmware) enters startup at least at EL2. The kernel is always entered in EL1.

For more information, see Building Embedded Systems in the QNX Neutrino OS documentation, and your board manufacturer's documentation.