Para-virtualized devices

Earlier versions of the VIRTIO specification are also supported; where relevant, VIRTIO vdevs included with QNX hypervisors have a legacy option that allows you to specify that you want the vdev to present a legacy interface (see for example, vdev virtio-console in the User's Guide, and the source code on GitLab).

For more information about the VIRTIO specification, see the Organization for the Advancement of Structured Information Standards (OASIS) web site at www.oasis-open.org/.

virtio-entropy

The virtio-entropy vdev is a random number generation device that uses VIRTIO functions.

For information on how to configure and use this vdev, see vdev virtio-entropy in the User's Guide Virtual Device Reference chapter.

The first thing to note about the virtio-entropy vdev is that it requires the qvm/vio.h public header file, which includes functions, data structures, and definitions needed to support VIRTIO (see the vio.h chapter in the Virtual Device Developer's API Reference).

As with all para-virtualized devices, you can't expect an unmodified guest to be able to interact with this vdev. You need to modify it; typically, by adding a device driver or modifying an existing one. Fortunately, some support for VIRTIO devices is already available; for example, virtio-rng, which a Linux guest can load to support the virtio-entropy vdev.

Like other vdevs, the virtio-entropy vdev defines itself, initializes some values, and looks after its options. The only option it supports in addition to the common options (i.e., intr and loc, looked after by the qvm process) is the delayed option, which if specified delays opening /dev/random unitl the guest first requests a random number (see random in the QNX OS Utilities Reference).

Below are some key differences between this vdev and the emulation vdevs described in this guide.

PCI and VIRTIO initializations

After receiving VDEV_CTRL_OPTIONS_END, virtio-entropy calls init_vdev() to look after initializing PCI (e.g, PCI Vendor ID and device type) and VIRTIO; in particular, note that it calls vio_init(), a generic VIRTIO vdev initialization function, and vio_init_queue() to initialize a virtqueue for itself (for more information about virtqueues, see the VIRTIO specification).

Creating a thread to handle guest requests

When it is safe to do so; that is, after it receives VDEV_CTRL_GUEST_CONFIGURED, the virtio-entropy vdev calls vdev_thread_create() to create a new thread. It will use this thread to handle requests from the driver in the guest, when the guest requests a random number (for more information about when it is safe to create threads, see Lifecycle of a vdev in the About vdevs chapter).

Calling vio_read() and vio_write()

This vdev's vioentropy_vread() and vioentropy_vwrite() functions don't call guest_cpu_read() and guest_cpu_write() as you would expect in an emulation vdev's vread() and vwrite() functions. Instead they call vio_read() and vio_write(). These functions handle guest requests to read from and write to VIRTIO vdevs.

virtio-console

Like the source code for the virtio-entropy vdev, the source code for virtio-console is also available on GitLab at https://gitlab.com/qnx/hypervisor. For information on how to configure and use this vdev, see vdev virtio-console in the User's Guide Virtual Device Reference chapter.