Physical devices

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:

• exclusively available to a specific guest (see “Pass-through devices”)
• shared between guests; not all devices can be shared (see “Shared devices”)

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).

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:

• Modify the guest's device driver so that it doesn't attempt to modify the clocks.
• Create a vdev that intervenes when the guest's device attempts to manipulate the clocks.
• If the clock registers are appropriately spaced, pass the appropriate subset of the clock registers to the guest.

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:

• Referred sharing
• Mediated sharing

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.

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.

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.