Read first: Read the mechanism and worked trace first
In the scoped CXL 2.0 Type 3 path, capacity becomes useful only when capability, route, decoder mapping and OS region lifecycle agree. A successful configuration read is an early milestone.
Distinguish a discovered device from an enabled region — decision record
Apply the stated local assumptions; record actual platform values before using this as an implementation checklist.
Decision / observation | Required evidence | Consequence |
|---|---|---|
Function enumerated | Type/capability and route evidence | Do not infer .cache support |
Region intended | Host/device decode ranges and supported capacity | Both ends must describe the same usable path |
Memory offered to software | OS region state and intended allocation policy | Application sharing still needs synchronisation |
An enabled consistent memory mapping and the OS’s usable region/allocation state, followed by the intended access test—not configuration discovery alone.
CXL memory can add capacity with latency and bandwidth determined by topology, link, device media, interleaving and load. It may be slower than a given local-memory path, but that is a platform measurement rather than a universal ordering. Placement/tiering is one possible software policy, not a mandatory hot/warm split. Cache-capable devices still need a defined coherence, ownership and synchronisation domain.
CXL switch enables multi-device topologies — each port trains independently.
CXL 2.0 introduced switched memory pooling: capacity can be assigned to different hosts without implying simultaneous coherent sharing of the same location. CXL 3.0 adds memory-sharing and expanded fabric capabilities; state the selected revision before relying on them.
Security: CXL memory regions need platform-appropriate discovery, isolation, access-control, integrity and lifecycle policy; do not reduce system memory semantics to MMIO.