1. 先把 CXL 事务层这件事说清楚

"CXL 事务层"这个说法，我最早是在啃互联协议规范文档时撞见的，当时第一反应是"大概又是把老一代 IO 报文换个壳"。真往下读才发现不是那么回事——它确实借了相当多 PCIe 的骨架，但在一致性语义、流控模型、载荷粒度这几个维度上，跟纯 IO 互联完全是两种设计思路。一句话概括：CXL 事务层定义的是"谁、在什么时刻、以什么语义、访问哪块内存"，以及这些访问之间怎么排序、怎么流控、怎么保证一致。它决定了加速器能不能安全缓存主机数据，决定了内存扩展卡插上去之后主机看到的究竟是一块可寻址内存还是一堆配置寄存器，也决定了整条链路的理论带宽里有多少能真正变成有效载荷。

这篇东西我打算按"是什么—报文长什么样—两条核心路径怎么走—怎么验证—怎么排障"的顺序拆一遍。写给三类人看：正在做设备侧 IP 集成、需要对着规范逐条对齐行为的；做主机侧固件和驱动、要调地址解码和热插拔流程的；还有单纯想把内存池化背后机制搞明白、不想停留在市场宣传话术层面的。零基础也能读下去，但我会默认你知道 PCIe 的基本概念，比如什么是根复合体、什么是配置空间、TLP 大致结构长什么样。

1.1 三层协议栈里，事务层到底站在哪一层

CXL 协议栈切得很清楚：物理层、链路层、事务层，另外还有一个横切模块负责在 IO 流量和缓存一致性流量之间做仲裁。物理层管电气特性和 bit 传输；链路层管组帧、CRC 校验、Ack/Nak 重传；事务层管报文语义、一致性状态机、信用流控和事务排序。

这个分层边界看起来简单，但新手最容易栽的地方是错误到底在哪一层被处理。链路层的 CRC 出错，链路层自己重传，事务层根本感知不到，也不需要感知；而事务层报文头里的 Poison 位表示"这份数据本身内容不可信"，链路层不管这事，它会老老实实把带毒的数据一路送到最终消费者。我在一个项目里见过把 Poison 当成链路层错误直接吞掉的实现，结果错误数据被静默写进了文件系统缓存，定位花了两周多。

还有一点必须先说清楚：CXL 事务层不是一个统一的东西，它是三套子协议的集合。CXL.io、CXL.cache、CXL.mem 三者共享同一个物理链路和链路层，但在事务层的语义、报文格式、甚至承载方式上都不太一样。很多人第一次看规范会疑惑"为什么有的报文用标准 TLP、有的用自定义结构"，原因就在这里。

1.2 三套子协议的分工，别搞混

我把三者的定位整理成一张表，这个表我建议贴在工位上，比翻规范快得多：

CXL.io 是必选能力，任何 CXL 设备都要实现它，否则连枚举都过不去。它基本上就是 PCIe 那一套，配置读写、MSI-X 中断、DMA 全都走这里。真正的创新在 CXL.cache 和 CXL.mem。

按设备形态分，业界习惯叫 Type 1、Type 2、Type 3：只有 CXL.cache 的（比如不带本地内存的加速卡）是 Type 1；CXL.cache 加 CXL.mem 都有的（带本地显存或片上内存的加速器）是 Type 2；只有 CXL.mem 的（纯内存扩展或内存池设备）是 Type 3。这个分类不是学术趣味，它直接决定了事务层要实现的报文集合有多大——Type 1 不需要实现 M2S/S2M 通道，Type 3 不需要实现 D2H 请求那一套，做减法的空间很明确。

1.3 为什么事务层的设计直接决定系统上限

我常跟人打比方：物理层是高速公路，链路层是收费站和路面维护，事务层才是"车上装的是什么货、怎么装卸、装卸顺序怎么排"。路面再宽，如果货车只能装半车、或者装卸要排长队，实际吞吐照样上不去。

