PCIe ATS, PRI, and PASID Explained: Device Address Translation and Shared Virtual Memory

A PCIe device that performs DMA ultimately needs addresses that the platform can translate safely into system memory. Modern systems can go beyond a simple model where software pins a buffer and gives the device a fixed I/O address. PCIe defines complementary capabilities that let capable devices participate more directly in address translation and shared virtual-memory designs.

Address Translation Services (ATS) lets a device request translations and cache them locally. Page Request Interface (PRI) gives a device a way to request service when a needed page is not currently available. Process Address Space ID (PASID) tags transactions with an address-space identity so the same device can distinguish work belonging to different processes or contexts. These features are related, but they are not synonyms.

An IOMMU sits on the I/O path and translates device-visible addresses into physical memory addresses according to mappings established by the operating system or hypervisor. That translation is useful for isolation as well as virtualization: a device can be limited to memory the platform has explicitly made accessible to it.

This is separate from PCIe BARs and MMIO. BARs describe address resources used to reach device registers or device-local memory windows. IOMMU translation governs DMA-style accesses from devices toward system memory. A large GPU BAR therefore does not replace an IOMMU, and enabling an IOMMU does not enlarge a BAR.

PCI-SIG defines ATS so a PCIe device can interact with a translation agent in or above the Root Complex, request DMA-address translations, and cache the returned translations in an Address Translation Cache (ATC). The stated purpose is to reduce translation latency and pressure on centralized translation resources.

Caching creates a consistency requirement. If the operating system changes or removes a mapping, stale device-side translations cannot remain usable indefinitely. Platform software and hardware therefore coordinate invalidation so the device's cached view follows authoritative page-table changes. ATS is an optimization and capability framework around translation; it is not permission for a device to bypass memory protection.

A conventional PCIe requester is already identified by its routing identity, but one physical function can serve work from many processes. PASID adds an address-space identifier to eligible PCIe transactions. PCI-SIG defines a 20-bit PASID value used together with the Requester ID to identify the address space associated with an untranslated request.

The PASID value is scoped with the requester rather than being a universal process number on the PCIe fabric. PCI-SIG also makes clear that PASID support is independent of ATS and PRI: a function can support PASID without supporting either of the other two capabilities. Software enables combinations only when the endpoint, translation path, and platform support the required behavior.

Shared virtual-address designs create a practical problem: a process can reference virtual memory whose backing page is not currently resident. Linux documents how ATS and PRI work together in this case. The device first attempts translation; if the mapping cannot currently be supplied because the page is absent, PRI can request that the operating system service the page condition. The device then performs translation again before accessing it.

This resembles CPU demand paging conceptually, but the device is not independently editing CPU page tables. The operating system, IOMMU, driver, and device cooperate through defined interfaces. Correct invalidation and fault handling are essential because a stale or incorrectly authorized translation could target memory that now belongs to something else.

Linux describes Shared Virtual Addressing (SVA) as allowing a processor and device to use the same virtual addresses, avoiding software translation between a CPU pointer and a separate device-visible address. PASID identifies the process context, ATS supplies device-side translation caching, and PRI can support page requests when required.

Windows exposes a related model for GPUs through WDDM's IOMMU support. Microsoft documents a process virtual address space shared by CPU and GPU in that model, with requests carrying a PASID to an IOMMU for translation. The exact software architecture differs by operating system and device class, so PCIe capability support should not be confused with a guarantee that every driver exposes shared virtual memory to applications.

PASID lets a shared device distinguish multiple address spaces without requiring a separate physical PCIe function for every software context. Linux documents PASID as a prerequisite for Shared Virtual Addressing and Scalable I/O Virtualization, while VFIO uses IOMMU mechanisms to preserve isolation when devices are assigned or shared across virtualized workloads.

Accelerators and GPUs benefit from the same broad idea: less software address rewriting and finer-grained memory contexts can make heterogeneous computing models more practical. The important distinction is architectural, not a promise of a fixed speedup. Performance depends on the device, workload, translation behavior, cache hit rates, page faults, driver implementation, and platform.

A useful mental model is: PASID answers 'which address space?', ATS answers 'what translation can the device cache for this address?', and PRI answers 'can the platform make this page available so translation can succeed?'. The IOMMU and operating system remain central to enforcing and maintaining the mappings.

That model also explains why these features often appear together in documentation without being interchangeable. A platform may support only some combinations, and software must negotiate what the complete path can safely provide. For PC users, their presence is most relevant to modern GPU/accelerator memory models, virtualization, device isolation, and advanced I/O—not as a BIOS tweak to chase benchmark points.