Memory sharing
Guests in a hypervisor system can use shared memory to pass data to each other or to the hypervisor host.
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 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 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)
moo) shared by Guest 0 and Guest 1
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.
All connections to a shared memory region are peers. That is, there is no distinction between the guest that creates a shared memory region and the guest that attaches to it. The first attempt to attach to a shared memory region creates the region, but as far as the guest is concerned, it simply attaches to the region. When the last guest detaches from a shared memory region, it destroys the region.
This design avoids ordering problems where the system designer would have to make sure that one guest always comes up and creates the shared memory region before another guest tries to attach to it.