CXL 事务层里有两个设计选择，直接卡住了实际性能天花板。第一个是载荷粒度：一个协议帧里到底能塞多少有效数据。这决定了理论带宽能转化出多少。第二个是信用流控的深度：发送方在等回应之前能连续发多少，这决定了长距离、多跳场景下链路会不会空转。

这两个问题我在后面章节会拿具体数字算一遍，先给个结论：早期版本的事务层帧结构，在纯缓存一致性流量下有效载荷效率大概只有一半左右，这个数字对做方案选型的人来说是必须提前知道的，否则容量规划会严重乐观。

2. 报文长什么样：帧结构、槽位与通道划分

理解事务层，绕不开对帧结构的拆解。CXL 在链路层之上传输的单位叫 flit，事务层报文就装在这个 flit 的特定槽位里。槽位怎么分，直接决定了事务层能同时跑几条消息、每条消息能带多少数据。

2.1 早期帧结构里的槽位划分与载荷预算

CXL 1.1 和 2.0 用的帧长度是 528 bit，也就是 66 字节，其中 64 字节是协议载荷，2 字节是 CRC。这 64 字节被切成 4 个 16 字节的槽位，编号 0 到 3。

分配规则是这样的：槽位 0 和槽位 1 用来放协议头，槽位 2 和槽位 3 用来放数据载荷。所以一个帧里最多同时容纳两条 16 字节的头部消息（比如一条请求加一条响应，或者来自不同通道的两条消息），数据载荷上限是 32 字节。

这个 32 字节的上限非常关键。一个标准缓存行是 64 字节，意味着一次完整的缓存行传输至少要跨两个帧。如果是带数据的响应，头部占一个槽位，剩下能塞的只有 32 字节，另一半得等下一帧。这就带来了两个后果：一是帧数量翻倍，二是头部开销占比被放大。

我把这个账算给你看。假设一条链路全部跑缓存一致性流量，每个帧 66 字节里只有 32 字节是真正的数据，剩下 34 字节是头部、CRC 和空槽。有效载荷效率 = 32/66 ≈ 48.5%。这还没算上协议规定的空帧填充和信用返还占用的带宽。实测下来，纯读流量的效率通常落在 42% 到 46% 之间，比理论值还要低一截。

注意：这个效率数字是纯 CXL.cache/CXL.mem 流量的情况。实际链路是 CXL.io 和这两者共享的，仲裁模块会根据配置的权重分配带宽，所以端到端看到的数字还要再打折。

2.2 新版本帧结构的改动与收益

到 CXL 3.0，规范引入了一个可选的 256 字节帧模式。256 字节切成 16 个 16 字节槽位，槽位 0 到 7 放头部（共 128 字节），槽位 8 到 15 放数据（共 128 字节）。

这个改动带来的最直接好处是：128 字节的数据载荷足够装下两个完整缓存行，一次传输就搞定，不用再拆。头部空间也从 32 字节扩到 128 字节，能塞下更多路由信息和端口标识——这是为了支持多级交换和多主机场景。

有效载荷效率变成了 128/256 = 50%，看起来只提升了不到两个点，但实际收益远不止于此。因为帧数量少了，头部重复开销、信用返还频率、链路层重传概率都跟着下降，实测端到端有效带宽提升通常在 1.6 到 1.9 倍之间。物理层速率提升叠加帧效率提升，这才是新版本真正的价值所在。

不过这个 256 字节模式是可选的，需要链路两端协商成功才能启用。我在一个混合组网场景里踩过坑：一端配了强制 256 字节模式，另一端还是默认的 64 字节模式，协商阶段直接卡死，日志里只报了个含糊的链路训练失败。后来把两端配置对齐才通。所以做互通测试的时候，帧模式、物理层速率、编码方式这三项必须逐条对表确认，不能想当然。

2.3 通道划分与信用流控的真实约束

事务层的消息不是一股脑塞进一个队列的，而是按通道分开。CXL.cache 分设备到主机（D2H）和主机到设备（H2D）两个方向，每个方向又分请求、响应、数据三类；CXL.mem 分主机到设备（M2S）和设备到主机（S2M），同样分请求、响应、数据。CXL.mem 还有个重要区分：无数据响应和有数据响应是两条独立的路径，写操作只需要回一个无数据确认，读操作才需要回数据。这个区分对流水线设计影响很大，后面讲 CXL.mem 的时候细说。

