【CXL协议-复位、初始化及管理（9）】

9.1 Compute Express Link 启动和重置概述

9.1.1 总体

CXL设备的三种复位：

Hot reset：通过链路触发（（LTSSM 或 linkdown））
Warm reset：通过外部信号触发 （PERST）
Cold reset：通过外部信号触发，并伴随电源开关
这三种复位被归纳为传统（Conventional）复位。Function级复位和CXL复位不是传统复位。

9.1.2 对比CXL和PCIe行为

Warning：即将到来的事件的早期通知
Signaling：实际启动状态转换

9.2 CXL设备启动流程

CXL设备将沿用PCIe的Warm reset和Cold reset。

9.3 CXL系统复位进入流程

在系统复位过程中，主机发送下列CXL PM VDM给CXL设备。

•PM Logical Opcode[7:0]=RESETPREP

•Parameter[15:0]=REQUEST

•ResetType = Warm Reset

•PrepType = General Prep

CXL设备应向主机刷新任何相关上下文，清理为主机服务的数据，并将连接到CXL设备的内存置于安全状态。所有复位准备完成后，CXL设备发出下列CXL PM VDM给主机。

•PM Logical Opcode[7:0]=RESETPREP

•Parameter[15:0]=RESPONSE

•ResetType = Warm Reset

•PrepType = General Prep

9.4 CXL设备睡眠状态进入流程

9.5 Function-level复位（FLR）

PCIe的FLR机制使软件能够以Function-level粒度停止和复位Endpoint硬件。CXL设备向主机软件公开一个或多个PCIe Function。这些Function可以向主机呈现FLR能力，从而现有的PCIe兼容软件可以向这些Function发出FLR。

9.6 缓存管理

旧有的操作系统或旧有的PCIe总线驱动程序不知道CXL.cache功能。所以，设备驱动程序应该提供CXL.cache功能的支持，以管理CXL缓存。

系统软件可能希望在不复位系统或整个设备的情况下，确保支持CXLcache的设备不包含任何有效的缓存行。由于不需要设备通过FLR清除缓存内容，因此为此定义了单独的控制位和状态位。此功能对于所有支持CXL 2.0 CXLcache的设备都是必需的。软件通过下面的步骤保证设备内没有有效的缓存行：

（这几个步骤个人的一些理解：
禁用缓存（设置 Disable Caching=1）
这一步骤涉及设置DVSEC CXL Control2寄存器中的一个位，以禁用缓存。DVSEC（Device Specific Extended Capability）是扩展能力结构，用于控制特定的硬件功能。
位的位置在协议的8.1.3.4节中有详细定义。
发起缓存写回和失效（设置 Initiate Cache Write Back and Invalidation=1）
此步骤可能与上一步骤结合在一起，通过对DVSEC CXL Control2寄存器的单次配置空间寄存器写操作完成。
这意味着你可以通过一次操作同时设置“禁用缓存”和“发起缓存写回和失效”这两个位。
等待缓存失效确认（等待 Cache Invalid=1）
这一确认是通过检查DVSEC CXL Status2寄存器来完成的，该寄存器的位置在协议的8.1.3.5节中定义。
软件可能需要根据DVSEC CXL Capability2寄存器中报告的缓存大小（在8.1.3.7节中定义）来计算合适的超时值，以确保缓存失效已经完成。
重新启用缓存（设置 Disable Caching=0）
软件需要将禁用缓存的位重新设置为0来启用缓存。
当禁用缓存位从1变回0时，如果之前缓存失效位是1，设备应该将缓存失效位转换为0。
简而言之，这段文本描述了在CXL协议中如何安全地禁用和重新启用缓存，同时确保在这个过程中缓存数据被正确地写回和失效。这是一种避免数据不一致和优化系统性能的措施。）

9.7 CXL复位

9.7.1 对易失性HDM的影响

由于易失性HDM（Host-managed Device Memory）范围的所有权可能在CXL复位后发生变化，因此必须确保CXL复位之前存在的易失性内存内容没有泄漏。

两种情况需要考虑：

