About Writing Vdevs

This chapter presents an overview of concepts you need to understand before you start writing virtual devices (vdevs) for a QNX Hypervisor system

Types of vdevs

There are three fundamental types of vdevs:

boot vdev — intervene to change the boot process of a guest; in a QNX Hypervisor system, this intervention would occur when the vdev received the VDEV_CTRL_GUEST_STARTING callback (see “Lifecycle of a vdev”)
instruction trap vdev — emulate a special guest instruction that was trapped by the hardware virtualization extensions
emulating vdevs and para-virtualized devices — the type of vdev discussed in this guide: emulate a physical device, or provide 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 hardware

You can write boot and instruction trap vdevs to use in a QNX Hypervisor system. Emulating vdevs and para-virtualized devices are far more common, and are therefore the focus of this guide. Unless otherwise specified, in this document vdev refers to emulating vdevs and para-virtualized devices.

About QNX virtual environments and vdevs

QNX hypervisors include a small number of implicit vdevs; these are included in the hypervisor code itself and don't need to be explicitly specified in a virtual machine (VM) configuration. It also includes a larger number of optional vdevs that you can include in a VM configuration to make them available to the guest in that VM.

These optional vdevs are shared objects, which you must explicitly include in the configuration for each VM that will need to use them. VMs are created by qvm process instances.

When you write a vdev, you create a shared object, which you'll make available to the hypervisor host, because that is where it will run. This is an important point to remember: a vdev belongs to the hypervisor host domain, not to the guest. The guest uses a vdev in the same way that it uses a hardware device.

The distinction between implicit and explicit vdevs is simply an implementation detail: implicit vdevs are always included in the hypervisor code; explicit vdevs are shared objects that must be specified in a VM's configuration.

A more important difference between vdevs is based on what they do and how they do it:

An emulation vdev emulates, in whole or in part, a physical device. The guest can interact with the vdev just like it does with a physical device. The vdev may emulate everything, (e.g., a timer chip (vdev timer8254)), or it may emulate only some aspects of the physical device. An emulating vdev may also act as an intermediary between the guest and an actual physical device (e.g., vdev ser8250).
A para-virtualized vdev is a vdev that has no hardware equivalent. To use it, a guest must be aware that it is running in a VM; it needs an appropriate driver in the guest, interfaces, etc. Para-virtualized devices can be efficient in a hypervisor system, providing important functionality without the constraint of having to fully emulate a hardware device.

For a more detailed discussion of virtual devices and of devices in general in a QNX Hypervisor system, see “Devices” in the QNX Hypervisor for Safety 2.0 User's Guide.

Public header files

The vdevs described in this guide use functions available in:

the QNX Hypervisor public header files documented in the QNX Hypervisor for Safety 2.0 Virtual Device API Reference
QNX Neutrino virtualization public header files

Device drivers

If you write an emulating vdev your guest should be able to use the driver it would use to work with the corresponding hardware device in an unvirtualized system. If you are writing a para-virtualized device, you may need to write a corresponding driver for your guest OS.

Note: Linux includes modules for the more common types of VirtIO devices, so you may only need to make sure these modules are loaded into your Linux kernel.

Terminology

Hypervisors are relatively new; and some of the terms used to describe hypervisors and their components, and what they do may not always be used to indicate or describe the same thing. For example, the terms “guest” and “VM” are often used interchangeably, when in fact they indicate very different things.

Or, inversely, different writers may use different terms to describe the same thing. For example, ARM calls the memory assembled for a VM “intermediate physical memory”, but Intel calls it “guest physical memory”.

That noted, whatever other people do, we try to be precise and consistent in our use of terminology across all the QNX Hypervisor documentation. For more information about how we use hypervisor and virtualization terminology, please see “A note about nomenclature” and “Terminology” in the QNX Hypervisor for Safety 2.0 Virtual User's Guide.