每个通道独立跑信用流控。发送方在发消息前必须先拿到信用，收到对方返还的信用才能继续发。信用分两类：头部信用和数据信用。头部信用管"能发多少条消息"，数据信用管"能发多少字节数据"。

这里有个很容易被忽略的坑。信用深度不是随便配的，它必须满足带宽时延积的要求。我给你算一笔账：

假设链路是 x16 配置、单通道速率 32 GT/s，编码开销按 128b/130b 算，原始带宽 64 GB/s，编码后约 63 GB/s，再乘上帧效率得到事务层可用带宽。往返延迟按 300 纳秒估（单跳直连算是乐观值），那么在等第一个信用返还之前，链路上最多能积压的数据量 = 63 GB/s × 300 ns ≈ 18.9 KB。按每帧 32 字节数据算，需要大约 590 个数据信用才能把带宽打满。

实际情况是，设备侧的接收缓冲区根本给不了这么多信用，通常配置在几十到一百多个之间。这就意味着带宽利用率天然受限，具体能跑到多少取决于延迟和信用深度的比值。我在一个两跳交换的场景里实测，跳数从一跳变两跳，延迟从 300 纳秒涨到 700 纳秒左右，带宽直接掉到峰值的 55% 附近。这不是配置错了，是物理规律。

实操心得：做容量规划的时候，别拿理论带宽乘个 0.8 就交差。先确认拓扑跳数，再确认两端信用配置，然后按带宽时延积反推实际能跑多少。我一般会留 30% 的余量给协议开销和突发流量，这样算出来的数字才敢写进方案。

3. CXL.cache 事务层：设备侧一致性怎么落地

CXL.cache 是让加速器直接缓存主机内存的那条路径。它的核心矛盾在于：设备有自己的缓存，主机也有自己的缓存，两边都可能持有同一份数据的副本，谁改了、谁读到的该是哪个版本，必须有一套状态机来管。事务层就是这套状态机的载体。

3.1 设备发起请求的语义选择逻辑

设备要访问主机内存时，发的是 D2H 请求。请求类型有十来种，挑错类型是新手最常见的错误来源。我按用途归类一下：

这张表里最关键的两个是RdOwn 和 RdOwnNoData。前者是"我要读也要改"，后者是"我只要所有权，数据不用给我"。如果你的场景是整行覆盖写，用 RdOwnNoData 能省掉一次 64 字节的数据传输，直接进写流程。我在一个做整块数据初始化的场景里把 RdOwn 换成 RdOwnNoData，带宽利用率提升了约 18%，效果非常明显。

反过来，用 RdCurr 读完直接改是最典型的错误。RdCurr 拿到的状态是共享的，你改了之后主机侧不知道，别的缓存副本也没失效，一致性直接崩。表现形式是偶发数据错乱，压测跑几个小时才复现一次，排查成本极高。记住一条铁律：要写就必须拿独占状态，拿不到就先升级状态再写。

3.2 主机侧探询路径与过滤器的作用

方向反过来，主机要访问某块内存时，得先确认设备缓存里有没有副本。这就是 H2D 方向的探询消息，作用是"问一下设备：你这行数据现在是什么状态，如果有脏数据请给我"。

探询消息也分几种：只取数据不改状态的、取数据并降级的、取数据并使副本无效的。设备收到后要回一条响应，响应里带上"我原来是什么状态、现在变成什么状态"，如果有脏数据还要附带数据本身。

这里有个性能攸关的设计点：探询过滤器。如果主机侧不维护任何目录信息，每次访问内存都得向总线上所有设备广播探询，设备一多探询流量就爆炸。探询过滤器本质上是个目录，记录"哪一行可能被哪个设备缓存了"，命中才发探询，不命中直接走本地内存。

