CXL 3.1 Improvements

CXL 3.1 is a refinement release, not a new physical layer — it runs on the same PCIe 6.0 PAM4 PHY and the same multi-host coherent switching fabric that CXL 3.0 introduced. What 3.1 adds is finer control over that fabric: Dynamic Capacity Devices (DCD), which let a memory device's capacity be added to or released from a host in small extents without a reboot, and a Trusted Execution Environment Security Protocol (TSP), which lets memory stay protected from a compromised host or fabric manager when it is shared across tenants. Where CXL 3.0's headline was *who* can share a pool coherently, CXL 3.1's headline is *how finely and how safely* that sharing can be managed.

CXL 3.1: Dynamic Capacity Devices and the TEE Security Protocol same PCIe 6.0 PHY and fabric as 3.0 — finer capacity control, added tenant isolation Dynamic Capacity Device (DCD) Fabric Manager issues add-capacity / release-capacity commands to a DCD-capable device Memory Device — Capacity Split into Extents each extent can be assigned, resized, or freed independently No reboot — capacity changes live Host sees capacity appear/disappear as hot-plug-like memory events, not a reset Versus CXL 2.0 / 3.0 pooling Earlier generations reassign a whole device between hosts. DCD reassigns pieces of one device's capacity. TEE Security Protocol (TSP) The problem a shared fabric creates Once memory is pooled across hosts and tenants, a compromised host or fabric manager could, in principle, observe or tamper with another tenant's data. Earlier CXL generations did not define a protocol for this. What TSP adds Encrypts and attests the link between a host's trusted execution environment and the device, so pooled memory can back confidential-computing workloads even when shared infrastructure sits outside the trust boundary. Builds on existing PCIe/CXL link-encryption mechanisms. Still the same physical and fabric layer No new PHY, no new switch topology — 3.1 is a protocol and management refinement on top of 3.0's PCIe 6.0 PAM4 link and multi-tier coherent switching fabric.

Why finer-grained capacity matters once pooling is real. CXL 3.0 made it possible for several hosts to share a coherent memory pool at all; CXL 3.1 addresses what happens once that pool is in production and workloads change size unpredictably. Reassigning a whole physical device between hosts, the unit CXL 2.0 and 3.0 pooling operate in, is coarse — a host that needs 200 GB more memory either gets an entire spare device or gets nothing. A Dynamic Capacity Device lets the fabric manager carve out exactly the extents a host needs and return them later, so the pool's capacity tracks demand rather than device boundaries, with no reboot on either side of the transaction.

Why security had to be addressed explicitly. A pool that only ever served one trust domain didn't need a security protocol beyond ordinary link encryption. Once the same physical memory devices serve multiple hosts and tenants through a shared fabric manager, the fabric manager itself — and any host sharing the pool — becomes a thing a tenant's workload may need protection from, not just a thing it cooperates with. TSP extends CXL's existing link-level protections up to the trusted-execution-environment boundary specifically so that confidential-computing workloads can use pooled CXL memory without trusting every other party on the fabric. Both features are consistent with the shape CXL has taken since 2.0: each generation does not reinvent the physical interconnect, it refines what the fabric is allowed to do with the capacity already on it.

Take CXL 3.1 improvements further

Ask the copilot about this term, or have our engineers assess it against your process.

Ask CFSGPT about this → Request a technical assessment → Open the CFS app