Para-virtualized devices implemented in QNX hypervisors use the VirtIO 1.0 specification by default.
The VirtIO 0.95 specification is also supported; where relevant, VirtIO vdevs included with the QNX hypervisor 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 QNX Hypervisor for Safety 2.0 User's Guide, and the source code on GitHub).
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/.
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 vdevs, you can't expect an unmodified guest to be able to interact with this vdev. You may 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 SDP Utilities Reference).
Below are some key differences between this vdev and the emulation vdevs described in this guide.
After receiving VDEV_CTRL_OPTIONS_END, virtio-entropy calls vdev_init() 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).
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).
This vdev's vioentropy_vread() and vioentropy_vwrite() functions don't call, respectively, guest_cpu_write() and guest_cpu_read() as you would expect in an emulation vdev's vread() and vwrite() functions. Instead they call, respectivley, vio_read() and vio_write(). These functions handle guest requests to read from and write to VirtIO vdevs.
In addition to the source code for the virtio-entropy vdev, QNX has made available on GitHub (github.com/qnx) the source code for the vdev virtio-console vdev. For information on how to configure and use this vdev, see vdev virtio-console in the User's Guide “Virtual Device Reference” chapter.