设备继续绑定到同一主机，但是系统软件将易失性HDM分配给其它的软件实体。
设备被迁移到另外一个主机。

9.7.2 软件动作

在执行CXL复位时，系统软件应遵循以下步骤：

1. 确定设备是否支持CXL Reset和CXL Reset Mem Clr功能。查阅DVSEC CXL Capability Register(第8.1.3.1节)。
2. 如果设备支持CXL Reset Mem Clr功能，根据需要在DVSEC Control2寄存器(章节8.1.3.4)中编程“CXL ResetMem Clr Enable”。
3. 通过DVSEC CXL Capability Register确定完成的超时时间。
4. 如前所述，为CXL Reset准备系统的其余部分(例如offline内存等)。
5. 在DVSEC CXL Control2寄存器中设置Initiate CXL Reset=1。
6. 在DVSEC CXL Status2寄存器(章节8.1.3.5)中等待CXL Reset Complete=1或CXL Reset Error =1，最长等待超时时间。
   系统软件在重新初始化和联机设备时应遵循这些步骤：
7. 根据需要设置设备，以启用受CXL Reset影响的功能。
8. （可选）检查设备是否在CXL Reset期间执行了清除或随机化内存。如果是，跳过基于软件重新分配前的软件初始化。如果没有，进行软件初始化。

9.8 全局持久刷新（Global Persistent Flush，GPF）

全局持久性刷新（GPF）是一种基于硬件的机制，用于将缓存和内存缓冲区刷新到持久性域（Persistent Domain）。持久性域定义为一个位置，用于保证重新启动设备时保留其数据内容，而不是丢弃数据。比如，当发生突然断电，主机可以启动GPF以确保未完成的数据被写回持久介质中。

9.8.1 主机和交换机职责

所有支持CXL 2.0的主机和交换机都需要支持GPF。GPF流程包含两个阶段：GPF Phase 1和GPF Phase 2。在Phase 1，设备停止新的传输，写回缓存；在Phase 2，持久性设备刷新本地的写缓冲区里的数据到持久性域。在两个阶段之间，主机必须确保停止注入新的CXL.cache事务，并在进入Phase 2之前写回到本地缓存。

9.8.2 设备职责

所有CXL 2.0及更高版本的设备都需要支持GPF，且应在其AGENT_INFO响应中设置CAPABILITY_VECTOR字段的第1个bit。

收到GPF Phase 1请求消息后，CXL设备应按指定顺序执行以下步骤：

1. 停止注入新的 CXL.cache 事务，除了下面步骤 3 中描述的缓存写回之外
2. 如果支持 CXL.cache 并且 Payload[1]=1，则禁用缓存。 这将确保设备不再缓存任何一致内存，从而不会将通过 CXL 接口接收到的任何写入缓存在其 CXL 缓存中。
3. 如果支持 CXL.cache 并且 Payload[1]=1，则写回设备缓存中的所有修改行。 内存目的地可以是本地的或远程的。
   — 为了最大限度地减少 GPF 延迟，设备应忽略不脏的行
   — 为了最大限度地减少 GPF 延迟，设备不应回写它知道映射到易失性存储器的行。 设备获取此知识的机制不属于本规范的范围。
   — 设备必须使用设备内部机制写回映射到其本地持久 HDM 的所有脏行。
   — 设备必须写回所有未映射到其本地 HDM 且可能是持久类型的脏行。 每个此类脏行必须分两步写回到目标 HDM：
   向主机发出 DirtyEvict 请求（第 3.2.4.1.15 节）
   向主机发出 Clflush 请求（第 3.2.4.1.13 节）。
4. 通过发送 GPF 第 1 阶段响应消息，指示设备已准备好移至 GPF 第 2 阶段。 如果第 1 阶段处理不成功，请在响应中设置有效负载 [8]。
   收到GPF Phase 2请求消息后，CXL设备应按指定顺序执行以下步骤：
5. 如果它是持久性内存设备并且设置了 Payload[8] 标志，则增加脏关闭计数（请参见第 8.2.9.5.3.1 节）
6. 将内部内存缓冲区刷新到本地内存（如果适用）
7. 通过发送 GPF 第 2 阶段响应消息来确认请求。
8. 进入尽可能低的功耗状态。

