Memory sharing

In a QNX hypervisor system, client applications running in guests can create and manage shared memory, and use shared memory regions to exchange data. However, these memory regions are ultimately controlled by the hypervisor, not by the guest. Host applications may also create shared memory regions or attach to them if permission allows.

QNX provides sample code showing how to use shared memory. For a QNX guest, this code is in the architecture-specific guest BSP under src/apps/hypervisor/demos/shmem-guest, for both the x86_64 and ARM BSPs. (For information about the included BSP packages, see the release notes for your QNX hypervisor product; for information about building a hypervisor system with these BSPs, see Methods of building a QNX hypervisor system.) For a Linux guest, a kernel module is needed, and the sample code for using this module is available in our GitLab repository at: https://gitlab.com/qnx/hypervisor/working-with-guests/shared-memory-device-example-for-linux-vdev-shmem. For the hypervisor host, the sample code is in any BSP that provides a hypervisor buildfile variant and is found under src/apps/hypervisor/demos/shmem-host.

To write hypervisor host modules that can share data with guests, you need to use the Virtualization API (libhyp.a). This is described in the Virtualization API Reference that's not included with the QNX hypervisor documentation. To obtain this additional documentation and support for writing host modules, contact your QNX representative.

How shared memory works

To use shared memory, a client application in a guest or in the hypervisor host needs:

• a mapping of the shared memory region
• a hardware interrupt it can use to signal other users of shared memory regions that this region has been updated

The hypervisor provides the shmem vdev, which implements setting up the shared memory mapping and the interrupts you need to use shared memory. This vdev provides additional functionality to simplify using this memory, including:

• memory region names (a QNX hypervisor system may include multiple named shared memory regions)
• configurable access permissions and group ownership for individual regions
• selective signaling (e.g., signal Guest 0 but not Guest 1)
• signal knowledge (the ability to know which guests have been signaled)

The figure below illustrates memory sharing between two guests:

Here, guest 0 attempts to attach to a 128 MB shared memory area (moo) first. Since no such area exists at the specified location, the attempt to attach creates the area and allows the guest to attach to it. Then, guest 1 can simply attach to the same name to share data with Guest 0.