The sensor-sharing framework provides a virtual device (vdev) that lets guest applications access data from a sensor connected to the host. Sensor data requests from guests are sent to the host using the SCMI messaging protocol. The back end of the framework on the host uses existing QNX components to fulfill these requests.
Note:
This chapter assumes that you are already familiar with the concepts presented in the following documentation:
- QNX Hypervisor User's Guide
- The virtualization frameworks architecture
The vdev, virtio-scmi, is based on the unofficial draft version 5 of the VirtIO 1.2 specification. Our implementation supports the sections of the SCMI 3.0 standard related to the retrieval of gyroscope and accelerometer data (which are accessible as separate sensors).
Sensor sharing
In this framework, the guest needs a driver that works in a virtual environment, and the host manages all interactions between
guests and the sensor hardware. This is done as follows:
- The hypervisor host contains the Sensor Framework middleware that works with the sensor hardware. This middleware includes the Sensor library, which provides an interface to higher layers for accessing sensors.
- To allow a guest to access a sensor, such as an IMU sensor, the VM (i.e., qvm process) that hosts the guest must include the SCMI vdev (virtio-scmi).
- To interact with the vdev, a guest runs a driver that complies with the SCMI messaging standard. Android guests use the Industrial I/O (IIO) SCMI kernel driver.
- To communicate with each other (command and control), the SCMI driver and the vdev use virtqueues, which are the standard mechanism for data transport on VirtIO devices.
- Host applications can use the Sensor Framework to access the same sensors as the guests.
The diagram below illustrates the interaction between a guest and sensors on the host system.
This interaction is done through the virtio-scmi vdev and the Sensor middleware on the host.
Figure 1. Sensor-sharing framework architecture
Figure 1. Sensor-sharing framework architecture
Note:
The sensor-sharing framework requires the Sensor Framework middleware for its operation,
so that the vdev backend can interact with the hardware.
Because the middleware is part of the latest version of QNX SDP, by default, it's installed on your development system
and included in the host image.
Note:
For more information on device sharing in the QNX Hypervisor, see the section on “Devices” in the
“Understanding QNX Virtual Environments” chapter of the QNX Hypervisor
User's Guide.
Sensor virtualization
Guest applications don't have to change any code to read sensor data on the host—they can keep using their native sensor
services. For instance, Android applications use the Sensors Multi-HAL interface to retrieve sensor data from sensors.
The Multi-HAL layer uses an IIO SCMI driver (included with Android) to access the sensor device.
In this case, it's our vdev, which responds to SCMI commands.
This capability, which we refer to as sensor virtualization, is supported by the following host-side components:
- virtio-scmi vdev
- The virtio-scmi vdev is a para-virtualized device that enables sensor data requests from guests, encoded as SCMI commands, to be executed on the host. This vdev runs in a hypervisor VM but doesn't emulate a hardware sensor. Instead, it forwards sensor requests received through the guest driver to the Sensor library, and reports the results (through sensor update notifications) back to the guest driver.
- Sensor library
- This library provides applications with an interface to access sensors connected to the host. The interface supports functions such as starting and stopping sensor units, accessing sensor data and status, and more. The Sensor library uses the Sensor service to carry out these operations.
- Sensor service
- The Sensor service interacts directly with the sensor hardware. The Sensor configuration file is where you must configure the sensors that you want to make available to guest applications.