9.8.3 能量预算

通常有必要评估系统是否有足够的能量在断电情况下处理GPF。系统软件可能会通过使用各种CXL DVSEC寄存器中的可用信息，和系统其余部分的信息来确定。

9.9 热插拔

CXL 1.1主机和CXL 1.1设备不支持热插拔。CXL 2.0根端口、CXL 2.0设备和CXL交换机需要支持Hot-Add和Hot-Remove。

支持热插拔需要什么流程？需要看PCIe协议。

9.10 软件枚举

CXL 2.0设备呈现给主机软件的是一个或多个PCIe Endpoint。CXL 1.1设备则呈现为RCiEP（Root Complex Integrated Endpoints）。CXL设备的发现遵循PCIe规范，但CXL 1.1层次结构和CXL 2.0虚拟层次结构之间存在一些差异。

9.11 CXL 1.1 层次

在 CXL 1.1 层次结构中，链路本身不会作为 PCIe 链路暴露给操作系统。 这与 PCIe 模型不同，在 PCIe 模型中，操作系统中的 PCIe 总线驱动程序能够管理 PCIe 链路。 这种方法可确保与传统 PCIe 软件 100% 兼容。
由于该链路未向旧版操作系统公开，因此每个 CXL 1.1 设备都会以 ACPI 定义的 PCIe 主机桥 (PNP ID PNP0A08) 的形式创建新的 PCIe 枚举层次结构。 CXL 端点显示为根联合体集成端点 (RCiEP)。
CXL 端点通过主机中实现的根复合体事件收集器 (RCEC) 向操作系统报告“PCIe”接口错误。 这是通过将 RCEC（根复合体事件收集器总线编号关联 ECN）扩展到 PCIe 规范来实现的。

9.11.1 PCIe Software View of the CXL 1.1 Hierarchy

9.11.2 System Firmware View of CXL 1.1 Hierarchy

CXL 1.1 下游端口和 CXL1.1 上游端口的功能可通过内存映射寄存器进行访问。 这些不会出现在现有操作系统的标准 PCI 总线扫描中。 这些寄存器的基地址由系统固件设置，系统固件可以使用该知识来配置 CXL。
系统固件配置下游端口以解码由 PCIe BAR 寄存器和上游端口 BAR 表示的 CXL 设备的内存资源需求。
PCIe BAR 不得配置为解码与 CXL 设备关联的任何 HDM。

9.11.3 OS View of CXL 1.1 Hierarchy

CXL 设备实例化一个或多个 ACPI 主机桥。 该主机桥的 _BBN 方法与托管 CXL RCiEP 的总线号相匹配。
此 ACPI 主机桥产生了合法的 PCIe 层次结构。 位于 CXL 设备中的所有 PCIe 端点都是此 ACPI 主机桥的子级。 这些端点可能直接出现在根总线编号上，也可能出现在根总线上的根端口后面。
PCIe 根桥的 _CRS 方法返回 CXL 端点占用的总线和内存资源。 _CRS 响应不包括支持 CXL.mem 的设备上的 HDM。
它也不包含任何上游端口 BAR（从操作系统中隐藏）。
CXL 感知操作系统可以使用 CXL 早期发现表 (CEDT) 或 ACPI 命名空间中的 _CBR 对象来定位下游端口和上游端口寄存器。 CEDT 枚举操作系统切换时存在的所有 CXL 主机桥，而 _CBR 仅限于热添加的 CXL 主机桥。

9.11.4 CXL 1.1 Hierarchy System Firmware Enumeration Flow

由于 CXL 1.1 层次结构不支持 CXL 设备的热添加，因此在操作系统切换之前由系统固件枚举它。
CXL 1.1 硬件自主模式选择流程无法自动检测重定时器的数量。 如果系统包括重定时器，系统固件应遵循以下步骤以确保重定时器的数量配置正确。

