Building Linux and Android guests

QNX hypervisors support Linux and Android guests, provided these guests are built for virtual hardware that the hypervisor can present to the guest in a VM.

Building Linux guests

The information below is only an outline of what you need to do to implement a Linux guest in a QNX hypervisor system. Refer to your Linux documentation for information about how to configure and build your Linux system.

When you build non-QNX guests to run in a QNX virtualized environment, you must build them for the right hardware architecture, and configure the VMs in which they'll run to match their expectations.

To implement a Linux OS as a guest, you need to do the following:

Get from your favorite Linux source a Linux build environment appropriate for building your Linux OS, and configure it.
Follow your Linux instructions to build the guest in your Linux work directory.
Write a VM configuration file (e.g., linuxvm1.qvmconf) that assembles in a VM the components your Linux OS will expect to find on the platform where it will run.

For a sample file, see Configuration file for VM hosting a Linux guest (example) below.
When you have built your Linux guest, you may include it in a new hypervisor disk image, which you can transfer to your target.

Adding drivers, applications, and utilities to a Linux guest

To be useful in a virtualized environment, your Linux guest will probably need to include some additional drivers, applications, and utilities. For example:

To use the VIRTIO hardware the hypervisor makes available to it, the Linux guest kernel must be configured to include the VIRTIO drivers (e.g., block, network). For more information, see your Linux documentation.
To use the shared memory demo application in your Linux guest, you need to take the relevant source code from the board-specific BSP for your target platform and copy it into your work area used for building the Linux kernel. In QNX-provided BSPs that support QNX Hypervisor, this source code is found at src/apps/hypervisor/demos/shmem-linux/.
If you'll use a virtual hardware watchdog, you must include in the Linux kernel a driver for the watchdog device: SP805 (ARM) or IB700 (x86), and include and configure the corresponding watchdog vdev in the VM that will host your Linux guest (see Watchdogs in the QNX Hypervisor: Protection Features chapter).

Making command-line arguments available to a Linux guest

You start Linux guests the same way you start QNX guests: start the VM, either through the command line, or by adding to the hypervisor host startup routine the instructions for starting the hosting qvm process instance (see Starting and using guests).

When you start your Linux guest, however, you'll probably need to provide it with some command-line arguments. To do this, you can use the qvm cmdline configuration option to hand the startup arguments to the Linux kernel (see cmdline in the VM Configuration Reference chapter).

For example, we might use the following to tell the Linux kernel where to find the console:

On ARM platforms:
```
cmdline
    console=ttyAMA0 earlycon=pl011,0x1c090000
```
points the Linux kernel to a virtual PL011 UART device located at 0x1c090000 in guest-physical memory. Don't forget to include this device in your VM configuration.
On x86 platforms:
```
cmdline
    pmtmr=0 nolapic_timer tasks=standard pkgsel/language-pack-patterns=
    pkgsel/install-language-support=false console=ttyS0,115200n8 reboot=t
```
points to a virtual 8250 UART (ttyS0 is Linux's device name for an 8250 UART device). Don't forget to include this device in your VM configuration.

Booting Linux guests

To boot from disk, a Linux guest needs to know in which partition the root filesystem is installed (i.e., the filesystem that gets mounted at location /). When you have this information, you can specify it with a command-line argument in the VM configuration file. For example:

cmdline
    root=/dev/vda1

where vda1 refers to the first virtio-blk vdev entry in the configuration for the VM (for more information, see Making command-line arguments available to a Linux guest above).

If you use a virtio-blk device for your disk, remember that in Linux these devices present as /dev/vda*, /dev/vdb*, etc. If your device is a pass-through device, you'll need to know its device entry (probably /dev/hda*) and make it known to the Linux guest so it can boot.

Configuration file for VM hosting a Linux guest (example)

Below is an example of a *.qvmconf file for a Linux guest. Note the use of the reserve and rom options for the regions where OSs designed to run on x86 platforms expect to find a VGA device and the BIOS.

# A minimalist VM configuration for a Linux guest on an x86 system
ram 0,0xa0000
reserve loc 0xa0000,0x20000
rom 0xc0000,0x40000
ram 1m,1023
cpu
cpu
load ./linux
initrd load ./initrd.gz
cmdline "pmtmr=0 nolapic_timer tasks=standard pkgsel/language-pack-patterns=
    pkgsel/install-language-support=false console=ttyS0,115200n8 reboot=t
    root=/dev/vda1"
vdev ioapic
        loc 0xf8000000
        intr apic
        name myioapic
# this vdev entry corresponds to the console
# location specified in the above command line
vdev ser8250
        intr myioapic:4
vdev timer8254
        intr myioapic:0
vdev mc146818
        reg 0x0b,0x02
vdev shmem
vdev virtio-net
        peer /dev/vdevpeers/vp0
        peerfeats 0x00007fc3
        loc pci:0:1
        name guest_to_host
# this first virtio-blk vdev entry corresponds to the root
# filesystem partition specified above as /dev/vda1
vdev virtio-blk
        hostdev /dev/hd1t131
vdev pckeyboard
vdev 8259
        loc 0x20
vdev 8259
        loc 0xa0
vdev hpet
        loc 0xf8008000
        intr myioapic:0,myioapic:8,myioapic:10
pass loc pci:0:2.0=pci:0:2.0
pass loc pci:0x8086/0x5aa8
vdev pci-dummy clone pci:0:31.0

Building and including Android guests

To build an Android guest, you need:

an Android build environment on your development host
an Android kernel

Follow the outline instructions for building a Linux guest, adapted for your Android OS.

Note:

Remember that your Android guest must be built for the architecture and board you're using, and that your hosting VM must be configured to match the guest's expectations.

Page updated: March 05, 2025