{
  "schemaVersion": 1,
  "id": "atlas-lesson-dma-visibility-ownership",
  "title": "DMA visibility, ordering and buffer lifetime",
  "category": "learning",
  "format": "Atlas lesson",
  "description": "Separate coherent values, ordered descriptor publication and ownership of in-flight storage.",
  "canonicalUrl": "https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/",
  "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/dma-visibility-ownership-82d7e647892c3b29.json",
  "interactiveUrl": "https://semiaifoundry.com/ai-atlas/#dma-visibility-ownership",
  "related": [],
  "supersedes": [],
  "supersededBy": [],
  "contentHash": "daed6e18f2275f31a64cfafc9fb0c771d14bf9121f008fa7551e3e66e0114907",
  "contentLength": 7014,
  "jsonUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-dma-visibility-ownership.json",
  "markdownUrl": "https://semiaifoundry.com/agents/publications/atlas-lesson-dma-visibility-ownership.md",
  "sections": [
    {
      "id": "section-1",
      "title": "DMA visibility, ordering and buffer lifetime",
      "start": 36,
      "end": 513
    },
    {
      "id": "section-2",
      "title": "The mechanism",
      "start": 513,
      "end": 2042
    },
    {
      "id": "section-3",
      "title": "Science and assumptions",
      "start": 2042,
      "end": 2070
    },
    {
      "id": "section-4",
      "title": "Input visibility changes the actual operand",
      "start": 2070,
      "end": 2801
    },
    {
      "id": "section-5",
      "title": "Buffer reuse follows ownership",
      "start": 2801,
      "end": 3464
    },
    {
      "id": "section-6",
      "title": "Engineering example",
      "start": 3464,
      "end": 3911
    },
    {
      "id": "section-7",
      "title": "Distinctions and tradeoffs",
      "start": 3911,
      "end": 4426
    },
    {
      "id": "section-8",
      "title": "Specifications and interfaces",
      "start": 4426,
      "end": 4820
    },
    {
      "id": "section-9",
      "title": "Interfaces",
      "start": 4820,
      "end": 5065
    },
    {
      "id": "section-10",
      "title": "Check your understanding",
      "start": 5065,
      "end": 5094
    },
    {
      "id": "section-11",
      "title": "Physical C is correct, but the noncoherent CPU output handoff was omitted. What does the fixture consumer read?",
      "start": 5094,
      "end": 5470
    },
    {
      "id": "section-12",
      "title": "Evidence and scope",
      "start": 5470,
      "end": 5988
    },
    {
      "id": "section-13",
      "title": "Sources",
      "start": 5988,
      "end": 6426
    },
    {
      "id": "section-14",
      "title": "Continue exploring",
      "start": 6426,
      "end": 6449
    },
    {
      "id": "section-15",
      "title": "Foundations",
      "start": 6449,
      "end": 6660
    },
    {
      "id": "section-16",
      "title": "Related lessons",
      "start": 6660,
      "end": 7014
    }
  ],
  "citations": [
    {
      "title": "Explore in Atlas",
      "url": "https://semiaifoundry.com/ai-atlas/#dma-visibility-ownership"
    },
    {
      "title": "Linux 6.16 — Dynamic DMA mapping Guide",
      "url": "https://docs.kernel.org/6.16/core-api/dma-api-howto.html"
    },
    {
      "title": "OASIS — Virtual I/O Device (VIRTIO) Version 1.3",
      "url": "https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html"
    },
    {
      "title": "Published lesson data",
      "url": "https://semiaifoundry.com/ai-atlas/lesson-data/dma-visibility-ownership-82d7e647892c3b29.json"
    },
    {
      "title": "Atlas releases and licensing",
      "url": "https://semiaifoundry.com/ai-atlas/licenses.html"
    },
    {
      "title": "Process, physical and device address spaces",
      "url": "https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/"
    },
    {
      "title": "L1 and texture cache",
      "url": "https://semiaifoundry.com/learn/atlas/l1-cache/"
    },
    {
      "title": "IOMMU permission and tensor identity",
      "url": "https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/"
    },
    {
      "title": "Completion, reset and execution epochs",
      "url": "https://semiaifoundry.com/learn/atlas/device-completion-reset-epochs/"
    },
    {
      "title": "PCIe and CXL: transport versus memory semantics",
      "url": "https://semiaifoundry.com/learn/atlas/pcie-cxl-semantics/"
    }
  ],
  "recordHash": "0b58a1fc0c74114af9c9922e956ad7d4e0984419a383d894ca78d5889feacdd0",
  "contentFormat": "text/markdown",
  "content": "Executable software · Atlas v1.3.0\n\n# DMA visibility, ordering and buffer lifetime\n\nSeparate coherent values, ordered descriptor publication and ownership of in-flight storage.\n\n[Explore in Atlas](https://semiaifoundry.com/ai-atlas/#dma-visibility-ownership)One process and device job; logical states and byte addresses, no timing or physical geometry\n\nLearning objectiveDiagnose whether a failed job violated data visibility, descriptor ordering or buffer lifetime, using the actual copies and ownership trace.\n\n## The mechanism\n\nA CPU and a device can refer to the same physical storage while observing different versions of its data. The noncoherent teaching mode makes that discrepancy explicit with a CPU-visible copy and a memory copy. Inputs start as dirty CPU values over zeroed memory; output begins with a sentinel in both copies. Visibility handoffs reconcile them at the chosen ownership boundary. Coherent mode keeps the values equal without these copies, but it does not authorize reuse of storage still owned by a running job. Nor does it remove the need to publish descriptor fields before making the descriptor valid. The model treats those as separate actions. This separation explains why replacing a cache flush with a completion wait, or replacing a lifetime check with coherence, addresses the wrong condition. A result can be mathematically correct in physical memory while the consumer still reads an old cached output.\n\n1.  CPU writes create input values; in noncoherent mode physical memory initially remains zero.\n2.  The input handoff makes those values visible before device consumption.\n3.  Descriptor fields are prepared before ordered publication makes the job available.\n4.  Publication transfers buffer ownership to the device; early host overwrite is rejected before mutation.\n5.  Device output writes update memory. The noncoherent CPU copy still contains the sentinel until its output handoff.\n6.  Completion, output visibility and ownership return precede the consumer read and subsequent buffer reuse.\n\n## Science and assumptions\n\n### Input visibility changes the actual operand\n\n$$\nA_{\\mathrm{device}}=\\begin{cases}A,&\\text{coherent or synchronized},\\\\0,&\\text{noncoherent with omitted input handoff}.\\end{cases}\n$$\n\nThe device reads A when values are coherent or synchronized; it reads the zeroed memory copy when the noncoherent input handoff is omitted.\n\nSymbols and units\n\nA\n\nCPU-populated input matrix\n\ninteger values\n\nAdevice\n\nValues delivered from device-visible memory\n\ninteger values\n\nB follows the same rule in this fixture, so omitting both input handoffs yields a zero output even though the CPU matrices are populated.\n\nAssumptions The initial physical input copies are explicitly zero. This is not a universal prediction of stale cache contents.\n\n### Buffer reuse follows ownership\n\n$$\nG_{\\mathrm{reuse}}(b)=\\mathbf{1}[\\operatorname{owner}(b)=\\mathrm{host}]\n$$\n\nThe reuse gate accepts a buffer only while its declared owner is the host.\n\nSymbols and units\n\nGreuse\n\nPermission to overwrite or reuse in the teaching runtime\n\nBoolean\n\nb\n\nStable buffer identity\n\nobject\n\nowner(b)\n\nCurrent host/device lifetime owner\n\nenum\n\nDevice publication transfers ownership; validated completion and visibility handoff return it. A coherent value does not change this lifetime rule.\n\nAssumptions Single host and device, one in-flight job, explicit whole-buffer ownership; no shared-reader or fine-grained ownership protocol.\n\n## Engineering example\n\nWith default noncoherent mode, omitting input visibility produces \\[\\[0,0\\],\\[0,0\\]\\]. Omitting only output visibility lets memory contain \\[\\[19,22\\],\\[43,50\\]\\], but the consumer reads \\[\\[−777,−777\\],\\[−777,−777\\]\\]. Coherent mode removes these two-copy discrepancies. An early attempt to reuse B is still rejected in either mode; its CPU and memory values remain unchanged and the original job can complete correctly.\n\n## Distinctions and tradeoffs\n\nCoherence makes values visible; it does not grant permission to mutate an in-flight buffer or order every required control action.\n\nCopies and synchronization have costs in real machines, but no such timing is assigned here. Removing a handoff is valid only when a different declared mechanism establishes visibility and lifetime.\n\nAccelerator runtimes overlap transfers and execution. That overlap is useful only when completion and ownership make the next read or overwrite valid.\n\n## Specifications and interfaces\n\nNoncoherent toy\n\nCPU copy and memory copy\n\nNo line size, coherence state machine, cache replacement or ISA barriers are simulated.\n\nSentinel output\n\n−777 in each initial C word\n\nA chosen fixture value, not uninitialized real memory.\n\nOrdering and lifetime\n\nDescriptor then valid; complete before reuse\n\nThese conditions remain necessary with coherent values.\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### Physical C is correct, but the noncoherent CPU output handoff was omitted. What does the fixture consumer read?\n\n1.  The stale sentinel matrix\n2.  The independent mathematical reference\n3.  An automatically corrected version of C\n\nAnswer and reasoning\n\nThe stale sentinel matrix\n\nThe consumer reads its actual CPU-visible copy, which still contains −777 in this fixture.\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-   [OASIS — Virtual I/O Device (VIRTIO) Version 1.3](https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html)\n\n[Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/dma-visibility-ownership-82d7e647892c3b29.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html)\n\n## Continue exploring\n\n### Foundations\n\n-   [Process, physical and device address spaces](https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/)\n-   [L1 and texture cache](https://semiaifoundry.com/learn/atlas/l1-cache/)\n\n### Related lessons\n\n-   [IOMMU permission and tensor identity](https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/)\n-   [Completion, reset and execution epochs](https://semiaifoundry.com/learn/atlas/device-completion-reset-epochs/)\n-   [PCIe and CXL: transport versus memory semantics](https://semiaifoundry.com/learn/atlas/pcie-cxl-semantics/)"
}