1. 在链路训练之前，系统固件应根据可用信息设置 DVSEC Flex 总线端口控制寄存器，以指示是否存在 0、1 或 2 个重定时器。 （在链路训练之前，BIOS 可能无法检测到 CXL 附加卡或背板上的重定时器，并且初始编程可能无法考虑路径中的所有重定时器。）
2. 链路训练成功完成或失败后，系统固件应读取 PCIe 标准链路状态 2 寄存器中记录的“重定时器存在检测”和“两个重定时器存在检测”值，并查看它们是否与 Flex 总线端口中的设置一致 上一步中的 DVSEC。 如果它们不同，系统固件应通过设置“链接禁用”来关闭链接
   位，更新 Flex 总线端口 DVSEC 中的 Retimer1_Present 和 Retimer2_Present 位，并再次启动链路训练。

9.11.5 CXL 1.1 device discovery

1. 解析辅助总线 # 上的设备 0、功能 0 的配置空间并发现 CXL 特定属性。 这些通过 CXL 设备功能结构的 PCIe DVSEC 公开。 参见第 8.1.3 节。

9.11.6 CXL 1.1 Devices with Multiple Flex Bus Links

9.11.6.1 Single CPU Topology

在此配置中，系统固件应向控制器报告两个 PCI 主机桥
操作系统，一个托管左侧设备 0、功能 0，第二个托管左侧设备 0、功能 0
右侧托管设备 0、功能 0。 两个设备 0、功能 0 实例
为 CXL 设备实施 PCIe DVSEC 和设备序列号 PCIe 扩展功能。 供应商 ID 和序列号匹配表明两个链路连接到单个 CXL 设备，这使得系统固件能够执行某些优化。
在某些情况下，CXL 设备可能会公开由 CXL 设备的驱动程序管理的单个 CXL 设备功能，而另一个设备 0/功能 0 表示虚拟设备。 在此配置中，应用软件可以将工作提交到单个 CXL 设备实例。 但是，CXL 设备硬件可以免费使用这两个链路
只要不违反编程模型，就可以进行流量和窥探。
系统固件使用以下规则将 HDM 映射到系统地址空间。

9.11.6.2 Multiple CPU Topology

在此配置中，系统固件应向操作系统报告两个 PCI 主机桥，一个托管左侧的设备 0、功能 0，第二个托管右侧的设备 0、功能 0。 两个设备 0、功能 0 实例都实现了 CXL 设备的 PCIe DVSEC 和设备序列号 PCIe 扩展功能。 供应商 ID 和序列号匹配表明这两个链接是
连接到单个加速器，这使得系统固件能够执行某些优化。
在某些情况下，加速器可以选择公开由加速器设备驱动程序管理并处理所有工作请求的单个加速器功能。 如果加速器框架或应用程序不支持分发工作，这可能是必要的
跨多个加速器实例。 即使在这种情况下，两条链路都应生成一个合法的 PCIe 主桥层次结构，并至少具有一个 PCIe 功能。 然而，只要不违反编程模型，加速器硬件就可以自由地使用流量链路和窥探链路。 为了最大限度地减少窥探损失，加速器需要能够区分 CPU 1 和 CPU 2 解码的系统内存范围。设备驱动程序可以通过 ACPI SRAT 表获取此信息，并使用设备特定机制将其传递给加速器。
系统固件使用以下规则将 HDM 映射到系统地址空间。 与单 CPU 情况不同，系统固件绝不能在两个 Flex 总线链路上交错内存范围。

9.12 CXL 2.0 枚举

支持CXL 2.0的主机可以在系统软件中表示为零个或多个CXL 2.0主机桥（Host Bridge），零个或多个CXL 1.1主机桥，零个或多个PCIe主机桥。主机桥是一种软件概念，它表示根端口的集合。

9.12.1 CXL 2.0根端口（Root Port）

每个CXL 2.0主机桥与基本总线号（Base Bus Number）关联，该总线号应包含一个或多个支持CXL 2.0的根端口。这些根端口显示在PCIe配置空间中。根端口可以处于以下四种状态之一：

