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.
CXL ATTACH MODES
Type 1: CXL.io + CXL.cache (smart NIC, accelerator)
Type 2: CXL.io + CXL.cache + CXL.mem (GPU with memory)
Type 3: CXL.io + CXL.mem (memory expander)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 maps device memory into host address space. CPU loads/stores go through the CXL link. Bandwidth and latency depend on link width and device memory technology.
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.
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.