过滤器的容量和相联度直接决定了漏探询率。我在一个八设备组网的场景里做过对比：过滤器容量配成缓存容量的 1/8 时，漏探询率大概 12%，总线流量里探询占了三成；把容量提到 1/4 之后，漏探询率降到 3% 以下，有效带宽回升约 22%。这个投入产出比非常高，做系统方案的时候建议优先把过滤器容量拉满，代价只是几 MB 的片上 SRAM。

还有一个容易忽略的细节：探询是阻塞式还是非阻塞式。阻塞式意味着一条探询没回来之前不能发下一条，简单但吞吐上不去；非阻塞式可以并发多条，但需要更多的跟踪表项。我一般建议至少支持 16 条并发探询，这个深度在大多数场景下够用，再往上收益递减明显。

3.3 状态迁移里几个反复踩的坑

一致性状态机本身不复杂，四个状态来回转，但落地实现的时候有几个坑反复出现。

第一个是状态降级时的数据回写时机。设备持有独占状态且数据是脏的，收到降级请求时，必须把数据回写出去再降级，不能先降级再慢慢回写。顺序反了就会出现一个窗口期，主机读到的是旧数据。这个 bug 在功能仿真里几乎测不出来，得上形式化验证或者长时间随机压力测试。

第二个是驱逐和探询的冲突。设备正在驱逐某行（发 DirtyEvict），同时主机发来对该行的探询，两条消息交叉。规范里对这种情况有明确的处理顺序要求，实现时如果只用一个队列处理，很容易死锁。我的做法是驱逐和探询走不同的处理路径，用独立的资源池，代价是面积增加，但省下的调试时间远超这点面积。

第三个是部分写的处理。设备只改了缓存行的一半，剩下的一半还是旧的，这时候不能简单地把整行标脏。有两种做法：一是先把整行读进来改成独占再改（读改写），二是用带长度的部分写报文直接发出去让主机侧合并。前者延迟高但简单，后者效率高但要主机侧支持。我在低延迟场景选前者，在吞吐优先场景选后者，没有一个放之四海皆准的答案，得看你的负载特征。

注意：一致性相关的验证一定要做随机延迟注入。我见过太多设计在零延迟的理想环境下完美运行，一加上真实的链路延迟和乱序就崩。验证环境里把延迟范围设成 50 到 800 纳秒随机，能提前暴露八成以上的时序问题。

4. CXL.mem 事务层：主机访问设备内存的路径

CXL.mem 是另一个方向：主机把设备上的内存当成自己地址空间的一部分来访问。这条路径的一致性模型比 CXL.cache 简单——内存归主机管，设备只是提供存储介质，不存在设备侧缓存副本的问题。简单归简单，细节一点不少。

4.1 读写与失效三类报文的语义拆解

主机发起的内存请求主要有这么几类：

这里最重要的区分是有数据响应和无数据响应两条独立路径。写操作只回一个确认，不带数据；读操作才回数据。这个设计的好处是写操作的响应非常轻量，不会占用数据通道的带宽。坏处是实现的时候要维护两套跟踪机制，而且两条路径的完成顺序不保证。

我遇到过的一个典型问题是：驱动层假设"写操作完成后紧接着的读一定能读到新值"，但硬件层面写确认和后续读可能走不同路径，中间有重排窗口。正确做法是在写和读之间插入一个内存屏障类的操作，或者依赖协议规定的同地址排序规则。同地址的读写是有序的，不同地址没有，这条规则要刻在脑子里。

MemWrPtl部分写是个特殊存在。设备侧收到之后不能直接写，得先读出整行、合并、再写回。这个读改写过程对设备侧的存储控制器压力不小，尤其是小粒度随机写。我在一个场景里测过，全是 8 字节随机写的时候，设备侧实际的内存带宽消耗是主机侧请求带宽的 2.4 倍，因为每次都要读一整行。如果你的负载是小粒度随机写为主，得提前跟设备厂商确认他们的合并策略和缓冲区深度，不然性能会非常难看。

4.2 地址映射与解码器的设计要点

主机怎么知道哪段地址该发到 CXL 设备上？靠地址解码器。主机在枚举阶段通过 CXL.io 读设备的能力寄存器，知道设备有多大容量、支持什么交错粒度，然后在自己地址空间里划出一块区域映射过去。

