The shmem vdev provides a simple mechanism for sharing memory regions between guests, or between guests and the hypervisor host.
For complete configuration information for this vdev, see vdev shmem in the Virtual Device Reference chapter.
The shmem vdev appears to client application code running in a guest or in the hypervisor host as a device with a mapped register set in guest-physical or host-physical memory and the ability to raise interrupts.
This client code is simply a driver for the shmem vdev, rather than for some physical device (see Virtual devices in the Understanding QNX Virtual Environments chapter). The client running in a guest or in the host can use the shmem vdev register set to connect to an existing named shared memory region, or to create a new such region and connect to it.
Two methods are available for specifying a shared memory factory page in the VM configuration: MMIO and PCI (see Factory and control pages). To locate a factory page, clients in a guest or the host must use the method that corresponds to the method that was used to specify the factory page:
When your client application in the guest has obtained the factory page's base address in guest-physical memory, it can use mmap() to map the address into a virtual address. The relevant registers are in the guest_shm_factory data structure, defined in the guest_shm.h public header file.
The shmem vdev is the factory; the client writes to virtual registers in the factory page, which causes the shmem vdev to create shared memory regions, if these regions don't already exist.
That is, the factory page client (i.e., the shmem vdev driver) writes a name and size to the factory page. This action prompts the shmem vdev: if the specified shared memory region doesn't already exist, the shmem vdev creates it along with its control page, returning their location in guest-physical memory to the client; or, if the region already exists, the vdev simply returns the location. This create-on-first-use behavior allows guests to be started in any order; whichever guest is first to attempt to access a shared memory region creates the region.
When accessing a named shared memory region, the client application needs to do the following with the guest_shm_factory data structure for the factory page: