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. Note, however, that shared memory regions are ultimately created and controlled by the hypervisor; not by the guest. Host applications may also create shared memory regions or attach to them if permission allows.

The hypervisor-shmem-examples-*.tgz archive available with QNX hypervisors includes source code for sample memory-sharing programs: ghstest.c for a QNX guest and hhstest.c for the hypervisor 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 shared memory, including:

• shared memory region names (a QNX hypervisor system may include multiple named shared memory regions)
• selective signaling (e.g., signal Guest 0, but not Guest 3)
• signal knowledge (the ability to know which guests have been signaled)

The figure above illustrates memory sharing between two guests. 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. Guest 1 can simply attach to the same name to share data with Guest 0.