ARM SMMU versions 1 and 2
The ARM SMMU specification outlines an IOMMU architecture for ARM processors, similar to Intel's VT-d. The SMMU mediates accesses to RAM by devices, and can translate addresses generated by DMA engines so as to correct them as the OS requires.
This page is current with versions 1 and 2 of the SMMU specification. This page does not serve as an exhaustive description of the SMMU. It is meant to serve as a refresher to jog the memory of people who have already read the SMMU specification.
Terminology:
- Just in general, the SMMU spec refers to DMA engines and MCUs on the chipset as being "upstream" from the SMMU and it refers to RAM as being "downstream" from the SMMU.
- The "Stream mapping table" is a term used to refer to the combined working of the SMMU_SMRn + SMMU_S2CRn registers. Do not confuse the SMMU_SMRn ("Stream **match**ing registers") with the umbrella term "Stream **mapp**ing registers".
- "Contexts" are synonymous with Intel's "domain" terminology used in the VT-d specification; they refer to a set of IO-page tables for translating IO-Addresses into output addresses on the bus/memory controller.
- Transactions: Any write to or read from the SMMU by any agent is an SMMU transaction.
- Client transactions: Client transactions are requests sent through the SMMU which can be potentially translated. These are generally bus messages.
- Configuration transactions: Configuration transactions are accesses to the SMMU register interface to program the SMMU's behaviour (using the SMMU_* registers).
Usage model
Contrast against Intel VT-d
Both SMMU and VT-d support 1st-stage translation. 1st-stage translation can be used:
- To isolate devices and ensure that they don't access memory beyond what they are expected to (i.e, beyond the scatter gather list that has currently been programmed into the device).
VT-d 1st-stage translation can be used:
- To isolate guest VMs and ensure that they don't touch memory outside of what they have been allocated as their guest physical address space (IPA addrspace).
Only SMMU supports 2nd-stage translation. 2nd stage translation can be used:
- When passing a device through to a guest VM, to translate the IPA addresses that the guest will program into the device, into their correct PAs.
Only VT-d supports PASID 2nd-stage translation. PASID translation can be used:
- To enable a device to directly walk the page tables of userspace processes, and translate virtual addresses into physical addresses.
- For example, the virtual address of a graphics texture buffer can be sent to the GFX card directly, and the VT-d DHRU will be able to walk the page tables of the sending process and translate the virtual address on its own.
- PASID translation is then chained into the standard translation flow to isolate the device's address accesses in the standard way that an IOMMU is normally used.
Secure/Non-secure mode split and SSD
The SMMU splits its registers for use between secure and non-secure mode; both modes can use the SMMU at the same time and there is register banking for some of the registers to facilitate this. Because both modes can use the SMMU at the same time, the SMMU also needs to know which devices have been partitioned into secure-mode devices and which are left for non-secure mode. In particular, secure mode devices can generate client transactions which access both secure memory and non-secure memory whereas non-secure mode devices can only access non-secure memory.
There is a distinction to be kept in mind about the difference between the SMMU's SSD feature (Security-State Determination) and the marking of a transaction by an upstream bus technology/device as either secure or non-secure. A non-secure device may maliciously mark its transactions as being secure, so the SSD feature which sits within the SMMU is meant to thwart that. When an upstream device is determined to be SSD-non-secure, the SMMU will never generate a downstream transaction which is marked secure. When an upstream device is determined to be SSD-secure, the SMMU may generate a downstream transaction which is either secure or non-secure.
- The SMMU may not have a programmable SSD register space, in which case the SSD determination is done via some [implementation defined] mechanism attached to the SMMU.
- The SMMU SSD register space is present if SMMU_IDR1.SSDTP == 0b01 or 0b11.
- When this field has either of those values, the SSD space is present in the SMMU.
- When the SSD space is present in the SMMU, the SMMU_SSDRn registers are present.
- These SMMU_SSDRn registers are bitfields, 32 bits each. If bit<N> is 1 then device<N> is non-secure, else it is secure.
Translation, bypass and faulting
The SMMU will do one of 3 things with any client transaction that is sent to it:
- Translate the transaction using translation tables.
- Allow the transaction to bypass translation, and just modify the attributes of the transaction (read/write, shareability, caching, etc).
- Generate an SMMU fault.
