Configuring the VMs

The shmem vdev can be added to a VM configuration, just like any other vdev.

To include the shmem vdev in the VM that will host a guest using shared memory services, simply add it to the qvm configuration. Make sure that it is in the qvm configuration for every VM with a guest that will need to use the shared memory services. For example:

# qnxcluster.qvmconf example
#Give this guest a name
system cluster
ram 1024M
cpu
cpu
load /emmc/QNX_cluster.ifs
vdev ioapic
        loc 0xf8000000
        intr apic
        name myioapic
vdev ser8250
        intr myioapic:4
vdev timer8254
        intr myioapic:0
vdev mc146818
vdev shmem
vdev pckeyboard

The line of particular interest in the qvm configuration information above is:

vdev shmem

This is a PCI device. If you specify its loc and intr properties, the guest will see it as an MMIO device at the specified location. For example:

vdev shmem
	create TEST1,0xf0000	# name is TEST1 with size of 0xf0000
	loc 0x10000000		# location of factory page
	intr myioapic:10	# hardware interrupt used for signaling

will cause the qvm process to create a shared memory region “TEST1” when it starts up and assembles the VM. The configuration assumes that a vdev ioapic called “myioapic” has already been specified.

Note:

Since the qvm process creates the shared memory region when it starts up (rather than when a guest attempts to attach to it), you can ensure there's enough underlying physical memory on the host system for the region.

For more information about qvm configuration files and how to use them to assemble a VM, see “Assembling and configuring VMs” in the “Configuration” chapter.

Using the allow and deny options

You can use the shmem vdev's allow and deny options to establish a restrictions list of shared memory regions the guest may and may not access (see vdev shmem) in the “Virtual Device Reference” chapter).

The hypervisor enforces the access and denial properties specified in the restrictions list at runtime. This enforcement ensures that code in a guest can't access specified shared memory regions without explicit permission to do so, or create vulnerable shared memory regions areas that another guest in the hypervisor system might find and mine for information.