The hypervisor uses an IOMMU/SMMU Manager (smmuman) that ensures that no pass-through DMA device is able to access host-physical memory to which it has not been explicitly granted access.
A non-CPU-initiated read or write is a read or write request from a Direct Memory Access (DMA) device (e.g., GPU, network card, sound card). An IOMMU (SMMU on ARM architectures) is a hardware/firmware component that provides translation and access control for non-CPU initiated reads and writes, similar to the translation and access control second-stage page tables provide for CPU-initiated reads and writes.
The SMMU manager (smmuman) works with the IOMMUs or SMMUs on supported hardware platforms to:
A library (libsmmu) provides the client-side API into smmuman.
The smmuman service is a QNX Neutrino OS service. In a QNX Hypervisor system, it runs as a service in the hypervisor host domain and is started at hypervisor host startup.
When it starts, smmuman learns which SMMUs on the board control which DMA devices. Later, qvm process instances will be able to ask smmuman to inform the board SMMUs of the memory locations DMA devices are permitted to access.
With the information about DMA devices obtained at startup, during operation the IOMMUs/SMMUs will know to reject any attempts by DMA devices to access memory outside their permitted locations.
During operation, smmuman monitors the system IOMMUs/SMMUs. If all DMA devices are behaving as expected, smmuman does nothing except continue monitoring. However, if a DMA device attempts to access memory outside its permitted locations, the IOMMU/SMMU hardware rejects the attempt, and smmuman records the incident internally.
Clients may use the smmuman API provided in libsmmu to obtain the information and output it to a useful location, such as to the system logger (see slogger2 in the QNX Neutrino OS Utilities Reference). You can then use this information to learn more about the source of the illegal memory access attempt, and troubleshoot the problem.
The qvm process instances in a QNX Hypervisor system are smmuman clients:
There is one exception to the above rules of behavior: unity-mapped guests. A guest is unity-mapped if all guest-physical memory allocated in the guest's VM is mapped directly to the host-physical memory (e.g., 0x80000000 in the guest maps to 0x80000000 in the host).
If a guest is unity-mapped, if smmuman isn't running or doesn't know how to handle a device, the qvm process instance hosting the guest will report the problem as expected, but it will also start.
Information about which IOMMU/SMMU controls which DMA device may be available in different locations, depending on the board architecture and the specific board itself (e.g., in ACPI tables, in board-specific code). To obtain this information, smmuman queries the firmware, and accepts user-input configuration information.
By default, the user-input information will override the information obtained from the board, so that it can replace corrupt or otherwise unreliable information on the firmware. However, the user may request that smmuman keep the information obtained from the board and merge it with the user-input information.
The QNX Hypervisor installation packages include smmuman configuration files. These files may be specific to a reference board. For example, two files are provided for the R-Car H3 boards:
For x86 boards, the configuration is specific to a board's VT-d variant support. A configuration file is required only for non-standard implementations.
Make sure you use the appropriate configuration file when you start smmuman.
For information about how to configure smmuman see smmuman in the “Utilities and Drivers Reference” chapter.
Use of smmuman isn't restricted to qvm process instances. Other processes in the host may also be smmuman clients.