Using non-QNX (Linux, Android) guests

The QNX Hypervisor supports Linux guests, provided these guests are built for virtual hardware 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.

Note: Just like QNX guests, Linux guests must be built for the architecture and board on which they will run.

When you build non-QNX 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 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.

See “Configuration file for VM hosting a Linux guest (example)” below for an example of a configuration file for a VM hosting a Linux guest.
When you have built your Linux guest, you may include it in a new hypervisor disk image, which you can transfer to your target.

Copy the Linux kernel file (vmlinuz*) and RAM disk file (e.g., initrd, initramfs) in your Linux work directory into the HHBSP's architecture-specific directory for Linux guests: either aarch64 or x86_64 in images/guest_bsps/linux/. This is where the hypervisor system build will look for them.
Assuming that:
- you are working in the HHBSP framework
- your environment is properly set up for QNX SDP 7.0 builds in your HHBSP's root directory
- the Linux kernel file and ram disk file are ih the appropriate directories (see previous step)
in the HHBSP's root directory, run make to rebuild the hypervisor bootable disk image with the new Linux guest image.

Adding drivers, applications and utilities

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

To make use of the VirtIO hardware passed through the hypervisor to the Linux guest, the Linux kernel must be configured to include the VirtIO drivers (e.g., block, network). For more information, see your Linux documentation.
If you want to use the shared memory demo application in your Linux client, you will need to include the application when you build your Linux kernel. The source code for the application can be found in the HHBSP's src/apps/hypervisor/demos/shmem-linux/ directory. If you are using the defaults for the hypervisor host, the host-side component of the application is already included in the host build configuration.
If you will 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 “Using Your Hypervisor System” chapter).

Passing command-line arguments to Linux

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” in the “Getting Started” chapter).

When you start your Linux guest, however, you will probably need to pass up to the guest some commandline arguments. To do this, you can you can use the qvm cmdline configuration option to pass startup arguments to the Linux kernel (see cmdline in the “Configuration” 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 pass the information on 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.

See “Passing command-line arguments to Linux” 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 will need to know its device entry (probably /dev/hda*) to pass it along 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
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
vdev virtio-blk
        hostdev /dev/hd1t131
vdev pckeyboard
vdev 8259
	loc 0x20
vdev 8259
	loc 0xa0
vdev hpet
        loc 0xf8008000
        intrmap myioapic:0,myioapic:8,myioapic:10

#passthrough graphics
pass loc pci:0:2.0=pci:0:2.0

#passthrough usb
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 host system (e.g., in the HHBSP's images/guest_bsps/android/ directory)
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 are using, and that your hosting VM must be configured to match the guest's expectations.