1.断开连接
2.连接到CXL 2.0设备/交换机
3.连接到CXL 1.1设备
4.连接到PCIe设备/交换机

9.12.2 CXL 2.0虚拟层次

在CXL 2.0模式下运行的根端口可以直接连接到CXL 2.0设备或CXL交换机。这些根端口形成CXL 2.0虚拟层次结构（Virtual Hierarchy，VH）。

9.12.3 枚举支持CXL 2.0的下游端口

软件可以使用下游端口配置空间中的Link Status寄存器和CXL DVSEC ID 7结构的组合来确定具有CXL 2.0功能的下游端口处于哪个状态。

1. 支持 CXL 2.0 的下游端口在不连接时处于断开状态
   有一个活跃的链接。 可以通过跟随PCIe来检测链路的状态
   基础规格。 如果链路未启动，软件应忽略 CXL DVSEC ID 3
   以及 CXL DVSEC ID 7 功能结构。 热添加事件可以将断开端口转换为 CXL 2.0 连接状态或 PCIe 连接状态。 热添加 CXL 1.1 适配器会将端口转换为未定义状态。
2. 连接到 CXL 2.0 设备/交换机的支持 CXL 2.0 的下游端口应公开 CXL DVSEC ID 3 的一个实例和 CXL DVSEC ID 7 功能结构的一个实例。 CXL DVSEC ID 7 结构中的 DVSEC Flex 总线端口状态寄存器应指示 CXL 2.0 协议在链路训练期间已成功协商。 系统固件可能会将下游端口的端口控制覆盖寄存器中的取消屏蔽 SBR 和取消屏蔽链路禁用位保留为默认 (0) 值，以防止旧版 PCIe 软件分别重置设备和链路。

9.12.4 连接到支持 CXL 2.0 的下游端口的 CXL 1.1 设备

CXL 1.1 设备可以连接到 CXL 2.0 根端口或 CXL 2.0 下游端口
交换机端口。 CXL 1.1 设备将自身报告为 RCiEP，因此无法出现
软件，位于 PCIe 可枚举下游端口下方。 系统固件是
负责检测此类情况并重新配置路径中的 CXL 端口
以便 CXL 1.1 设备出现在软件的 CXL 1.1 层次结构中，而不是出现在 CXL 中
2.0 层次结构。
启动时间重新配置支持 CXL 2.0 的端口以启用 CXL 1.1 设备

1. 复位时，下游端口寄存器在 PCI 配置空间中可见
   具有类型 1 标头。 在枚举过程中，系统固件应识别所有
   通过读取 DVSEC ID 7 连接到 CXL 1.1 设备的下游端口
   寄存器而不是链接状态寄存器。 如果培训成功的话
   CXL DVSEC ID 7 结构中的 DVSEC Flex 总线端口状态寄存器应指示
   CXL 2.0 协议未协商，但应指示在链路训练期间协商了 CXL.cache 或 CXL.mem 协议。 如果训练不成功，CXL DVSEC ID 7 结构中的 DVSEC Flex 总线端口接收修改的 TS 数据阶段 1 寄存器应指示该设备具有 CXL 功能，但应指示它不具有 CXL 2.0 功能。 当下游交换机端口检测到 CXL 时，不应在 PCIe 链路状态寄存器中报告链路状态
   1.1 设备位于另一端，以防止旧版软件发现它。
2. 系统固件识别 CXL 2.0 根端口以下所有 CXL 1.1 设备的 MMIO 和总线资源需求。 系统固件添加了 CXL 所需的 MMIO 资源
   1.1 RCRB（每个链路 8KB MMIO）和 CXL 1.1 组件寄存器（每个链路 128KB MMIO）。