交错粒度这个参数值得单独说。它指的是多个设备之间怎么瓜分连续的地址空间，常见粒度从 256 字节到 16 KB。粒度越小，多设备之间的负载越均衡，但每个请求的有效载荷占比越低——256 字节粒度意味着每 256 字节就换一个设备，而你的一次传输可能是 64 字节，那所有请求都落在同一个设备上，交错等于没做。

我一般建议交错粒度至少是典型传输大小的 4 倍以上。如果业务以 64 字节缓存行访问为主，粒度选 512 字节或 1 KB 比较合适；如果以大块顺序传输为主，粒度可以放大到 4 KB，减少地址译码开销。

解码器还有个绕不开的问题是热插拔时的重映射。设备拔掉之后，映射到它的那段地址必须从可用地址池里摘掉，否则后续分配会拿到一段悬空地址，访问直接报错。这个过程涉及和操作系统内存管理器的联动，顺序搞错了会触发内核 panic。我的经验是：先让上层停止向该区域分配新内存，等已有分配全部回收，再更新解码器配置，三步走，中间任何一步都不能跳。

实操心得：调试地址映射问题时，先在设备侧把收到的请求地址打印出来，跟主机侧发出的地址列表逐个比对。我遇到过主机侧地址是 0x1000_0000 对齐、设备侧收到的是 0x0FFF_F000 的情况，差了 4 KB，最后查出来是解码器基址寄存器的最低几位被当成使能位误写了。这种问题看波形一小时能定位，纯靠猜能猜一周。

4.3 新版本的反向失效与共享内存

CXL 3.0 给 CXL.mem 加了几个重量级特性，其中一个叫反向失效。之前的模型里，只有主机能让设备的缓存失效，设备没办法反向操作。支持反向失效之后，设备可以主动通知主机"你那边的某行数据我要改了，请失效"，这就为真正的多主机共享内存打下了基础。

共享内存的价值在于：多个计算节点访问同一份数据，不用来回拷贝。做分布式训练、内存数据库这类场景，省掉的拷贝开销非常可观。但代价是一致性维护的复杂度上了一个台阶——从"一主多从"变成了"多主对等"，失效消息可能来自任意方向，死锁和活锁的可能性都增加了。

实现层面我建议先把反向失效关掉跑通基础路径，等基础读写稳定了再逐条打开。我在一个共享内存的验证环境里试过一上来就全开，结果各种交叉死锁，日志根本看不懂。后来拆成三步：单主机无共享、双主机只读共享、双主机读写共享，一步一验证，问题定位效率高得多。

还有一个特性是端口级路由。早期的帧头里没有足够的路由信息，多级交换只能靠地址映射来间接定位。新版本在帧头里直接带了端口标识，交换机能按端口转发，跳数可以堆得更多，拓扑也更灵活。这个特性对做大规模内存池化的场景是刚需，但对单机直连的场景意义不大，按需启用就行，不用为了追新而追新。

5. 实操：从零跑通一次事务层行为观测

纸上谈兵到此为止，下面是我实际跑通的一套验证流程，从环境搭建到抓一条完整的事务流。这套流程不依赖任何特定厂商的工具链，大方向是一致的。

5.1 搭建最小可用验证环境

环境分三层：主机侧模型、链路模型、设备侧模型。

主机侧我一般用一个支持 CXL 设备模型的开源虚拟机监控器来跑，好处是能完整走一遍枚举流程，配置空间读写、地址解码器编程、驱动加载都是真的，不是 mock 出来的。设备侧用一个自研的行为模型，先实现最小功能集：CXL.io 的配置空间、CXL.mem 的读写通道，CXL.cache 先不实现。链路模型负责加延迟和注入错误。

最小功能集的验证顺序我总结成四步：

1. 枚举通：主机能发现设备，读到正确的设备类型、容量、支持的协议版本。
2. 地址映射通：主机能把一段地址映射到设备上，写进去读出来一致。
3. 中断通：设备能通过 CXL.io 发中断，主机能收到。
4. 热插拔通：设备能在运行时插拔，地址空间正确回收和重新分配。

