Virtual devices

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

A vdev may never access a physical device, or it may 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, vdevs are provided by the hypervisor in the qvm process for the VM that hosts the guest. The guest hosted in the VM receives interrupts from the 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. They are 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.