Keep the CXL 2.0 Version 1.0 scope of this topic. CXL.io supplies the I/O discovery/configuration path; .cache and .mem serve different caching and memory-access roles. A discovered Type 3 memory device does not provide device caching of host memory through .cache.
Suppose firmware sees a Type 3 function but software cannot use its capacity. Check each transition below. The invented addresses and capacity are omitted deliberately: a real decoder mapping must come from the platform configuration and device capabilities. Hardware coherence and discovered capacity do not establish software allocation, sharing or synchronisation semantics.
Type discovery is the start of a usable memory path — worked trace
Illustrative isolated example; not measured silicon behaviour.
Layer of readiness | Required evidence | What it does not yet prove |
|---|---|---|
Function discovered | Configuration and capability access works | Memory capacity is mapped and usable |
Device/path configured | Matching supported configuration across the route | Host address space includes the region |
Address decoders agree | Host and device mappings select the intended capacity | The OS has enabled it for the intended use |
OS makes memory available | Region/device lifecycle and allocation state | An application’s concurrent accesses are synchronised |
A .mem path, decoder, resource or OS-enablement problem remains possible. Working .io only establishes the configuration path; it does not certify the memory route.
Scope: Compute Express Link Specification Revision 2.0 Version 1.0 for the device-type model below. Later sharing/fabric features are separate revision-scoped extensions, not assumed capabilities of these examples. CXL.io discovery succeeding does not demonstrate that CXL.cache or CXL.mem is enabled or usable.
In the CXL device-type model used here, CXL.io provides PCIe-based discovery, configuration and I/O, while CXL.cache lets a participating device cache host memory using CXL coherence messages. State the selected CXL revision and device type before assuming which protocols or optional capabilities are active.
CXL.mem lets a host access device-attached memory under the selected device/revision semantics. Platform firmware and software decide address exposure, interleaving and policy; the existence of CXL.mem does not by itself define placement, ownership or software synchronisation.
Use capabilities, not product labels, to classify a CXL device
CXL 2.0 Version 1.0 type model used in this course. A commercial label such as GPU or accelerator does not determine the type by itself.
Type | CXL.io | CXL.cache | CXL.mem |
|---|---|---|---|
Type 1 | Yes | Yes | No |
Type 2 | Yes | Yes | Yes |
Type 3 | Yes | No | Yes |
What to notice
All three types have the .io discovery/configuration path in this scoped model.
Type 3 capacity does not imply device caching of host memory through .cache.
Type 1 has .cache and lacks .mem; Type 3 has .mem and lacks .cache. Confirm actual capabilities rather than inferring the type from a product name.
Choose the protocol from the initiator and memory owner
Intended operation in the CXL 2.0 model | Relevant protocol | Required check |
|---|---|---|
Discover/configure any of these device types | CXL.io | Function and capability discovery; resource configuration. |
Type 1 or Type 2 device caches host memory | CXL.cache | Cache participation, region/access policy and software synchronisation. |
Host accesses Type 2 or Type 3 device memory | CXL.mem | Host/device address-decoder setup, capacity assignment and memory policy. |
Type 3 tries to cache host memory via CXL.cache | Not supported by this device-type model | Do not infer .cache from a working .io or .mem path. |
No. In this CXL 2.0 type model it supplies CXL.io and CXL.mem, not CXL.cache. Enumeration alone also does not establish that a device-memory region has been configured and exposed for host use.
CXL.cache enables a participating device to cache host memory through a defined hardware-coherence protocol. It does not remove software synchronisation, access-control or buffer-ownership requirements, and it is not a universal replacement for DMA mapping or bounce-buffer mechanisms.
CXL.mem provides access to configured device memory in the host physical-address space. A CPU cache hit need not generate a new link transaction; a device-memory access that requires remote service uses the configured memory path. Link, device media, caching, interleaving and traffic affect the measured latency and bandwidth.
CXL revisions differ in link/fabric capabilities, switching, pooling and sharing; name the revision before making a feature claim.
Platform firmware and/or system software must discover and configure the enabled CXL protocols according to the platform boot/runtime model; do not assume one universal pre-boot sequence.
Separate .io, .cache, .mem traffic for debug — different failure modes.