【CXL协议-事务层之CXL.io（3）】

3.1 CXL.io

CXL.io 为 I/O 设备提供非一致的加载/存储接口。 图 14 显示了 CXL.io 事务层在 Flex Bus 分层结构中的位置。 交易类型、交易数据包格式、基于信用的流量控制、虚拟通道管理和交易排序规则遵循PCIe定义； 请参阅
有关详细信息，请参阅 PCI Express 基本规范的“事务层规范”一章。 本章重点介绍 CXL.io 使用的值得注意的 PCIe 操作模式或功能。

3.1.1 CXL.io 端点

CXL 设备需要支持在 CXL 1.1 和 CXL 2.0 模式下运行。 CXL 备用协议协商决定操作模式。 当链路配置为在 CXL 1.1 模式下运行时，CXL.io 端点必须作为 PCIe RCiEP 暴露给软件，而当配置为在 CXL 2.0 模式下运行时，必须暴露给软件，软件作为 PCI Express 端点。 更多详情请参阅 PCIe 5.0 基本规范。 请参阅第 9.12 节。
参与 CXL 协议的 CXL.io 端点函数不得生成 INTx 消息。 非 CXL 函数映射 DVSEC（第 8.1.4 节）枚举不参与 CXL.cache 或 CXL.mem 的函数。 即使不推荐，这些非 CXL 函数也可以生成 INTx 消息。
MLD 组件的 CXL.io 端点功能（包括非 CXL 功能）不允许生成 INTx 消息。

3.1.2 CXL 电源管理 VDM 格式

CXL 电源管理消息作为 PCIe 供应商定义的类型 0 发送
具有 4 DW 数据负载的消息。 其中包括 PMREQ、PMRSP 和 PMGO
消息。 图 15 提供了 CXL PM VDM 消息的格式。 下列
这些消息的特征是：
• Fmt 和Type 字段被设置为指示带有数据的消息。 所有消息都使用路由
“在接收方本地终止”。 消息代码设置为供应商定义的类型 0。
• 供应商ID 字段设置为1E98h1。
• 消息头的字节15 包含VDM 代码并设置为“CXL PM 消息”的值。 （68小时）
• 4 DW 数据有效负载包含 CXL PM 逻辑操作码（例如，PMREQ、GPF）以及与 CXL PM 消息相关的任何其他信息。 数据有效负载内字段的详细信息如表 5 所示。
如果 CXL 组件接收到有毒的 PM VDM (EP=1)，则接收方应丢弃此类消息。 由于接收方在收到此类 VDM 后能够继续正常操作，因此它应将此事件视为建议性非致命错误。
如果接收器电源管理单元 (PMU) 不理解 PM VDM 有效负载的内容，它应默默地丢弃该消息，并且不应发出不可纠正的错误信号。
图 15. CXL 电源管理消息数据包格式
表 5. CXL 电源管理消息——数据有效负载字段定义

3.1.2.1 信用和 PM 初始化

PM 积分和初始化过程是链接本地的。 图 16 说明了使用 PM2IP.CREDIT_RTN 和 PM2IP.AGENT_INFO 消息来初始化电源管理消息传递协议，旨在促进下行端口 PMU 和上行端口 PMU 之间的通信。 CXL交换机为PM提供聚合功能
消息如第 9.1.2.1 节中所述。
GPF 消息不需要信用，并且接收方不应生成 CREDIT_RTN 来响应 GPF 消息。
Credit and PM Initialization:

PM Credits：这是一种流量控制机制，确保电源管理单元 (PMU) 之间的通信不会超过接收方的处理能力。发送方必须拥有足够的信用（Credits）才能发送消息。
Initialization Process：初始化过程是本地链路的，意味着它是针对连接两个PMU的特定链路进行的。它涉及特定的消息交换，用来建立电源管理通信协议。
使用PM2IP.CREDIT_RTN和PM2IP.AGENT_INFO消息:
PM2IP.CREDIT_RTN：这是一种信用返回消息，用于通知发送方已成功接收消息，并且可以再次发送更多消息。
PM2IP.AGENT_INFO：这是一种代理信息消息，用于在初始化过程中交换PMU之间的配置和状态信息。
CXL交换机的聚合功能:
CXL交换机具有聚合电源管理消息的功能，这意味着它可以将来自不同端口的电源管理消息进行汇总，以简化电源管理协议的通信。
GPF消息和信用返回:
GPF (Generic Protocol Flow) 消息：这些消息不要求信用，因为它们通常用于非流量控制的目的，例如系统级别的管理和控制信号。
接收方不应对GPF消息生成CREDIT_RTN响应，因为这些消息不受信用机制的限制。
Power Management Credits and Initialization 过程:
在CXL.io中，电源管理初始化过程通常涉及以下步骤：
链路建立后，下游和上游PMU之间交换AGENT_INFO消息，以传达电源管理能力和配置参数。
随后，PMU之间交换CREDIT_RTN消息，以建立信用计数和确认消息传输的准备就绪。
一旦建立了信用体系和电源管理通信协议，PMU就可以开始交换用于电源管理的其他消息，并据此调整功率状态。
这个过程确保了PMU之间的同步和一致性，使得电源管理操作可以根据系统的实时需求进行调整，从而在满足性能要求的同时优化能耗。