这四步任何一步不通，后面的验证都没有意义。我见过跳过第二步直接上一致性的，出问题的时候根本分不清是映射错了还是一致性错了。

环境搭好之后先跑一个零延迟基线，确认功能正确；然后逐步加延迟到 100、300、800 纳秒，观察行为变化。延迟注入的粒度建议按 50 纳秒步进，太粗会漏掉边界情况。

5.2 抓一条读请求的完整生命周期

下面这条路径是我在验证环境里抓到的真实事务流，简化之后展示出来：

[主机侧] 应用发起 64B 读 → 缓存未命中 → 内存控制器生成 MemRd 请求 → 事务层打包：M2S 通道，请求头 16B，无数据载荷 → 链路层组帧：占用槽位 0，槽位 1-3 空闲 → 物理层发出 [链路] → 链路延迟 180ns → 交换节点转发（两跳拓扑，第二跳再 190ns） [设备侧] → 链路层解帧、校验 CRC → 事务层解析：MemRd，地址 0x2A00_0040，长度 64B → 送存储控制器，读 DRAM，耗时 45ns → 生成有数据响应：S2M 通道，响应头 16B + 数据 32B （第一帧只带 32B，因为帧的数据槽位只有 32B） → 第二帧再带 32B，完成 64B 传输 [回程] → 两跳延迟 370ns 返回主机 → 主机事务层组装两帧数据，凑齐 64B → 送缓存，完成一次填充

这里面有几个观察点值得说道。

第一，64 字节的读要用两帧带数据回传。这就是前面说的载荷粒度限制的直接体现。如果是带 256 字节帧模式的环境，一帧就搞定，往返延迟虽然一样，但链路上的帧数量减半，拥塞概率和重传概率都下降。

第二，头部开销在整条路径上被重复支付。请求一次头部、响应两次头部，一共三个 16 字节头部承载 64 字节数据，头部占比 43%。这个比例在大块传输的时候会好看很多，所以 CXL.mem 更适合大块顺序访问，小粒度随机访问的效率天生就吃亏。

第三，设备侧的存储控制器延迟占比不高。整条路径 415 纳秒里，DRAM 只占 45 纳秒，剩下全是链路和交换。这解释了一个现象：换更快的存储介质对整体延迟改善有限，减少跳数才是王道。我在一个场景里把存储介质从普通内存换成低延迟内存，端到端延迟只降了 8%；把拓扑从两跳改成直连，延迟直接降了 45%。

5.3 带宽、信用和利用率的账怎么算

做方案的人最关心的就是这三个数。我把计算方法整理成一套可复用的流程。

第一步，算物理带宽。通道速率乘以位宽，除以 8 得字节带宽，再乘编码效率。以 x16、单通道 32 GT/s 为例：32 × 16 ÷ 8 = 64 GB/s，编码效率 128/130 约 98.5%，得 63 GB/s。

第二步，算事务层可用带宽。纯缓存一致性流量下，帧效率是 32/66，得约 30.5 GB/s。混合流量按实际比例加权。

第三步，算信用约束下的实际带宽。用带宽时延积除以信用深度，得到"信用周转一次能传多少数据"，再除以往返延迟就是实际吞吐上限。

我拿一组实测数据做个对照，你可以拿去估自己的场景：

这张表的结论很直白：信用深度翻倍，两跳场景的带宽利用率从 41% 拉到 64%，提升幅度远超优化任何其他环节。如果只能在有限的改动里做一件事，优先加深信用。

写操作的利用率普遍低于读，因为写虽然只回确认，但确认也是要占头部信用的，而且写的流水线更难排满。我在一个写密集场景里加了个写合并缓冲区，把相邻的小写合并成大块再发出去，利用率从 52% 提到了 73%。这个优化的前提是你的业务负载本身有空间局部性，否则合并命中率低，白搭。

注意：上面所有数字都是在特定配置下测的，换硬件的绝对值会变，但相对趋势是稳的：跳数的影响大于信用深度，信用深度的影响大于帧模式，帧模式的影响大于物理层速率的小幅提升。做优化的时候按这个优先级排，不容易走弯路。

