CXL 1.1 could expand one host's memory. CXL 2.0 is where memory becomes a poolable resource — carved up and handed out across hosts on demand. This is the single most consequential version jump in CXL's history, and it happened without even changing the physical layer. The magic is entirely in one new component: the switch.
Same Physical Layer, Transformative New Structure
A detail that surprises people: CXL 2.0 stays on the same PCIe 5.0 physical layer (32 GT/s) as CXL 1.1. Not a single gigatransfer faster. Everything CXL 2.0 adds is architectural, layered on top of the unchanged 1.1 primitives — which is the clearest possible illustration of Day 6's point that later versions build on the foundation rather than replace it.
The Switch — Breaking the One-Host Barrier
CXL 1.1's defining limit was direct-attach: one device, one host, point-to-point (Day 6). CXL 2.0 introduces the CXL switch, which sits between hosts and devices and can connect multiple hosts to multiple devices. This one component is what makes everything else in CXL 2.0 possible.
SLD vs MLD — The Key to Fine-Grained Pooling
CXL 2.0 defines two ways a device can present itself through a switch:
📦
Single Logical Device (SLD)Presents as one single device to one or more heads. The whole device is allocated as a unit.
🧩
Multi Logical Device (MLD)Can be split into up to 16 Logical Devices (LDs), each with its own LD-ID, each in a separate virtual hierarchy with independent reset control.
The MLD is the star. A single physical memory device can be carved into as many as 16 logical slices, and the switch can hand each slice to a different host, as though it were a separate resource. This is what makes pooling fine-grained: you're not forced to give an entire memory device to one host — you can dole out portions of one device across several hosts, and reassign them as demand shifts.
The Fabric Manager — The Orchestrator
All this switch-and-MLD structure needs a brain to configure it. That's the Fabric Manager (FM) — a control entity that sits external to the CXL switches and configures the CXL hierarchies inside them. The FM decides which LD goes to which host, performs the bind/unbind operations, and manages the pooled topology as workloads come and go.
The mental model: the switch is the physical crossbar; the MLD is the divisible resource; the Fabric Manager is the software that decides the allocation. Together they turn a rack's worth of memory devices into a pool that the FM parcels out to hosts on demand — which is exactly the "no more stranded memory" promise from Day 1, now with the machinery to actually deliver it.
Managed Hot-Plug
A pool is only useful if resources can come and go while the system runs. CXL 2.0 adds hot-plug flows — including Managed Hot Add, used to BIND an SLD, or an individual Logical Device of an MLD, to a host at runtime. This is what lets the Fabric Manager reassign memory dynamically: bind an LD to a host that needs more capacity now, unbind it later and give it to another. Without hot-plug, pooling would be a static, boot-time-only affair; with it, the pool is genuinely elastic.
IDE — Security Arrives on the Link
Day 6 flagged that CXL 1.1 had no link encryption. Once memory traffic can flow through a switch across a pooled, multi-host environment, that's no longer acceptable — so CXL 2.0 introduced IDE (Integrity and Data Encryption):
Provides confidentiality, integrity, and replay protection for data on the CXL link
Encrypts and integrity-protects flits using 256-bit AES in Galois/Counter Mode (AES-GCM) with a 96-bit message authentication code (MAC)
Builds on established security frameworks — DMTF's SPDM (Security Protocol and Data Model) and CMA (Component Measurement and Authentication)
Protects against attackers intercepting point-to-point traffic between CXL ports
The Limit CXL 2.0 Still Had
CXL 2.0 is powerful, but it has one crucial constraint that defines the jump to CXL 3.0 (Day 8). Its switching is limited to directed tree topologies with at most one path between each host and device, and because the switch must track each virtual hierarchy's address maps, scalability is capped at a single switch level. And critically: CXL 2.0 does pooling, not sharing — each LD is owned by one host at a time. Multiple hosts coherently accessing the same region simultaneously, and multi-level non-tree fabrics, are exactly what CXL 3.0 adds next.
🎯 Day 7 Key Takeaways
CXL 2.0 stays on the PCIe 5.0 PHY (32 GT/s) — all its gains are architectural, layered on the CXL 1.1 foundation
The CXL switch connects multiple hosts to multiple devices, breaking 1.1's one-host direct-attach limit
SLD presents as one device; MLD splits into up to 16 Logical Devices (LD-IDs), each assignable to a different host — enabling fine-grained pooling
The Fabric Manager, external to the switch, configures the hierarchies and binds LDs to hosts
Managed Hot Add (BIND) lets LDs be attached to hosts at runtime, making the memory pool elastic
CXL IDE adds link security: 256-bit AES-GCM with a 96-bit MAC, built on DMTF SPDM/CMA
Still pooling (one owner at a time) and single-level tree topology only — sharing and multi-level fabrics come in CXL 3.0
Frequently Asked Questions
What did CXL 2.0 add over CXL 1.1?
CXL 2.0 added switching (a CXL switch between hosts and devices), memory pooling across multiple hosts, hot-plug flows, and CXL IDE link-level integrity and data encryption. It stays on the PCIe 5.0 physical layer at 32 GT/s, but the switch and Multi Logical Devices are what turn memory expansion into a poolable, allocatable resource.
What is the difference between a Single Logical Device and a Multi Logical Device?
A Single Logical Device (SLD) presents itself as a single device to one or more hosts. A Multi Logical Device (MLD) can be split into up to 16 Logical Devices (LDs), each identified by an LD-ID, each belonging to a separate virtual hierarchy with its own reset control, and each handed out by a CXL switch to a particular host as though it were a separate resource. MLD is what enables fine-grained memory pooling.
What is the CXL Fabric Manager?
The Fabric Manager (FM) is a control entity that sits external to the CXL switches and configures the CXL hierarchies inside them — assigning logical devices to hosts, handling bind/unbind operations, and managing the pooled topology. The elaborated switch-and-MLD structure of CXL 2.0 only makes sense when orchestrated by an FM.
How does CXL 2.0 memory pooling work?
A CXL switch sits between multiple hosts and one or more Multi Logical Devices. Because an MLD can be split into up to 16 LDs, the Fabric Manager can allocate different LDs of a single memory device to different hosts, and reassign them over time. This lets a shared memory pool be carved up and handed out per host — but in CXL 2.0 each region is still owned by one host at a time (pooling, not sharing).
What is CXL IDE?
CXL IDE (Integrity and Data Encryption), introduced in CXL 2.0, provides confidentiality, integrity, and replay protection for data on the CXL link. It encrypts and integrity-protects flits using 256-bit AES in Galois/Counter Mode (AES-GCM) with a 96-bit message authentication code, building on DMTF security features like SPDM and CMA to protect against attackers intercepting traffic between CXL ports.