Building guests
When you build guests to run in a QNX virtualized environment, you must build them for the appropriate hardware architecture, and configure the VMs in which they will run.
You need to have the build environment and tools that correspond to the guest OSs
you're using (see Supported build environments
).
Validating devices and guests
It may be easier to identify and debug some guest OS and device problems in a non-virtualized environment, before you integrate it into in your hypervisor system. In most environments, guests and devices also need further validation in the hypervisor environment.
For example, run the host OS on your target board and validate that devices work as intended with the host, before trying to configure them as pass-through devices. Checking that pass-through devices work with the host OS can also be helpful in figuring out the pass-through parameters that a given device requires (i.e., by running pidin to find which memory regions and hardware interrupt requests it uses).
In some environments, it could be useful to run the guest OS as the host on your target board, to validate that devices work as intended with it directly, before trying to configure them as pass-through devices. However, if you're building a QNX OS system to use as a guest, the startup driver required for the guest may not work directly on the board; you may have to change the buildfile for the guest to (temporarily) use the appropriate driver for starting it up directly on the board.
Remember that the hardware presented by a qvm system is fundamentally unlike the hardware presented by the host system. (This characteristic is why the startup driver for guests corresponds to the model that qvm presents to the guest, not the board on which the host resides.)
- The guest uses para-virtualized devices, which by definition don't exist as hardware.
- The guest uses vdevs, meaning the configuration for the VM that hosts
the guest must be updated to include these vdevs
(see
Configuring the VMs and the guests to match
below). - Some devices aren't passed through to the guest. In this case, you need different drivers when you run the hypervisor system so the hypervisor host can manage these devices.
Supported guest formats in images
- ELF (including multiboot)
- Linux zImage
Configuring the VMs and the guests to match
If you change anything in your guest about how it accesses hardware (physical or virtual), you need to ensure that the qvm configuration file for the VM that will host the guest is properly configured.
When building any kind of guest to run in a QNX virtualized environment, it is important to remember that the guest must be configured to match the VM in which it will run. This means that it must have the drivers it needs to access devices, whether they are physical or virtual. In the VM, the drivers must be configured to be where the guest expects them to be.
The only difference between QNX guests and non-QNX guests is that QNX guests use BSPs to bring in the architecture-specific and board-specific components, while other OSs may use other mechanisms to achieve the same end.
For more information, see Assembling and configuring VMs
in
the Configuration
chapter.