6. 常见问题与排查实录

这一节是我这些年攒下来的问题清单，按症状分类，每条都带排查路径。

6.1 性能断崖类问题

症状：带宽只有理论值的一半左右，而且怎么调都不涨。

先别急着怀疑硬件。第一步确认帧效率，纯缓存一致性流量本来就只有 48% 左右的载荷效率，你算出来的"理论值"如果没扣这一层，那说明是算错了不是跑错了。第二步确认收发两端协商的帧模式是否一致，一端 64 字节一端 256 字节的情况我见过不止一次，协商失败但链路能通，带宽砍半。第三步看信用配置，用带宽时延积反推需要的深度，对比实际配置。

症状：延迟随负载上升而暴涨，轻载时正常。

典型的拥塞问题。检查信用返还是不是被低优先级流量阻塞了，请求和响应有没有共用同一个队列。我遇到过响应通道和请求通道抢同一组缓冲区的情况，轻载看不出来，重载时响应被压住，发送方等不到信用返还，形成正反馈雪崩。解决办法是把请求、响应、数据的信用池彻底分开，物理上隔离，不给互相影响的机会。

症状：单设备性能正常，多设备组网后性能塌陷。

大概率是探询风暴。检查探询过滤器是否启用、容量是否够、相联度是否匹配。另外确认交错粒度是否合理，粒度太小时每个设备分到的连续地址段太短，预取和合并全部失效。我在一个四设备场景里把交错粒度从 256 字节调到 2 KB，整体吞吐提升了 60%。

6.2 一致性与数据错乱类问题

症状：偶发数据不一致，压测几小时才复现一次。

三个方向排查。一是状态迁移的原子性，尤其是降级和回写的顺序，用形式化工具把状态机跑一遍穷举，比随机测试高效得多。二是部分写的合并逻辑，确认设备侧和主机侧对"同一行被两个来源同时改"的处理规则理解一致。三是 Poison 位的传播，确认带毒数据不会被静默消费。

症状：热插拔之后访问该区域直接崩。

按顺序查：地址空间是否已经回收、解码器配置是否已经更新、已有的缓存行是否已经全部回写或失效。这三步任何一步没做完就允许新访问，都会崩。我的做法是在驱动里加一个状态标记，插拔期间把所有新请求挡在门外，等清理完成再放行。

症状：多主机共享场景下出现死锁。

先确认反向失效的启用范围，能不能收敛到只对共享区域启用。再检查两侧的失效请求是否有超时机制，没有超时的话一旦丢包就永久卡死。最后看跟踪表项的数量，表项耗尽时请求排队，排队的请求又占着资源不释放，这是最常见的死锁形态。

6.3 常见问题速查表

7. 最后分享几条踩出来的经验

做这类协议栈的东西，我最大的体会是别急着上全功能。CXL 事务层看着报文类型多，其实绝大部分场景只会用到其中一小部分。我建议按"配置能通、单地址读写通、多地址并发通、多设备共享通"这个顺序推进，每步都跑稳定了再往下走。跳过前面的步骤直接冲复杂特性，出问题的时候你连是哪个环节错了都判断不了。

第二个体会是延迟和带宽要分开看。很多方案汇报里只写带宽数字，实际业务卡在延迟上。存储类业务尤其明显，带宽够但延迟高，尾延迟直接爆炸。做验证的时候一定要把延迟分布（不只是平均值）拉出来看，P99 和 P999 才是真实体验。

第三个是别信标称值。设备厂商给的容量、带宽、延迟都是理想条件下的数据，实际装到系统里，协议开销、多跳转发、软件栈损耗叠上去，能到七成就算不错。方案里留 30% 余量不是保守，是及格线。

最后一条，验证环境里一定要注入错误。CRC 错误、Poison 位、超时、乱序、信用丢失，这些在实验室里几乎不会自然发生，但现场一定会遇到。提前在环境里把这些都打一遍，比在现场熬夜定位强一百倍。