The Same Virtual Address Can Refer to Two Different Process Buffers

SVA shares addresses within a process context

Linux 6.18's x86 Shared Virtual Addressing documentation describes the processor and device using the same virtual addresses. This is useful because application addresses can remain meaningful to the device through supported translation. The described arrangement requires platform IOMMU support, including the applicable ATS and PRI facilities.

Shared therefore describes an agreement between the processor and device about an address space. It does not merge the private address spaces of two applications. A pointer can retain its numeric value when used by the device on behalf of one process while that same number means something else for another process.

The mechanism here is the documented x86 SVA path with ENQCMD; Intel DSA provides a named architecture example below. A supplier's SVA or Shared Virtual Memory label needs documentation for the exact device, platform IOMMU and software combination being offered. These references do not establish support for every GPU or every implementation using those terms.

References: [SV1][SV2]

PASID adds a process selector to the device identity

A PCIe Requester ID, or RID, identifies the device's bus/device/function. Linux describes tracking PASID in addition to that identity when different processes use shared hardware workqueues. PASID means Process Address Space ID. In this Linux path, the IOMMU's PASID entry connects translation to the process page tables used by the CPU.

Intel's Data Streaming Accelerator Architecture Specification, revision 3.0, June 2025, gives the concrete shared-queue mechanism: ENQCMD places the assigned PASID into the submitted descriptor. The device uses PASID for address-translation lookups and page requests. Its shared-queue description identifies PASID as a 20-bit value.

One device identity can therefore accompany work associated with different process address spaces. Identifying the shared queue or device alone leaves that process distinction unresolved. Conversely, counting PASIDs does not count devices, external network ports or physical memory pages.

The 20-bit width describes the context identifier. Multiplying the available identifier values by a page size would invent a memory-capacity relationship. A particular PASID value also needs its actual process association; the number alone does not identify a buffer allocation.

References: [SV1][SV2]

SV-69: one virtual address, two physical destinations

Fictional example SV-69 stipulates two processes, A and B, using one device function with Requester ID 3b:00.0. A has assigned PASID 11 and B has assigned PASID 12; these are decimal context labels. Assume a supported SVA environment, valid process-to-device associations and permitted read access throughout one stated interval. The mappings below are invented premises for reasoning, rather than observations of equipment.

Each process has its own 4096-byte buffer beginning at virtual address 0x4000. A's virtual range 0x4000 through 0x4fff maps to a physical page beginning at 0x14000. B's identical virtual range maps to a different physical page beginning at 0x24000. Both mappings cover one 4 KiB page. Stipulate separate host-memory backing, no shared payload page and no additional payload copies.

Now follow byte offset 0x80, which is 128 bytes. In A, the CPU's virtual address is 0x4080. A device access associated with RID 3b:00.0, PASID 11 and that virtual address reaches physical 0x14080 under the stipulated mapping. In B, virtual address 0x4080 with the same RID but PASID 12 reaches physical 0x24080.

The equal virtual numbers preserve the offset within each process's buffer. The different contexts select different mappings. Each process can have CPU and device references to its own buffer agree, while the two processes' references reach different physical bytes.

There are two separate 4096-byte backing pages, so their combined payload backing is 8192 bytes, or 8 KiB. That total excludes translation structures and other system overhead. Counting one numeric virtual range as one physical allocation would omit B's separate backing. Counting each CPU and device reference as another payload copy would overcount the stipulated buffers.

An address record needs enough context to resolve the claim

Suppose SV-69's supplier note contains only the device identity and virtual address 0x4080. Both process cases fit that note. It cannot choose between physical 0x14080 and 0x24080.

Adding PASID 11 resolves that ambiguity only because SV-69 has also supplied the association with A and a valid mapping for the relevant interval. In an actual offer, a list of RID, PASID and virtual address values still needs the corresponding supported address-space association and mapping evidence before it establishes a physical destination.

An allocation claim needs its own extent too. One resolved byte does not establish a buffer's full size, the backing of every page in it or the presence of another allocation. SV-69 can total 8 KiB because two complete, separate page mappings are explicit assumptions. The repeated address number supplies none of that accounting by itself.

Translation support and mapping lifetime complete the explanation

Intel DSA's section 3.13 names Address Translation Service (ATS) and Page Request Service (PRS). A cached translation can supply the physical address; otherwise the device requests an IOMMU lookup through the appropriate page tables. Section 3.13.2 describes unsuccessful page-fault servicing returning an error. Supporting page requests is not a promise that every supplied address can acquire valid backing.

Linux 6.18 calls its page-request interface PRI. Its process-address-space tagging discussion describes page-table invalidations propagating to the device's translation cache. Keeping translations current addresses which mapping an access uses. It does not define application synchronization between competing reads and writes.

For SV-69, the stated interval lets the reader use the stipulated physical destinations throughout the example. If a later report supplies the same virtual address and PASID without a current mapping, the earlier physical destination is not established for that later report. The address label can remain unchanged while the evidence needed to resolve it has expired.

References: [SV1][SV2]

Match the supplied evidence to the decision

For an address-meaning requirement, ask the platform owner to connect the process address space, assigned PASID, device Requester ID, virtual range, permitted access and relevant interval. Have the supplier name the documentation supporting that arrangement on the offered system. This is a request to explain the supported relationship, rather than a procedure for creating it.

For a memory-capacity requirement, obtain the allocation extent and backing account. SV-69 demonstrates why equal virtual addresses cannot establish shared physical storage. A GPU-local residence requirement needs placement evidence for the named GPU as well; the host-backed example provides none.

For a performance or security requirement, request evidence for that specific outcome and its operating conditions. Correctly selecting a process mapping alone establishes neither a completion-time target nor a complete isolation or identity-verification design.

The related DMA-address article explains the CPU virtual, physical and device-address distinction for one host buffer. The SR-IOV article follows functions to physical ports. The Unified Memory article follows allocation to residence. Use those guides when the offer raises their respective questions alongside process context.

Scope physical preparation once the system is selected

If the selected equipment also needs receiving, preparation or rack assembly, the linked Rack Assembly & Preparation service and project inquiry address that physical work package. Share a nonconfidential equipment summary, delivery state, site, requested physical tasks and handoff records to discuss scope and availability.

The appointed platform and application owners retain SVA support, software implementation and workload acceptance decisions. This article supplies an interpretation of address claims, rather than a field procedure or approval to perform work.