Required components

To use the Shared USB framework in a QNX Hypervisor system, you must add components to your guest and host images. You must also configure the xHCI vdev in the guest's VM.

Host components

To support the USB framework, a host image must contain the following components:

xHCI vdev: The xHCI vdev, exhci, runs in the VM for each guest, where it emulates an xHCI host controller. As a result, the guest can use its existing xHCI device drivers, unmodified.; The vdev supports bulk and interrupt transfers for mass storage, keyboard, mouse, and network devices that comply with USB standards up to USB 3.0. To provide guests with access to connected devices, the vdev uses the USB stack that runs on the hypervisor host.; The vdev is implemented by a shared object, vdev-exhci.so, which you must add to the host's buildfile. See “Building the host” in the QNX Hypervisor User's Guide for information on host buildfiles. This shared object acts as a resource manager, allowing the enumerator to issue commands to make the vdev attach to or detach from USB devices.; The configuration for the VM hosting the guest must include the xHCI vdev. See “vdev exhci” in this chapter for the vdev configuration options, and “Assembling and configuring VMs” in the QNX Hypervisor User's Guide for information on the syntax of VM configuration files. The path to the VM configuration (*.qvmconf) file must also be in the host buildfile.
Enumerator: The host build must include an enumerator service that performs guest and USB device discovery and manages guest-to-device associations. The enumerator arbitrates requests from the host and from guests, typically on a first-come, first-served basis. On the host, this service is typically launched at bootup.; The reference images available for this release include the sharedusbmgr service. Source code for sharedusbmgr can be obtained from our community server; for information about doing so, see the Release Notes. You can use or adapt our enumerator, or write your own. If you do the latter, your replacement service must interface with the vdev-exhci.so resource manager. For more information, contact QNX Technical Support.; The USB launcher utility can run in parallel with our enumerator, but this isn't required. This utility performs different functions, as explained in the usblauncher_otg reference.; To interact with our enumerator, host applications use objects in its PPS interface. For example, the main HMI process can subscribe to this interface, so it can monitor and respond to device insertions and removals.
Persistent Publish/Subscribe (PPS) service: If you use our example enumerator, sharedusbmgr, your host build must include the PPS service because this enumerator uses it. See the pps entry in the QNX Neutrino Utilities Reference for details on how to launch this service. See also the PPS Developer's Guide to learn more about this service.
USB stack and USB hardware drivers: The same USB stack (io-usb-otg) and hardware controller drivers (devu-*) that you would use when running the QNX Neutrino RTOS outside of a QNX Hypervisor environment and without virtualization frameworks components must be included in the host build. No modifications to the stack or drivers are required.; The xHCI vdev runs as a client of the host's USB stack, which it uses to detect device removals and perform I/O. The stack handles the I/O; that is, data transfers to and from connected devices.; See the io-usb-otg entry in the QNX Neutrino Utilities Reference for details on the USB stack, and see the devu-* entries (e.g., devu-hcd-xhci.so) in the same guide for details about the hardware drivers.

Guest components

To support the USB framework, a guest image must contain the following components:

xHCI drivers: To communicate with the xHCI vdev, a guest image must include xHCI device drivers that support the class- or vendor-specific protocols used by the connected USB devices.; When adding a device driver to a virtualization frameworks guest, you should specify that the driver run as root. You should also set the read and execute access bits for the user, group, and other permissions.; See “Building guests” in the QNX Hypervisor User's Guide for more guidelines on building guests.