CXL 上行端口 PMU 必须能够接收和处理 CREDIT_RTN 消息，而不依赖于任何其他 PM2IP 消息。 此外，CREDIT_RTN 消息不使用信用。 CREDIT_RTN消息用于初始化和更新每一侧的TX信用，以便可以适当地管理流量控制。
在 PM 初始化期间的第一个 CREDIT_RTN 消息期间，通过 NUM_CREDITS 字段发送的信用表示 CREDIT_RTN 的发起者可以从另一端接收的依赖于信用的 PM 消息的数量。 在后续的 CREDIT_RTN 消息期间，NUM_CREDITS 字段表示自同一方向的最后一个 CREDIT_RTN 消息以来释放的 PM 信用数。 下行端口 PMU 还使用第一个 CREDIT_RTN 消息将 PM_AGENT_ID 分配给上行端口 PMU。 该 ID 通过 CREDIT_RTN 消息中的 TARGET_AGENT_ID 字段进行传达。 在发起任何 IP2PM 消息之前，上游端口 PMU 必须等待来自下游端口 PMU 的 CREDIT_RTN 消息。
上行端口 PMU 必须支持至少一个信用，其中信用意味着有足够的缓冲来接收具有 128 位有效负载的 PM2IP 消息。
信用初始化后，上行端口 PMU 必须等待来自下行端口 PMU 的 AGENT_INFO 消息。 该消息包含下游端口PMU的PM协议的CAPABILITY_VECTOR。 上游端口 PMU 必须将其 CAPABILITY_VECTOR 发送到下游端口 PMU，以响应来自下游端口 PMU 的 AGENT_INFO 请求。 当存在不匹配时，下游端口 PMU 可以实现兼容模式以与能力较差的上游端口 PMU 一起工作。 或者，如果下游端口 PMU 不知道如何与能力较差的上游端口 PMU 一起可靠地运行，则它可能会记录不匹配并报告错误。
上游端口 PMU 期望在收到消息后立即恢复下游端口 PMU 的信用。 如果下游端口 PMU 提供了多个信用，则它可以有多个正在传输的消息。 及时释放信用将为延迟敏感的流提供更好的性能。
以下列表总结了上行端口 PMU 必须遵循的规则。
• 上行端口PMU 在启动任何IP2PM 消息之前必须等待接收PM2IP.CREDIT_RTN 消息。
• 上游端口PMU 必须从从下游端口PMU 接收到的第一条PM2IP 消息中提取TARGET_AGENT_ID 字段，并将其用作未来消息中的PM_AGENT_ID。
• 上游端口PMU 必须实现足够的资源来接收和处理任何CREDIT_RTN 消息，而不依赖于任何其他PM2IP 或IP2PM 消息或其他消息类别。
• 上行端口PMU 必须实施至少一个信用来接收PM2IP 消息。
• 上游端口PMU 必须尽快将所有信用返回至下游端口PMU，以防止阻塞通过CXL 链路的PM 消息通信。
• 建议上游端口PMU 保留信用的时间不要超过10us。

3.1.3 CXL 错误 VDM 格式

CXL 错误消息作为 PCIe 供应商定义的类型 0 消息发送，不带数据负载。 目前，此类包括单一类型的消息，即内存错误固件通知（MEFN）。 图 17 提供了 CXL 错误 VDM 消息的格式。
MEFN消息的特点如下：
• Fmt 和Type 字段设置为指示没有数据的消息。
• 使用“路由到根联合体”的路由发送消息。 它始终由设备发起。
• 消息代码设置为供应商定义的类型0。
• 供应商ID 字段设置为1E98h。
• 消息头的字节15 包含VDM 代码并设置为“CXL 错误消息”的值。 （00 点）
• 字节8、9、12、13 设置为0。
• 字节14 的位[7:4] 设置为0。字节14 的位[3:0] 用于传送固件中断向量（在图17 中缩写为FW 中断向量）。

