Physical devices

A physical device may be for the exclusive use of the hypervisor host or of a guest, or it may be shared.

Physical devices (or simply devices) in a virtualized environment are exactly the same as devices in a non-virtualized environment. They require drivers, and they assert interrupts and receive signals, etc.

Guests running in a QNX virtualized environment may access a physical device directly or through a virtual device, or they may be prohibited from accessing a device. Access to physical devices is controlled by the configuration of the virtualized environment. A physical device may be configured to be:

Pass-through devices

In a hypervisor system, a pass-through device is a physical device to which a guest has direct and exclusive access. Because it is direct and exclusive, this type of access to a physical device may be faster than access through a virtual device, or than when access is shared with other guests or the hypervisor host.

To use a pass-through device, the guest must have its own driver for the physical device. No vdev is required in the qvm process hosting the guest, and no driver is required in the hypervisor itself.

With a pass-through device, the hypervisor host domain only knows that it must route interrupts from the physical device directly to the guest, and pass signals from the guest directly to the device. All interaction is between the guest and the device; the hypervisor’s only responsibility is to identify and allow to pass through the interrupts from the device, and the signals from the guest.

Figure 1. Illustration of a pass-through device in a hypervisor system.

Before the guest is launched, pass-through devices must be configured in the *.qvmconf file for the VM that will host the guest (see pass in the VM Configuration Reference chapter).

CAUTION:

In general, only one resident of a virtualized system is permitted access to a pass-through device at any one time. If the host owns a device that a guest requires as a pass-through device, the host must terminate the device driver before the guest can start a driver for the device in its virtual environment.

Similarly, if one guest owns a device as a pass-through device, it must terminate this device driver in its virtualized space before another guest can use the device in its space.

In short, you should never pass a DMA device through to more that one guest, and only in exceptional designs should you pass a non-DMA device through to more than one guest.

If you believe that your design requires that a non-DMA device be passed through to more than one guest, contact your QNX representative.

Passing through clock-dependent devices

Devices that are clock-dependent (e.g., eMMC devices) may require some additional work to be passed through, because the guest doesn't have access to the clocks. Strategies for passing through these devices include:

For more information, contact your QNX representative.

Working with pass-through of complex devices

Some devices (e.g., audio and video devices) consist of multiple hardware interfaces, and require very specific configurations in order to operate correctly.

A knowledgeable system designer who knows and understands how to use all the device interfaces, and can define them properly in the VM configuration should be able to make any complex device work as a pass-through device in a QNX hypervisor system.

Please contact QNX services for more information about the sharing of complex devices between guests.

Shared devices

In a hypervisor system, shared devices are physical devices that can be used by more than one guest, or by one or more guests and the hypervisor itself. There are several methods (e.g., VirtIO) and models available for device sharing; these include:

The hypervisor provides services such as TCP/IP, shared memory, and virtqueue support, which you can use for device sharing. The services and configurations you implement will depend on the requirements of your system.

Note: QNX hypervisors support vdevs that enable the sharing of audio and graphics physical devices. For more information, please contact your QNX representative.

Referred sharing

With the referred sharing model, the physical device that is to be shared is assigned to a guest, which has full control of the device. If the physical device is accessed as a pass-through device, the guest needs a driver for the physical device (see Pass-through devices above). If the physical device is accessed through a virtual device, the qvm process hosting the guest must have the appropriate virtual device (see Virtual devices in this chapter), and both the guest and the hypervisor host need the appropriate device drivers: for the virtualized device (guest), and for the actual physical device (host).

The other guests that also need to access the physical device use mechanisms such as TCP, or shared memory and virtqueues to communicate with the guest that controls the device, and pass data as needed.

For example, suppose that two guests are running on a hypervisor system. Guest 0 is a QNX safety-related guest, while Guest 1 is a garden-variety Linux OS guest with no safety requirements. They both need to access a device to output audio: Guest 0 to emit warning sounds, Guest 1 to play music.

We assign the audio device as a pass-through device to Guest 0. The audio virtual device in the qvm process for the VM hosting Guest 1 is designed to share data with a virtual device in another VM, and it is configured to know that this other virtual device is in the qvm process for the VM hosting Guest 0. With this configuration, all audio device activity for Guest 1 is referred to Guest 0 for processing.

When the virtual device in Guest 0’s qvm process receives interrupts and data for Guest 1, it passes them on to the virtual device in Guest 1’s qvm; when the virtual device in Guest 1's qvm process receives signals and data from Guest 1 for the audio device, it passes these on to Guest 0 to pass on to its audio device driver and, ultimately, to the physical audio device.

Since Guest 0 controls all input and output from the audio device, it can set priorities to ensure that safety-related processes and threads take precedence over input and output to the garden-variety OS and its applications, even refusing to cooperate with the other guest or with a device if cooperation might put its own safety-related activities in jeopardy.

CAUTION:
A guest that uses a physical device controlled by another guest depends on that other guest for access to the device; if for whatever reason the guest controlling the device becomes unavailable, the device also becomes unavailable.

Mediated sharing

The mediated sharing model is similar to the referred sharing model, with the difference that with the mediated model, it is processes in the hypervisor host rather than a guest that assume the responsibilities for controlling the interface with the physical device, and for ensuring that configured priorities are respected.

With this model, the device that is to be shared is assigned to the hypervisor itself. Virtual devices in the qvm process for each VM connect to a mediator in the hypervisor. This mediator determines which interrupts and data are passed on from the physical device to guests, and which signals and data are passed from guests to a device driver in the hypervisor and, ultimately, to the physical device.

The mediator also ensures that configured priorities are respected (e.g., ensuring that safety-related activities take precedence), even refusing to cooperate with a guest or device whose activities might be harmful to other guests on the system, or the hypervisor itself.

Note: The mediator processes don't necessarily have to reside in the hypervisor host. They can reside in one of the guests. Note, however, that with this design, a guest failure will cause undefined behavior for the mediated sharing.