Skip to content
System IOMMU / SMMU

System IOMMU / SMMU

Address Translation Handoff resolved a key to a physical address and moved on. That address is physical from this engine’s own Key Cache’s vantage point – not necessarily the address that actually lands on a DRAM row. In any virtualized, SR-IOV, or PCIe-passthrough deployment, a system-level IOMMU or SMMU sits between this engine’s own output and real memory, retranslating an address this book has been calling final. This topic covers the RNIC-facing half of that boundary – not the IOMMU/SMMU’s own internal mechanism, which is a different site’s territory entirely, but what having one in the datapath means for this engine specifically: whether it’s transparent, what a miss costs, and whether a real implementation has any way to avoid paying that cost on every single transfer.

Chapters

Transparent by Default
Every ‘physical address’ this book has named so far is physical from this engine’s own Key Cache’s vantage point. Whether it’s also the address that actually lands on a DRAM row depends on a layer this engine has no architectural awareness of at all – and, by default, no way to find out.
IOTLB Misses and the Latency This Engine Can't See
Transparent doesn’t mean free. A system-level IOMMU or SMMU’s own cache miss adds real, measured latency to a transfer this engine has already committed a slot to – and this engine has no event, no status bit, and no way at all to learn that’s what just happened.
ATS: Caching a Translation Locally
Transparent by Default’s default costs a full round trip to the system-level translation layer on every access this engine’s own cache doesn’t already know about. PCIe’s own Address Translation Services extension is the one real mechanism that lets a device cache that answer locally instead – on request, not by default.
Last updated on