Virtual devices

Virtual devices (or vdevs) exist only in virtualized environments. To use a vdev, a guest requires a driver, just as it would require a driver to use a physical device in a non-virtualized environment.

A vdev might never access a physical device, or it might act as an intermediary that both responds directly to a guest and passes requests and responses between a guest and a physical device.

In a hypervisor system, the hypervisor provides vdevs in the qvm process instance for a VM. The guest hosted in the VM receives interrupts from each vdev and sends signals to it, exactly as though it were working with a physical hardware device. The guest has no direct communication with any physical device on the system; such a device might not even be present.

The guest requires a device driver for each vdev it will use.

The hypervisor supports the following types of vdev:

• Emulation vdevs
• Para-virtualized devices

For information about how to write your own vdevs, see the Virtual Device Developer's Guide in the QNX Hypervisor GitLab Repository at https://gitlab.com/qnx/hypervisor.

Emulation vdevs

An emulation vdev is a virtual device that emulates an actual physical device for a guest. The following are key characteristics of emulation vdevs in a QNX virtualized environment:

• To use the vdev, a guest doesn't need to know that it is running in a virtualized environment. It interacts with these devices exactly as it would with physical devices, and it has no indication that it is working with a virtual device or that no hardware device might be involved.
• The vdev emulates a physical device. In fact, some vdevs (such as an x86 pckeyboard) exist simply because a guest running on an x86 platform expects them to be there.
• The emulated physical device may or may not exist on the system.
• Depending on the type of physical device, the emulation vdev may either handle everything itself (e.g., emulate a timer chip, as does vdev timer8254), or it may act as an intermediary between the guest and an actual physical device (e.g., vdev ser8250).
• The guest can use the same device driver for the vdev as it would use for the emulated physical device if it were running in a non-virtualized environment.

Para-virtualized devices

Para-virtualized devices are a type of virtual device implemented as software code that runs in the hypervisor layer, but this code doesn't emulate any specific hardware device.

Instead, a para-virtualized device provides the functionality that might be provided by a physical device (or several physical devices) in a non-virtualized environment, but without the constraints of emulating a piece of hardware.

A typical para-virtualized device requires code running in the guest (front-end), and code running outside the guest (back-end); for example, a filesystem device driver running in the guest that connects to a block device driver running in the hypervisor host.

Key characteristics of para-virtualized devices include:

• To use a para-virtualized device, the guest must know that it is running in a virtualized environment. For example, to use virtio-net, the guest must know that it is running in a virtualized environment, if only because virtio-net has no corresponding physical device (it exists only as a para-virtualized device).
• There exists no physical device that corresponds exactly to the para-virtualized device.
• The guest must have appropriate drivers and interfaces to work with the para-virtualized devices.

Para-virtualized devices require some initial investment (e.g., to write drivers for guests), but these devices may often be more efficient than vdevs that must emulate a hardware component. For example, emulating a serial port interface that provides a console terminal can result in many guest exits and returns. A virtio-console vdev (a para-virtualized serial port interface) provides the same functionality, but with less overhead in the guest.