{
  "schemaVersion": 1,
  "id": "atlas-lesson-process-dma-address-spaces",
  "title": "Process, physical and device address spaces",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Trace the same allocated bytes through separate CPU virtual and device-visible mappings.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/",
  "publishedDate": null,
  "revisionDate": "2026-10-07",
  "author": null,
  "topic": "Executable software",
  "series": null,
  "license": null,
  "rightsUrl": "https://semiaifoundry.com/ai-atlas/licenses.html",
  "version": "1.3.0",
  "status": "Published educational lesson",
  "evidenceScope": "Primary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed.",
  "contentCoverage": "published-lesson",
  "artifactUrl": "https://semiaifoundry.com/ai-atlas/lesson-data/process-dma-address-spaces-09d9cb6220362ce0.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#process-dma-address-spaces",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "43335ca9d896ad080a7b18cf0101e321ec0e3caeb7601552ec420d1034830c34",
  "contentLength": 5894,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-process-dma-address-spaces.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-process-dma-address-spaces.md",
  "sections": [
    {
      "id": "section-1",
      "title": "Process, physical and device address spaces",
      "start": 36,
      "end": 494
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 494,
      "end": 2013
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 2013,
      "end": 2041
    },
    {
      "id": "section-4",
      "title": "Preserve the offset across address spaces",
      "start": 2041,
      "end": 2680
    },
    {
      "id": "section-5",
      "title": "Engineering example",
      "start": 2680,
      "end": 3117
    },
    {
      "id": "section-6",
      "title": "Distinctions and tradeoffs",
      "start": 3117,
      "end": 3712
    },
    {
      "id": "section-7",
      "title": "Specifications and interfaces",
      "start": 3712,
      "end": 4044
    },
    {
      "id": "section-8",
      "title": "Interfaces",
      "start": 4044,
      "end": 4289
    },
    {
      "id": "section-9",
      "title": "Check your understanding",
      "start": 4289,
      "end": 4318
    },
    {
      "id": "section-10",
      "title": "Which device address reaches A’s fourth word in this declared map?",
      "start": 4318,
      "end": 4517
    },
    {
      "id": "section-11",
      "title": "Evidence and scope",
      "start": 4517,
      "end": 5035
    },
    {
      "id": "section-12",
      "title": "Sources",
      "start": 5035,
      "end": 5356
    },
    {
      "id": "section-13",
      "title": "Continue exploring",
      "start": 5356,
      "end": 5379
    },
    {
      "id": "section-14",
      "title": "Foundations",
      "start": 5379,
      "end": 5570
    },
    {
      "id": "section-15",
      "title": "Related lessons",
      "start": 5570,
      "end": 5894
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#process-dma-address-spaces"
    },
    {
      "title": "Linux 6.16 — Dynamic DMA mapping Guide",
      "url": "https://docs.kernel.org/6.16/core-api/dma-api-howto.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/process-dma-address-spaces-09d9cb6220362ce0.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Host CPU",
      "url": "https://semiaifoundry.com/learn/atlas/host-cpu/"
    },
    {
      "title": "Firmware handoff and device readiness",
      "url": "https://semiaifoundry.com/learn/atlas/firmware-device-contract/"
    },
    {
      "title": "IOMMU permission and tensor identity",
      "url": "https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/"
    },
    {
      "title": "PCI Express interconnect",
      "url": "https://semiaifoundry.com/learn/atlas/pcie-interface/"
    },
    {
      "title": "PCIe and CXL: transport versus memory semantics",
      "url": "https://semiaifoundry.com/learn/atlas/pcie-cxl-semantics/"
    }
  ],
  "recordHash": "23e061c521ed8112309376ff670ff83040a2ab2e431ba47cb8f02f635844890b",
  "contentFormat": "text/markdown",
  "content": "Executable software · Atlas v1.3.0\n\n# Process, physical and device address spaces\n\nTrace the same allocated bytes through separate CPU virtual and device-visible mappings.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#process-dma-address-spaces)One process and device job; logical states and byte addresses, no timing or physical geometry\n\nLearning objectiveResolve a matrix element from both virtual and device address spaces and identify which namespace a descriptor must contain.\n\n## The mechanism\n\nA matrix buffer has an identity and contents independent of the address used to reach it. The CPU executes in an address space that translates process virtual addresses into physical storage. A DMA-capable device issues its own addresses, which can pass through a separate translation. Confusing these namespaces can make a descriptor unusable even though its numerical value looks like a valid pointer. In the teaching trace, the CPU and device reach the same buffer by different base addresses while preserving the offset within the buffer. Each namespace has its own bounds. The inspection table records the process identity, virtual base, physical base, device base and current epoch, so a copied address can be checked against its intended interpreter. These are declared sixteen-byte regions rather than a real page-table layout. They illustrate translation without pretending to model page pinning, page faults, TLB walks or virtual-machine isolation.\n\n1.  The process owns A, B and C as stable sixteen-byte objects.\n2.  CPU writes use virtual addresses and translate to the corresponding physical region.\n3.  The driver supplies a device-visible IOVA in the command descriptor, not a process pointer.\n4.  A device translation selects physical storage and adds the byte offset within its declared region.\n5.  Each word occupies four bytes; the last word begins twelve bytes after the buffer base.\n6.  An address from the wrong namespace has no matching range in this specimen and is rejected.\n\n## Science and assumptions\n\n### Preserve the offset across address spaces\n\n$$\np=p_0+(v-v_0)=p_0+(d-d_0),\\qquad 0\\leq v-v_0<16\n$$\n\nPhysical address equals its buffer base plus the virtual or device byte offset.\n\nSymbols and units\n\np,p0\n\nPhysical byte address and buffer base\n\nbytes\n\nv,v0\n\nProcess virtual byte address and buffer base\n\nbytes\n\nd,d0\n\nDevice byte address and buffer base\n\nbytes\n\nUnder the correct two mappings, a CPU and a device address with the same in-buffer offset reach the same physical byte.\n\nAssumptions The virtual and device bases refer to the same declared object. The inequality bounds a single byte; a multi-byte access must fit completely.\n\n## Engineering example\n\nFor A\\[1,1\\], the row-major element index is 3 and its four-byte word starts at offset 12. CPU VA 0x100C and device IOVA 0x800C both resolve to PA 0x400C. Passing 0x100C directly to this device fails: its device table starts A at 0x8000, not 0x1000. Passing 0x800C to the process mapping likewise fails. Equal physical destination follows from two explicit mappings, not from numerical equality of the pointers.\n\n## Distinctions and tradeoffs\n\nAn address is interpreted within an address space; an application pointer is not automatically a DMA address.\n\nTranslation enables placement and isolation but adds state that must remain valid for the whole access lifetime. Real page granularity can expose more storage than a small logical buffer, which this byte-range teaching model does not simulate.\n\nTensor runtimes pass buffers through host and accelerator execution. Keeping object identity separate from pointers prevents mistakes when memory is remapped or devices have distinct addressing constraints.\n\n## Specifications and interfaces\n\nA bases\n\nVA 0x1000 → PA 0x4000 ← IOVA 0x8000\n\nChosen teaching addresses, expressed in bytes.\n\nB bases\n\nVA 0x2000 → PA 0x5000 ← IOVA 0x9000\n\nA separate object even if equal values happen to be stored.\n\nC bases\n\nVA 0x3000 → PA 0x6000 ← IOVA 0xA000\n\nDevice write permission; sixteen allocated bytes.\n\n### Interfaces\n\nDeclared runtime inputs Input\n\nStable matrix job, buffer identities and the stated device/visibility contract\n\nInspectable accepted or rejected result Output\n\nEvent trace, actual buffer values and bounded completion/work ledger\n\n## Check your understanding\n\n### Which device address reaches A’s fourth word in this declared map?\n\n1.  0x100C\n2.  0x400C\n3.  0x800C\n\nAnswer and reasoning\n\n0x800C\n\nThe descriptor uses the device base 0x8000 plus twelve bytes.\n\n## Evidence and scope\n\nPrimary sources establish the cited runtime mechanisms. Numerical values, address ranges, ABI strings, event schedule and reset/retry epochs are authored teaching contracts. No real device, firmware image, operating-system driver, page table, cache protocol or security verification is executed.\n\nThe commissioning-execution-1 studio executes this bounded 2×2 matrix, buffer and completion contract. The surrounding atlas scene is conceptual; it is not a firmware emulator or system simulator.\n\n## Sources\n\n-   [Linux 6.16 — Dynamic DMA mapping Guide](https://docs.kernel.org/6.16/core-api/dma-api-howto.html)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/process-dma-address-spaces-09d9cb6220362ce0.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Host CPU](https://semiaifoundry.com/learn/atlas/host-cpu/)\n-   [Firmware handoff and device readiness](https://semiaifoundry.com/learn/atlas/firmware-device-contract/)\n\n### Related lessons\n\n-   [IOMMU permission and tensor identity](https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/)\n-   [PCI Express interconnect](https://semiaifoundry.com/learn/atlas/pcie-interface/)\n-   [PCIe and CXL: transport versus memory semantics](https://semiaifoundry.com/learn/atlas/pcie-cxl-semantics/)"
}