# DMA visibility, ordering and buffer lifetime

Canonical: https://semiaifoundry.com/learn/atlas/dma-visibility-ownership/
Revision: 2026-10-07
Rights: https://semiaifoundry.com/ai-atlas/licenses.html

Executable software · Atlas v1.3.0

# DMA visibility, ordering and buffer lifetime

Separate coherent values, ordered descriptor publication and ownership of in-flight storage.

[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

Learning objectiveDiagnose whether a failed job violated data visibility, descriptor ordering or buffer lifetime, using the actual copies and ownership trace.

## The mechanism

A 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.

1.  CPU writes create input values; in noncoherent mode physical memory initially remains zero.
2.  The input handoff makes those values visible before device consumption.
3.  Descriptor fields are prepared before ordered publication makes the job available.
4.  Publication transfers buffer ownership to the device; early host overwrite is rejected before mutation.
5.  Device output writes update memory. The noncoherent CPU copy still contains the sentinel until its output handoff.
6.  Completion, output visibility and ownership return precede the consumer read and subsequent buffer reuse.

## Science and assumptions

### Input visibility changes the actual operand

$$
A_{\mathrm{device}}=\begin{cases}A,&\text{coherent or synchronized},\\0,&\text{noncoherent with omitted input handoff}.\end{cases}
$$

The device reads A when values are coherent or synchronized; it reads the zeroed memory copy when the noncoherent input handoff is omitted.

Symbols and units

A

CPU-populated input matrix

integer values

Adevice

Values delivered from device-visible memory

integer values

B follows the same rule in this fixture, so omitting both input handoffs yields a zero output even though the CPU matrices are populated.

Assumptions The initial physical input copies are explicitly zero. This is not a universal prediction of stale cache contents.

### Buffer reuse follows ownership

$$
G_{\mathrm{reuse}}(b)=\mathbf{1}[\operatorname{owner}(b)=\mathrm{host}]
$$

The reuse gate accepts a buffer only while its declared owner is the host.

Symbols and units

Greuse

Permission to overwrite or reuse in the teaching runtime

Boolean

b

Stable buffer identity

object

owner(b)

Current host/device lifetime owner

enum

Device publication transfers ownership; validated completion and visibility handoff return it. A coherent value does not change this lifetime rule.

Assumptions Single host and device, one in-flight job, explicit whole-buffer ownership; no shared-reader or fine-grained ownership protocol.

## Engineering example

With 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.

## Distinctions and tradeoffs

Coherence makes values visible; it does not grant permission to mutate an in-flight buffer or order every required control action.

Copies 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.

Accelerator runtimes overlap transfers and execution. That overlap is useful only when completion and ownership make the next read or overwrite valid.

## Specifications and interfaces

Noncoherent toy

CPU copy and memory copy

No line size, coherence state machine, cache replacement or ISA barriers are simulated.

Sentinel output

−777 in each initial C word

A chosen fixture value, not uninitialized real memory.

Ordering and lifetime

Descriptor then valid; complete before reuse

These conditions remain necessary with coherent values.

### Interfaces

Declared runtime inputs Input

Stable matrix job, buffer identities and the stated device/visibility contract

Inspectable accepted or rejected result Output

Event trace, actual buffer values and bounded completion/work ledger

## Check your understanding

### Physical C is correct, but the noncoherent CPU output handoff was omitted. What does the fixture consumer read?

1.  The stale sentinel matrix
2.  The independent mathematical reference
3.  An automatically corrected version of C

Answer and reasoning

The stale sentinel matrix

The consumer reads its actual CPU-visible copy, which still contains −777 in this fixture.

## Evidence and scope

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.

The 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.

## Sources

-   [Linux 6.16 — Dynamic DMA mapping Guide](https://docs.kernel.org/6.16/core-api/dma-api-howto.html)
-   [OASIS — Virtual I/O Device (VIRTIO) Version 1.3](https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.html)

[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)

## Continue exploring

### Foundations

-   [Process, physical and device address spaces](https://semiaifoundry.com/learn/atlas/process-dma-address-spaces/)
-   [L1 and texture cache](https://semiaifoundry.com/learn/atlas/l1-cache/)

### Related lessons

-   [IOMMU permission and tensor identity](https://semiaifoundry.com/learn/atlas/iommu-buffer-identity/)
-   [Completion, reset and execution epochs](https://semiaifoundry.com/learn/atlas/device-completion-reset-epochs/)
-   [PCIe and CXL: transport versus memory semantics](https://semiaifoundry.com/learn/atlas/pcie-cxl-semantics/)