CPU Virtual, Physical and DMA Addresses: One Host Buffer

Linux 6.6 starts with three address spaces

The Linux 6.6 Dynamic DMA mapping Guide opens by separating CPU virtual, CPU physical and device bus addresses. The CPU's virtual-memory system translates virtual addresses to physical addresses. A device performing direct memory access, or DMA, uses its bus address space.

For the guide's host-buffer example, the CPU accesses the buffer through a virtual address. The device's DMA access does not pass through that CPU virtual-memory translation. On a simple system its DMA address can equal the physical address. Elsewhere an input/output memory management unit, or IOMMU, translates the device address to physical backing; host bridges can also produce bus-to-physical mappings.

Keep the address-space name attached to every value. A number presented as a CPU pointer cannot simply be substituted for the device-visible address. Equally, different address-space names do not require different numeric values on every platform.

References: [DA1]

DA-336 gives one 4096-byte buffer three labels

Fictional example DA-336 stipulates one contiguous 4096-byte buffer in host RAM. During the illustrated access interval, its CPU virtual base is 0x40001000, its CPU physical base is 0x100002000 and its device DMA base is 0x00200000. Stipulate a supported, valid mapping of the entire buffer for the named device throughout that interval. These are invented addresses and conditions, not an observed system or instructions for creating a mapping.

The CPU virtual range is 0x40001000 through 0x40001fff. Its physical backing occupies 0x100002000 through 0x100002fff. The device-visible range is 0x00200000 through 0x00200fff. Each range contains exactly 4096 bytes, or 4 KiB, and every base is 4096-byte aligned.

Follow byte offset 0x80, which is 128 bytes from the beginning. The CPU uses virtual address 0x40001080; the backing byte is at physical address 0x100002080; the device uses DMA address 0x00200080. Under the stipulated mappings, those references identify the same payload byte.

Three address labels do not turn the buffer into 12288 bytes of payload. This example contains one 4096-byte backing buffer. Translation describes how an access reaches it; it does not introduce a second payload buffer.

A smaller DMA address can reach a higher physical address

For an unsigned 32-bit byte address, the numeric range is 0 through 4294967295, or 0x00000000 through 0xffffffff. The next address is 2^32 = 4294967296, the 4 GiB boundary. This is an address-range calculation, not a measurement of installed RAM.

DA-336's entire device-visible range fits below that boundary. Its entire physical range lies above it: the physical base 0x100002000 is 4294975488, which is 8192 bytes above 2^32. A device using the stipulated DMA range therefore need not express that larger physical number. The translation connects the two ranges.

This explains why a 32-bit DMA-address capability does not, by itself, limit a server to 4 GiB of installed host RAM. It also does not establish that a particular 32-bit device can use every buffer in a larger-memory server. DA-336 grants one mapping as an assumption. Removing that assumption leaves the device's access to this buffer unestablished.

Linux 6.6 explicitly allows systems whose devices use 32-bit DMA addresses despite wider main-memory addressing. The guide describes a possible translated arrangement, rather than a promise that every platform supplies it.

References: [DA1]

Read address width, valid mapping and capacity separately

A width claim bounds the numeric range a device can express in the stated address space. A mapping claim connects a particular device-visible range to backing memory for an applicable interval. A capacity claim describes how much memory is installed or available under its stated accounting boundary. None supplies the other two answers.

Suppose a fictional server offer lists 256 GiB of installed host RAM and a device with 32-bit DMA addressing. That pair of fields alone proves neither incompatibility nor complete access to the host memory. The first field counts a physical resource; the second describes a device address range. The missing relationship is how the offered system supports access to the buffers the application requires.

An additional DA-336-style explanation can resolve that relationship for one identified buffer. It leaves a requirement covering all application buffers unresolved unless the supplied evidence covers that broader population. Do not enlarge one successful correspondence into a statement about arbitrary physical pages.

Time belongs to the mapping claim too. Linux's opening discussion describes dynamic DMA mappings being kept while used and removed after the transfer. A mapping established for an earlier interval does not establish a later mapping. Ask the supplier and appointed platform owner to explain the supported relationship for the relevant buffers and use period in the exact offered system. A wider address capability alone is still a capability statement.

References: [DA1]

Different addresses and separate copies answer different questions

In DA-336, changing from the CPU label to the device label selects an access path to the same stipulated backing. The physical buffer stays in host RAM. The different numbers establish no additional payload allocation and no movement into GPU-local memory.

A larger application path could also include separate staging and destination buffers. DA-336 says nothing about their presence or absence. Its translated access therefore cannot establish that the complete application path avoids copies, or predict a transfer time. Count separate buffers from the actual path description, rather than count address labels as copies.

The related pinned/pageable-memory article explains a path with distinct staging storage. The Unified Memory article addresses where backing resides. The huge-page article addresses CPU translation coverage. Ordinary DMA access to this host buffer also supplies no compatibility conclusion for a NIC accessing GPU memory; the related GPUDirect topology article owns that separate system question.

Connect the selected equipment to physical preparation

If the selected customer-supplied equipment also needs receiving, preparation or rack assembly, the linked Rack Assembly & Preparation service and project inquiry address that physical package. Share a nonconfidential equipment summary, delivery state, proposed location and requested physical tasks to discuss scope and availability. Memory-system implementation remains with the appointed platform owner. This explanation provides no mapping procedure or work approval.