PCIe PASID Lets One Device Carry Multiple Address-Space Contexts

A PCIe function normally has a Requester ID derived from its bus, device, and function identity. That identifier tells platform components which function issued a transaction, but it is too coarse when one device serves work from several process address spaces at the same time.

Process Address Space ID (PASID) adds another identity field to the transaction path. A PASID can select an address-space context beneath the same device function, allowing the IOMMU to distinguish memory traffic that belongs to different processes without requiring a separate PCIe function for each one.

The important property is multiplexing. PASID does not replace the Requester ID and does not perform address translation by itself. It supplies context used by translation and protection machinery.

Requester ID identifies the function, PASID refines the context

A PCIe Requester ID identifies the function that originates a transaction. If a single accelerator handles work for process A and process B, both streams can still carry the same Requester ID because both come from the same function.

PASID provides a finer selector:

Requester ID 03:00.0
    |
    +-- PASID 41  -> address space A
    |
    +-- PASID 92  -> address space B

The numeric values are identifiers, not addresses. Platform software establishes the association between a PASID and the translation context that should apply to transactions carrying that value.

This separation lets hardware queues or work submissions share a physical function while retaining distinct memory contexts. The exact queue architecture remains device-specific; PASID only supplies the transaction context needed by the platform.

Shared Virtual Addressing ties PASID to process memory

Linux Shared Virtual Addressing (SVA) allows a capable device and a process to operate with the same virtual addresses. On supported x86 systems, Linux allocates a PASID for a process using SVA and configures the IOMMU so transactions carrying that PASID resolve through the process address-space context.

That changes the interface between software and an accelerator. A work descriptor can contain application virtual addresses rather than a separate device-specific DMA address namespace, provided the complete SVA path is active.

PASID is one part of that path. The platform also needs suitable IOMMU support, and the device may rely on PCIe Address Translation Services (ATS) and Page Request Interface (PRI) for translation caching and page-fault-related service.

work submission
    |
    | process context
    v
PASID-tagged device transaction
    |
    v
IOMMU translation context
    |
    v
process-backed memory

A PASID value alone does not make an arbitrary user pointer valid for DMA. The operating system must bind the device to the address space and establish the required translation state.

PASID and ATS solve separate problems

ATS permits a device to request translations and cache translated address information locally. PASID identifies the address-space context associated with a transaction. These mechanisms often appear together in SVA systems, but their roles are distinct.

A device can need PASID because several address spaces share one function. It can need ATS because repeated translation requests would otherwise remain on the IOMMU path. When both are active, cached translation state must remain associated with the correct address-space context.

This also makes invalidation scope important. If a process mapping changes, stale translation state for that context must be retired according to the platform, IOMMU, and PCIe protocols. An invalidation for one address space must not be treated as permission to discard or reuse unrelated translation state without the applicable rules.

PASID lifetime follows address-space lifetime

An identifier that selects a translation context cannot be reused carelessly. If old device work can still carry PASID X while software has already reassigned X to another address space, delayed traffic could be interpreted under the new context.

The operating system and IOMMU therefore manage PASID allocation, binding, invalidation, and release as a lifecycle rather than as a simple integer assignment. Linux documents process-level PASID handling for its x86 SVA path, including removal across address-space-changing operations such as fork() and exec() in that implementation.

The precise lifecycle is platform-specific, but the invariant is broader: reuse must occur only after old transactions and derived translation state can no longer be interpreted as belonging to the previous context.

This is similar to other tagged-resource designs. The tag is useful only while every component agrees on what the tag names.

Shared work queues make the distinction visible

A shared hardware work queue can accept commands from multiple processes without dedicating a separate hardware queue or PCIe function to each process. The device still needs a way to associate resulting memory traffic with the process that submitted the work.

PASID provides that association on supported designs. Linux’s x86 SVA documentation describes shared work queues in this model and notes that device DMA requests carry the same process PASID used for the submission context.

That arrangement separates two resources that are easy to conflate:

hardware queue identity != process address-space identity

Many processes may share a queue while retaining separate PASIDs. Conversely, queue allocation policy is a device-driver concern and is not defined by PASID semantics.

PASID increases context density, not isolation by itself

PASID can let one function represent many address-space contexts, but the identifier is not a security boundary on its own. Isolation comes from the translation and permission state selected by that identifier, plus correct device, IOMMU, kernel, and firmware behavior.

A device that emits an incorrect PASID can direct a transaction at the wrong configured context if the surrounding hardware permits it. Platform policy therefore matters when deciding which devices may use PASID-based features and how those devices are isolated or assigned.

The practical architectural effect is precise: PASID adds process-scale context beneath a PCIe function identity. That extra tag lets shared devices participate in memory translation for several address spaces without multiplying physical functions. The benefit and the correctness burden come from the same fact: more translation contexts can coexist on one transaction source, so their binding, invalidation, and lifetime must remain unambiguous.