A physical device can be for the exclusive use of the hypervisor host or of a guest,
or it can 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.
Before the guest is launched, pass-through devices must be configured in the
*.qvmconf file for the VM that will host the guest (see
Configuring pass-through in the
Configuration chapter).
CAUTION:
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, never configure the same pass-through device for more than a single
guest (see
Configuring pass-through).
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 definition 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 hardware 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: The QNX Hypervisor supports 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 below), and both the guest and the
hypervisor need the appropriate device drivers: for the virtualized device (guest),
and for the actual physical device (hypervisor).
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 qvm process, 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.
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.