A virtual device can emulate a physical device, or it can provide functionality like that provided by a physical device without emulating any specific physical device.
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, just as it would require a device driver if it were running in a non-virtualized environment and accessing a physical device.
The hypervisor supports the following types of vdev:
For information about how to write your own vdevs, see the QHS 2.0 Virtual Device Developer's Guide.
An emulation vdev (or simply 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:
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 file system 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:
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.