Address Translation Handoff
Overview
Neither address Target Selection names is usable yet – a software-named lkey and a wire-named rkey are both still keys, not physical addresses. Turning one into the other is Key Caching’s mechanism in full, already covered field by field, hit and miss, eviction and all. This chapter doesn’t re-derive any of that. It names one thing: this is the stage that calls it.
Concept
“Address Translation” isn’t this engine’s own lookup structure – it’s this engine’s name for the moment it hands a key to Key Caching and waits for a physical address back. The structure, the working set, and the eviction policy behind that answer all belong to Memory Region / Key Table, not here.
Locator
Block diagram
Deep walkthrough
One combined lookup, not two sequential ones. Permission and Bounds Violations already stated this plainly for the check itself: no source documents bounds and permission validation as separate stages run in a specific order, or even confirms they’re separate at all rather than “one combined table-entry validation that either passes or doesn’t.” This chapter treats address resolution the same honest way – the single call into Key Cache this stage makes is what produces a physical address and a pass/fail verdict together, not two lookups with one running first.
What this engine hands over, and what it gets back. A key (lkey or rkey, per Target Selection), the address and length the operation names, and which kind of access this transfer needs (read, for a gather; write, for a scatter) go in. A physical address comes back on a pass; a fail comes back as the same rejected-lookup outcome Permission and Bounds Violations already covers in full, including its own honest admission that hardware can’t distinguish a bounds failure from a permission failure in what it reports. This chapter adds nothing to that reporting – a failed lookup here is that chapter’s event, not a new one.
Reading RX PSN Check and Out-of-Order Arrival’s handoff precisely. That chapter describes an arriving packet as already having “cleared permission and bounds checking” by the time it reaches this engine. Read that as naming the complete set of conditions a payload needs satisfied before it can land, not as asserting a separate, earlier pipeline stage that ran the check before this one exists. The lookup that actually clears permission and bounds is this stage’s own call into Key Cache – the same lookup, not a redundant second one.
Gotcha
Don’t go looking for a distinct “permission pre-check” stage somewhere in RX Pipeline that runs before this one. Nothing this book has found describes one, and Permission and Bounds Violations’ own position – one combined validation, no documented internal order – argues against inventing one here for tidiness.
This engine is a reader here, and nowhere else either. MR Capacity and Timing already established this fact directly: “nothing about a routine DMA writes back into the address, length, permission, or translation fields it consulted.” Every lookup this stage makes is read-only against Key Cache – registration and deregistration are the only two events that ever write that structure, both arriving over a control path this engine never touches.
Where this connects. A passing lookup hands a physical address forward into The Gather Path or The Scatter Path, whichever Target Selection’s direction called for. Whether this engine holds that resolved address privately for a whole burst, or re-derives it from Key Cache more than once during a long transfer, is the open question Mid-Transaction Burst Teardown covers, not this chapter – this chapter only names the single call that happens at least once, at the start.
Gotcha
“Physical address” here means this engine’s own Key Cache’s resolved endpoint – not necessarily the last translation a byte passes through before it reaches DRAM. In any virtualized, SR-IOV, or PCIe-passthrough deployment, a system-level IOMMU or SMMU retranslates this address again, transparently to this engine by default. System IOMMU / SMMU covers that boundary, including what a miss in its own translation cache costs (IOTLB Misses and the Latency This Engine Can’t See) and how a device can cache the second translation itself (ATS: Caching a Translation Locally); this chapter’s own use of “physical address” stays accurate for what it describes, just scoped one layer short of the whole path.
Interface reference
| Question | Answer |
|---|---|
| What performs the lookup | Key Caching – not a structure this engine owns |
| What goes in | a key (lkey/rkey), the named address and length, and the access type (read or write) |
| What comes back on a pass | a physical address |
| What comes back on a fail | the same rejected-lookup event Permission and Bounds Violations covers – no separate DMA-Engine-specific fault type |
| Is this a read or a write against Key Cache | always a read – confirmed directly by MR Capacity and Timing |
References
- No IBTA standard names an “address translation handoff” as its own mechanism – this chapter is entirely a pointer to Memory Region / Key Table’s own, already-cited research, applied here only to name the calling convention.