3. 系统固件分配 MMIO 和总线资源，并对路径中所有根端口和交换机端口以及 CXL 1.1 设备 BAR（连接到 CXL 1.1 的下游端口除外）中的备用 MMIO 基准/限制和备用总线基准/限制寄存器进行编程 设备。 这些备用解码器遵循标准 PCIe 规则，并在第 8.1.5 节中进行了描述。
4. 系统固件在每个 CXL 1.1 设备路径中的所有根和交换机端口中设置 Alt BME 和 Alt 内存和 ID 空间启用位。
5. 对于连接到 CXL 1.1 器件的每个下游端口，系统固件对 CXL RCRB 基址进行编程，然后将 1 写入 CXL RCRB 使能位。
   写入 CXL RCRB 使能位会将端口寻址模式转换为 CXL
   1.1. 下游端口寄存器现在出现在 RCRB Base 的 MMIO 空间中，而不是在配置空间中。 系统固件向地址 RCRB Base+4KB 发出读取。 CXL 1.1 上行端口捕获其 RCRB 基础，如第 9.11 节所述。 系统固件根据需要配置上游端口和下游端口寄存器。 如果这是交换机下游端口，它将忽略任何从上游端口收到的hot reset请求。
6. 系统固件使用第 9.11 节中描述的算法配置 CXL 1.1 设备。
   系统固件应在单独的 CXL 1.1 主桥下报告每个 CXL 1.1 设备，而不是作为 CXL 2.0 主桥的子桥。
   交换机应确保设备 0、功能 0 处始终有一个 DSP 可见。
   
   这些概念通过图 147 中所示的配置进行说明。在此配置中，CXL 1.1 设备 F 和 D 连接到 CXL 2.0 交换机。 交换机 DSP 标记为 E 和 C。交换机 USP 和 CXL 根端口分别标记为 B 和 A。 图147的左半部分表示地址映射以及A、B、C和E的普通解码器和Alt Mem解码器是如何配置的。
   如果主机访问属于D的MMIO地址，则访问流经A、B和C：
7. 主机发出读
8. 由于 A 的 Alt MSE=1，A Alt Decoder 积极解码访问并将其发送给 B
9. B Alt Decoder 积极解码访问，因为 B 的 Alt MSE=1
10. C正常解码器积极解码访问并将其转发给D，因为C MSE=1
11. D 积极解码并响应，因为 D MSE=1

9.12.5 带有 CXL 1.1 设备的 CXL 2.0 主机/交换机 - 示例

图 149 表示具有 4 个根端口、1 个交换机和 5 个设备的主机的物理连接。 相应的软件视图如图150所示。请注意，该图中的数字（例如PCI设备1中的“1”）并不代表设备编号或功能编号

如图 149 所示，交换机使其 DSP 下方的 CXL 1.1 设备 1 (DSP 1) 在 CXL 1.1 层次结构中显示为 RCiEP。 CXL 1.1 设备 1 作为单独的主机桥公开，正如 CXL 1.1 设备所期望的那样。 该设备在设备号 0、功能号 0 配置空间中托管一个 CXL DVSEC ID 0 实例。 CXL 1.1
下游端口和 CXL 1.1 上游端口寄存器按预期出现在 MMIO 空间中。
当支持 CXL 2.0 的根端口检测到 PCIe 设备（PCIe 设备 1）时，它会在 PCIe 模式下进行训练。 根端口配置空间（类型 1）可以包括 CXL DVSEC ID 3 和 CXL DVSEC ID 7。如果存在，DVSEC ID 7 实例将指示链路在 PCIe 模式下进行训练。 其他 CXL DVSEC ID 结构也可能存在。
如果支持 CXL 2.0 的根端口 (RP2) 连接到空插槽，则其配置空间（类型 1）托管 CXL DVSEC ID 3 和 CXL DVSEC ID 7，但 DVSEC ID 7 应指示无 CXL 连接且 PCIe 链路状态寄存器指示没有 PCIe 连接。 其他 CXL DVSEC ID 结构也可能存在。 用户可以在此插槽中热添加 CXL 2.0 设备、CXL 2.0 交换机或 PCIe 设备。

9.12.6 CXL 2.0 VH 中链路和协议寄存器的映射

