CXL协议栈整体架构：分层模型概述
我个人习惯把CXL协议栈看作是一栋三层的楼房——每一层各司其职，又通过严格定义的接口相互协作。很多初学者容易被CXL的复杂性吓到，觉得它既像PCIe又像内存协议，摸不清脉络。其实，只要理解了分层的思想，整个协议栈的轮廓就清晰了。
CXL协议栈从底向上分为三个逻辑层：CXL.io、CXL.cache 和 CXL.mem。这三层不是平行关系，而是层层堆叠、互为支撑的。其中CXL.io是所有通信的基础，CXL.cache和CXL.mem则是在这个基础上构建的高层服务。
核心要点：CXL的三层架构设计，本质上是把“发现与配置”、“缓存一致性”和“内存访问”这三个不同粒度的通信需求拆开，让每一层都能独立演进和优化。
2.1 CXL.io：设备通信的基础
CXL.io说白了就是PCIe的“马甲”。它复用了PCIe的物理层、链路层和事务层，用于设备发现、配置空间访问、中断处理以及DMA传输。你想想看，要是在一个CXL系统里，主机连设备都认不出来，那上层的一致性协议根本无从谈起。
CXL.io的职责
- 设备枚举与配置：通过PCIe的配置空间机制，操作系统能够发现并初始化CXL设备。
- IO虚拟化：支持SR-IOV（单根IO虚拟化）和ATS（地址转换服务），让多个虚拟机可以安全共享设备。
- 中断与错误处理：MSI/MSI-X中断、AER（高级错误报告）等机制，沿用PCIe生态。
- 控制路径通信：MMIO（内存映射IO）用于主机与设备控制器的寄存器交互。
我在项目中遇到过一件事：某次验证时发现设备无法被主机正确识别，折腾了两天才找到原因——设备端的CXL.io层在链路训练时，对PCIe的Link Status寄存器实现有偏差。你看，虽然CXL.io尽量复用PCIe，但实现细节上还是有坑的。
2.2 CXL.cache：缓存一致性的大脑
CXL.cache层是CXL协议中最具创新性的部分。它允许设备访问并缓存主机内存，同时保持缓存一致性。这听起来简单，但实现起来相当复杂——设备需要知道主机CPU缓存中哪些行处于Modified状态，否则读到脏数据就麻烦了。
CXL.cache的核心机制
- Snoop Filter / Directory：主机端通过目录或监听过滤器跟踪缓存行状态，设备端也需要维护有限的状态机。
- 缓存状态机：设备可以持有MESI或MESIF等状态的缓存行，并通过协议消息与主机同步。
- Back-Invalidation：当主机要修改某缓存行时，可以主动对设备发起Back-Invalidation，让设备丢弃或写回该行。
设计提示：CXL.cache的请求与响应是解耦的，设备可以发出多条未完成的缓存请求，利用流水线提高带宽。但过度pipeline会导致协议死锁——我曾经因为忘了实现Credit返回流控，让整个系统卡死过。
CXL.cache的消息类型主要包括：SnpData（监听数据）、SnpInv（监听无效化）、RdCurr（读取当前值）、WrCurr（写入当前值）等。这些消息的组合，覆盖了设备作为缓存代理的所有行为模式。
| 消息类型 | 方向 | 用途 |
|---|---|---|
| SnpData | 主机 → 设备 | 主机请求设备提供某缓存行数据 |
| SnpInv | 主机 → 设备 | 主机通知设备无效化某缓存行 |
| RdCurr | 设备 → 主机 | 设备读取某内存行的当前一致值 |
| WrCurr | 设备 → 主机 | 设备写回或写入某内存行 |
2.3 CXL.mem：内存访问的高速公路
CXL.mem层定义了设备如何以内存语义访问主机内存——说白了，就是让设备能像CPU读写内存那样，直接Load/Store主机物理地址空间。这层协议把设备从DMA的“先请求、再拷贝”模式中解放出来，延迟可以降低到几十纳秒级别。
CXL.mem的操作类型
- MemRd：读取指定物理地址的数据。支持多个data chunk，比如64B或128B。
- MemWr：写入数据到指定物理地址。可以附带数据部分写入的字节掩码。
- MemSet：内存置零操作，优化零初始化场景。
注意：CXL.mem是“无状态”的——它不要求设备维护任何缓存一致性状态。如果你需要设备缓存主机内存并保持一致性，那得同时使用CXL.cache。我见过不少方案只实现了CXL.mem就想做智能网卡缓存，结果因为一致性保护缺失，跑起来各种诡异的数据错乱。
2.4 三层协议的协作关系
现在我们把三层串起来讲。假设一个场景：一台Type 2设备（比如面向数据库的智能存储控制器）需要从主机内存读取一个数据页并做压缩处理。
- 第一步：主机通过CXL.io枚举设备、分配MMIO空间、配置中断。设备完成初始化。
- 第二步：设备通过CXL.mem发出MemRd请求，直接读取主机内存中的数据页。
- 第三步：如果设备想缓存这个数据页在本地，以备后续重复使用，它会通过CXL.cache协议请求持有该缓存行的“S”状态或“E”状态。
- 第四步：主机端的目录监听到该请求后，可能发起SnpInv让CPU写回或无效化冲突的缓存行，再响应设备。
- 第五步：设备完成压缩后，通过CXL.mem写回结果，或通过CXL.io发起DMA传输。
你看，不同类型的设备对三层的依赖程度各不相同：
| 设备类型 | CXL.io | CXL.cache | CXL.mem | 典型场景 |
|---|---|---|---|---|
| Type 1 (加速器) | 必需 | 可选 | 不支持 | 图计算加速器 |
| Type 2 (带缓存的加速器) | 必需 | 必需 | 可选 | 智能存储 / FPGA |
| Type 3 (内存扩展器) | 必需 | 不支持 | 必需 | CXL内存池 |
实战建议：在做系统架构选型时，先问清楚设备到底需要哪种一致性模型。无缓存的简单设备只用CXL.io和CXL.mem就够了，开发量能省一大半。
最后，我用一张图来总结CXL协议栈的三层分层关系：
这张图把三层的关系和职责一目了然地展示了出来。CXL.io在最底层，支撑一切；CXL.cache和CXL.mem像两个高阶模块，根据设备类型按需选配。搞懂了分层，你才能在系统设计时做出正确的取舍——说白了，不是所有设备都需要完整的三层协议，省一层意味着省下大量的验证时间和芯片面积。