2. CXL协议栈基础：CXL.io、CXL.cache、CXL.mem三大子协议详解

好，咱们直接进入正题。CXL协议栈，说白了就是一套“三合一”的通信方案。它不像传统总线那样只干一件事，而是把三种不同场景的协议揉在了一起。我个人习惯把这三大子协议比作一个团队里的三个角色：一个管后勤（CXL.io），一个管缓存协同（CXL.cache），一个管内存搬运（CXL.mem）。

你想想看，如果让一个协议去干所有事，那效率得多低？CXL的设计思路很清晰：让专业的协议干专业的事。下面我一个一个拆开讲。

2.1 CXL.io：基础通信的“后勤部长”

CXL.io，本质上就是PCIe的“换皮版”。它复用了PCIe的物理层、链路层和事务层。嗯，这里要注意：它并不是完全照搬，而是在PCIe的基础上做了一些扩展。

它负责什么？

• 设备发现与枚举：系统启动时，Host怎么知道插了个什么设备？靠的就是CXL.io的配置空间。
• 中断与错误处理：设备出错了，或者需要通知CPU，走CXL.io的MSI/MSI-X中断。
• DMA与数据传输：传统的PCIe设备做DMA，也是走这条通道。

我在项目中遇到过一个问题：某款加速卡插上去，系统死活认不到。查了半天，发现是CXL.io的链路训练没通过。说白了，就是PCIe那套物理层握手没搞定。所以，如果你搞不定CXL，先回去把PCIe的链路训练搞明白，这是基本功。

2.2 CXL.cache：缓存一致性的“协调员”

这个子协议，是CXL最核心的价值之一。它解决了什么问题？让加速器（比如GPU、FPGA）能直接访问CPU的缓存，并且保持数据一致。

为什么会这样？传统做法里，加速器要数据，得先通过DMA搬到自己的内存里。CPU改了数据，加速器不知道，还得软件去同步。这多麻烦？

CXL.cache允许加速器以“缓存代理”的身份，直接向CPU发起缓存请求。比如：

• Snp（Snoop）：加速器想读一个地址，先发一个监听请求，看看CPU的缓存里有没有最新数据。
• Dto（Data to Owner）：CPU把数据直接推给加速器。

CXL.cache不是必选的。如果你的设备不需要访问CPU缓存，比如一个纯内存扩展设备，那就不需要实现它。

2.3 CXL.mem：内存池化的“搬运工”

这个子协议，是CXL 2.0/3.0里最吸引人的部分。它让设备可以像访问本地内存一样，去访问远端的内存池。

它怎么工作的？

CXL.mem定义了两种主要的事务：

• MemRd（Memory Read）：从远端内存读数据。
• MemWr（Memory Write）：往远端内存写数据。

你想想看，传统架构里，内存是“焊死”在CPU旁边的。有了CXL.mem，内存可以放在一个独立的“内存池”里，多个主机共享。这就是内存池化。

特性	CXL.io	CXL.cache	CXL.mem
是否必选	是	否	否
主要用途	控制、配置、中断	缓存一致性	内存访问
访问目标	设备寄存器	CPU缓存	远端内存
典型延迟	微秒级	纳秒级	百纳秒级

2.4 三大子协议如何协同工作？

光讲理论不够，咱们画个图看看它们怎么配合的。

从这张图你可以看到：

1. CXL.io 是主机和设备之间的“控制通道”。设备插上后，先通过它跟主机打招呼。
2. CXL.cache 是设备向主机缓存发请求的“快车道”。设备想读CPU缓存里的数据，走这条路。
3. CXL.mem 是设备访问远端内存池的“数据通道”。内存扩展器主要靠它。

实际工作中，一个CXL设备可能只实现其中一两个子协议。比如：

• 内存扩展器：只实现CXL.io + CXL.mem。它不需要访问CPU缓存，所以不需要CXL.cache。
• 智能网卡：可能实现CXL.io + CXL.cache。它需要跟CPU做缓存协同，但不需要扩展内存。
• 全功能加速器：三个都实现。既能做缓存协同，又能访问内存池。