由于 CXL 2.0 虚拟层次结构显示为真正的 PCIe 层次结构，因此使用 CXL 2.0 组件的标准 BAR 来映射 Componen 寄存器块。 通过 CXL 1.1 RCRB 映射的寄存器被映射到 CXL 2.0 组件的 PCI 配置空间。
每个 CXL 2.0 主桥都包含 CHBCR，其中包含该主桥下所有根端口共用的寄存器。 在符合 ACPI 的系统中，该寄存器块的基地址是通过 ACPI 通过 CEDT 表或 _CBR 方法发现的。 CHBCR 包括 HDM 解码器寄存器。
每个 CXL 2.0 根端口都承载一个指向关联组件寄存器块的 BAR。 该 BAR 内的偏移量是通过 CXL DVSEC ID 8 发现的。请参见第 8.1.9 节。 组件寄存器块的布局如第 8.2.4 节所示。
每个 CXL 2.0 设备都可以将其组件寄存器块映射到其 6 个 BAR 中的任何一个以及该 BAR 内的 64K 对齐偏移量。 BAR 编号和偏移量通过 CXL DVSEC ID 8 发现。类型 3 设备组件寄存器块包括 HDM 解码器寄存器。
每个 CXL 2.0 上游交换机端口都携带一个指向关联组件寄存器块的 BAR。 该 BAR 内的偏移量是通过 CXL DVSEC ID8 发现的。 上游交换机端口组件寄存器块包含以下寄存器

9.13 HDM的软件视图

HDM作为正常存储呈现给OS/VMM，但是与主机内存相比，HDM可能具有不同的性能/延迟属性。因此，具有CXL.mem设备的系统可以被视为异构存储器系统。ACPI HMAT表是为此类系统引入的，可以报告不同内存范围的延迟和带宽特性。

9.13.1 内存交织

内存交织允许以统一的间隔将连续的内存地址映射到不同的CXL设备。

9.13.2 CXL内存设备标签存储区

暂时略过。

9.14 CXL OS固件接口扩展

9.14.1 CXL Early Discovery Table (CEDT)

CXL早期发现表（CXL Early Discovery Table）使操作系统能够在启动期间的早期，即在分析ACPI命名空间之前，找到CXL主机桥和主机桥寄存器的位置。此表中的信息可由早期启动代码用于执行CXL主机的预初始化，例如配置CXLcache和CXLmem。

9.14.2 CXL_OSC

根据ACPI规范，_OSC（操作系统能力）是操作系统用来向系统固件传达操作系统支持的能力并协商特定能力的所有权的控制方法。
本节中定义的 _OSC 接口仅适用于发起 CXL 层次结构的“主机桥”ACPI 设备。 如第 9.12 节所述，这些 ACPI 设备的 _HID 必须为（或 _CID 包括）EISAID(“ACPI0016”)。 对于 CXL 2.0 及更高版本的层次结构，需要 CXL _OSC。 对于 CXL 1.1 层次结构，CXL _OSC 是可选的。 CXL 主机桥还产生 PCIe 层次结构，并将具有 EISAID（“PNP0A08”）的 _CID。 因此，CXL 主机桥设备可以公开 CXL _OSC 和 PCIe _OSC。
CXL 层次结构的 _OSC 接口由通用唯一标识符 (UUID) 68f2d50b-c469-4d8a-bd3d-941a103fd3fc 标识。
版本 ID 1 包含本规范此版本的本节中定义的字段，由 5 个 DWORD 组成，包括由 _OSC 的通用 ACPI 定义描述的第一个 DWORD。
_OSC 功能缓冲区中的第一个 DWORD 包含 _OSC 通用的位。
其中包括状态和错误信息。
_OSC 功能缓冲区中的第二个 DWORD 是 PCI 固件规范定义的 PCIe 支持字段。
_OSC 功能缓冲区中的第三个 DWORD 是 PCI 固件规范定义的 PCIe 控制字段。
_OSC 功能缓冲区中的第四个 DWORD 是 CXL 支持字段。 支持字段中定义的位提供有关操作系统支持的 CXL 功能的信息。
与 PCIe Support 字段一样，Support Field 中的内容是单向传递的； 返回时，操作系统将忽略对此字段的任何更改。
_OSC 功能缓冲区中的第五个 DWORD 是 CXL 控制字段。 就像
PCIe 控制字段，CXL 控制字段中定义的位用于提交请求
用于控制/处理相关功能的操作系统，通常（但不排除）那些利用操作系统级驱动程序处理的本机中断或事件的功能。 如果控制字段中的任何位通过 _OSC 控制方法返回清除（屏蔽为零），则相应的功能将被指定为平台不支持，并且操作系统不得启用。 其中一些功能可以在操作系统启动之前或在旧操作系统的运行时期间由系统固件控制，而其他功能可能会被禁用/不起作用，直到本机操作系统支持可用为止。
如果主机桥设备范围内不存在 CXL _OSC 控制方法，则操作系统不得启用或尝试使用本节中为主机桥发起的层次结构定义的任何功能。 这样做可能会与系统固件操作发生冲突，或产生不良结果。 建议具有多个主机桥设备的计算机应报告所有主机桥的相同功能，并以相同的方式为所有主机桥协商控制字段中描述的功能的控制。