FW 中断向量字段的编码是主机特定的，因此 CXL 规范未定义。 主机可以支持多于一种类型的固件环境，并且该字段可以用于向主机指示这些环境中的哪一个要处理该消息。

3.1.4 CXL 所需的可选 PCIe 功能

表 7 列出了启用 CXL 所需的符合 PCIe 规范的可选功能。

Data Poisoning by transmitter：
数据毒化（Data Poisoning）是PCIe中的一种错误报告机制，它允许传输设备（transmitter）在检测到数据错误时标记该数据，以便接收设备（receiver）可以采取适当的行动。在CXL的上下文中，支持数据毒化是必需的，这样在发生错误时可以确保数据的完整性。
ATS (Address Translation Services)：
ATS是一种用于改善虚拟内存地址转换效率的机制，它只在设备支持缓存（即具有.cache功能）时才需要。在CXL中，Type 1和Type 2设备需要ATS支持，因为它们可以与CPU共享缓存。然而，Type 3设备（不包含缓存的设备）则不需要ATS支持。
Additional VCs (Virtual Channels) and TCs (Traffic Classes) beyond VC0/TC0：
VC（Virtual Channel）和TC（Traffic Class）是PCIe中用于管理数据流和优先级的功能。VC0和TC0是基本的通道和类别，用于处理所有通信。CXL要求至少支持VC0，如果需要实现服务质量（QoS）控制，可以选择性地支持额外的VC1。
Advanced Error Reporting (AER)：
AER是PCIe高级错误报告功能，允许设备报告详细的错误信息和执行更复杂的错误处理。CXL协议要求支持AER，以便在发生错误时可以提供更详细的诊断信息，从而提高系统的可靠性和可维护性。

3.1.5 错误传播

设备检测到的 CXL.cache 和 CXL.mem 错误通过 CXL.io 流量流传播到上游端口。 这些错误在 PCIe AER 寄存器中记录为可纠正和不可纠正的内部错误。

3.1.6 ATS 上的内存类型指示

对某些内存区域的请求只能在 CXL.io 上发出，而不能在 CXL.cache 上发出。 由主机决定这些内存区域是什么。 例如，在 x86 系统上，主机可以选择仅通过 CXL.io 限制对不可缓存 (UC) 类型内存的访问。 主机通过向设备发出 ATS 完成指示来指示此类区域。
来自 CXL 设备的 ATS 请求必须设置“Source-CXL”位。

64 位：DWORD3，字节 3，位 3； 32 位：DWORD2、字节 3、位 3 定义如下 0b - 表示由不支持 ATS 上内存类型指示的功能发起的请求 1b - 表示由支持 ATS 上内存类型指示的功能发起的请求。 如上所述，所有 CXL 设备功能都必须设置该位。
注：根据 PCIe 规范的定义，该位在 ATS 请求中保留。
来自主机的 ATS 转换完成将携带这样的指示：对给定页面的请求只能在转换完成数据条目中使用以下位“Issue-on-CXL.io”在 CXL.io 上发出：

DWORD1，字节 2，位 1 定义如下 0b - 可以在所有 CXL 协议上发出对页面的请求。
1b - 对页面的请求只能由 CXL.io 上的功能发出。 使用 CXL.Cache 协议向页面发出请求是一种功能违规。
注：根据 PCIe 规范的定义，该位在 ATS 完成中保留。

3.1.7 可延迟写入

CXL 规范中定义的可延迟写入仅适用于在 CXL 1.1 模式下运行时。 在 CXL 2.0 模式下运行时，请参阅 PCIe 规范以了解此功能。 可延迟写入允许多个软件实体将可扩展的工作提交到 CXL 设备，而无需显式锁定或软件同步。 可延迟写入是下游非发布内存写入。 可延迟写入的完成允许设备指示命令是否已成功接受或是否需要延迟。
在 CXL.io 上，可延迟写入作为 NPMemWr32/64 事务发送，该事务具有以下编码（请注意，NPMemWr32 的编码在 PCIe 中已弃用）：
FMT[2:0] - 010b/011b
类型[4:0] - 11011b
由于可延迟写入是非发布的，因此设备预计会发送 Cpl 响应。
Cpl 中的完成状态字段（字节数为“4”）指示工作是否已成功接受。 成功提交的作品会附有
“成功完成”完成状态。 不成功的工作提交会伴随“内存请求重试状态”完成状态。 这些的编码是：
成功完成 (SC) - 000b 内存请求重试状态 (MRS) - 010b