9.14.2.1 _OSC 评估规则

本节定义操作系统必须评估 _OSC 的时间和方式以及对固件实现的限制。

9.14.2.1.1 查询标志

如果操作系统在评估 _OSC 时设置了查询支持标志（功能 DWORD 1，位 0），则固件在 _OSC 调用的上下文中不允许更改任何硬件设置。 强烈建议操作系统使用设置的查询支持标志来评估 _OSC，直到 _OSC 返回清除的功能屏蔽位，以协商授予操作系统本机支持的功能集； 在授予给定功能的本机控制之前，平台可能需要操作系统本机支持特定的功能组合。

9.15 CXL设备可操作性模型（Manageability Model）

可管理性是被管理实体向管理实体公开的一组功能。CXL设备是被管理实体。这些能力通常分为sensor和effector。性能计数器是sensor的一个示例，而更新设备固件的能力是effector的一个示例。Sensor和effector可以在带内（即通过驻留OS/VMM的软件）访问，也可以在带外（即通过运行在独立于OS的管理控制器上的固件）访问。带内软件可以通过发出PCIe配置读/写或MMIO读/写事务来访问CXL设备的可管理性功能。S0状态下的带外可管理性可以在PCI Express基础架构上利用MCTP。

相同之处：
复位操作： 无论是CXL还是PCIe，复位操作的基本目的都是将设备带回到已知的初始状态，从而准备好接受新的配置和初始化序列。
CXL设备在执行复位时会遵循PCIe标准中定义的复位行为，包括对应的时序、电气信号要求和状态转换
信号完整性： 两种协议在初始化过程中都需要确保信号完整性，包括电气特性的匹配、链路训练以及可靠的数据传输。
功能配置： CXL和PCIe设备都需要在初始化阶段进行功能配置，这可能包括资源分配（如内存空间、IO空间）、中断设置等。
不同之处：
协议用途： PCIe通常用于各种类型的设备连接，如显卡、网络卡、存储设备等；而CXL专注于处理器与高速、低延迟设备（如加速器、内存扩展设备）之间的互联。因此，CXL在初始化时需要处理更多与处理器紧密相关的配置问题。
数据一致性和缓存协同： CXL协议设计了专门处理缓存一致性和协同操作的机制，因为它支持处理器和内存之间的协同工作。而PCIe协议通常不直接涉及缓存一致性问题，因为这通常由上层的软件或者具体实现来处理。
内存语义： CXL具有更为复杂的内存语义，支持内存区域的共享和细粒度的内存访问控制，这在PCIe中不是标准功能。
设备类型和类别： CXL设备在初始化时，可能会执行一些特定于CXL设备类型的步骤，如处理器内存扩展（CXL.mem），加速器（CXL.io）或者缓存扩展（CXL.cache）设备的特定操作。而PCIe初始化更加通用，适用于多种不同类型的设备。
固件和软件的角色： 在CXL设备的初始化过程中，涉及更复杂的固件和软件交互，因为这些设备的操作通常更接近处理器的核心功能。而PCIe设备的初始化过程更加简化和标准化。