CXL协议-第二章

2.0 CXL System Architecture

        本章介绍了CXL的性能优势和主要特点。CXL是一种高性能的I/O总线架构，用于互连外围设备，这些外围设备可以是传统的非相干I/O设备、内存设备或具有附加功能的加速器。可以通过CXL连接的设备类型和整个系统架构如图2-1所示。

        当类型2和类型3的设备内存暴露给主机时，它被称为主机托管的设备内存（HDM）。该内存的一致性管理有3个选项：仅主机相干（HDM-H）、设备相干（HDM-D）和使用反向失效Snoop（HDM-DB）。主机和设备必须共同了解每个地址区域的HDM类型。有关更多细节，请参见第3.3节。

Figure 2-1. CXL Device Types

        在深入研究每种类型的CXL设备的细节之前，这里有一个关于不需要使用CXL的情景。

        传统的非相干I/O设备主要依赖于标准的生产者-消费者模型，并针对主机连接的内存进行执行。对于此类设备，除了工作提交和工作完成边界上的信号传递外，很少与主机进行交互。这种加速器也倾向于用于数据流或大型连续数据对象。这些设备通常不需要CXL提供的高级功能，而传统的PCIe*作为一种加速器附加介质就足够了。

        以下部分描述了CXL设备的各种配置文件。

2.1 CXL Type 1 Device

        CXL类型1型设备有特殊的需求，在设备中有一个完全一致的缓存变得有价值。对于这类设备，标准的生产者-消费者订购模型并不工作。具有特殊要求的设备的一个例子是执行复杂原子，这些原子不是PCIe上标准原子操作组的一部分。

        基本的缓存一致性允许加速器实现它选择的任何排序模型，并允许它实现无限数量的原子操作。这些往往只需要一个小容量的缓存，可以很容易地被标准处理器窥探过滤机制跟踪。这类设备所能支持的高速缓存的大小取决于主机的窥探过滤能力。CXL使用其可选的CXL.cache缓存链接支持这些设备，加速器可以使用CXL.cache协议进行缓存一致性事务。

Figure 2-2. Type 1 Device - Device with Cache

2.2 CXL Type 2 Device

        CXL Type 2设备除了完全一致性缓存外，还具有附加到设备上的内存，例如DDR、高带宽内存（HBM）等。这些设备对内存执行，但它们的性能来自于加速器和设备连接内存之间的巨大带宽。CXL的主要目标是为主机提供一种方法，将操作数推到设备附加的内存中，并为主机从设备连接的内存中拉出结果，这样就不会增加软件和硬件成本，从而抵消加速器的好处。本规范将一致性系统地址映射的设备附加内存称为具有设备管理一致性的主机管理设备内存（HDM-D/HDM-DB）。

        在HDM和传统的I/O和PCIe专用设备内存（PDM）之间有一个重要的区别。这种设备的一个例子是带有附加GDDR的GPGPU。这些设备已经将与设备连接的内存视为私有内存。这意味着主机无法访问内存，并且与系统的其余部分不一致。它完全由设备硬件和驱动程序管理，主要用作具有大数据集的设备的中间存储器。这种模型的明显缺点是，当操作数和结果被写入时，它涉及从主机内存到设备附加内存的高带宽复制。请注意，CXL并不排除使用PDM的设备。

Figure 2-3. Type 2 Device - Device with Memory

        在高水平上，有两种方法可以解析HDM的器件相干性。第一个程序使用CXL。通过高速缓存来管理HDM的一致性，并被称为“设备一致性”。支持此流的内存区域用“D”（HDM-D）的后缀表示。第二种方法使用CXL.mem中的专用通道，称为反向内部验证Snoop，并用后缀“DB”（HDM-DB）表示。下面的部分将更详细地描述这些内容。

2.2.1 Back-Invalidate Snoop Coherence for HDM-DB

        使用HDM-DB，该协议在CXL.mem协议中启用了新的通道，允许设备使用专用的反向无效Snoop（BISnp）通道直接窥探到主机。这些窥探的响应通道是反向无效响应（BIRsp）通道。这些通道允许设备灵活地管理一致性，通过使用一个包含监听过滤跟踪单个数据线的一致性，这可能会阻止新的M2S请求，直到主机处理BISnp消息。当使用HDM-DB时，也可以实现第2.2.1节中描述的所有设备一致性跟踪选项；但是，HDM-DB流向主机的一致性必须只使用CXL.mem S2M BISnp通道，而不使用D2H CXL.cache请求通道。所有实现256B Flit模式的设备都需要HDM-DB支持，但HDM-D流将支持与68B Flit模式兼容。

        有关在HDM-DB中使用的流的更多详细信息，请参见第3.5.1节，“在CXL.mem上的反向内部验证提示操作的流”。       

2.2.2 Bias-based Coherency Model for HDM-D Memory 

        连接到给定设备的主机托管设备内存（HDM）称为设备连接内存，以表示它仅对该设备是本地的。基于偏置的相干性模型定义了设备附加内存的两种偏置状态：主机偏置和设备偏置。当设备连接的内存处于“主机偏置”状态时，设备上就会显示与常规主机连接的内存一样。也就是说，如果设备需要访问内存，它会向主机发送一个请求，该请求将解决所请求行的一致性。另一方面，当设备连接的内存处于“设备偏置”状态时，设备保证主机在任何缓存中都没有该行。因此，该设备可以不发送任何事务（如请求、窥探等）即可访问它。需要注意的是，无论偏置状态如何，主机本身看到的是设备附加内存的统一视图。在这两种模式下，与设备连接的内存都保持了相干性。

        基于偏倚的相干性模型的主要好处是：

1. 有助于维护映射到系统一致性地址空间的设备附加内存的一致性。
2. 帮助设备在高带宽下访问其本地附加的内存，而不会产生显著的一致性开销（例如，窥探主机）。
3. 以连贯、统一的方式帮助主机访问设备连接的内存，就像它访问主机连接的内存一样。

        为了维护偏倚模式，CXL Type 2设备将：

1. 实现偏倚表，它跟踪页面粒度偏倚（例如，每4kb页面1个），可以使用偏倚缓存缓存在设备中。
2. 使用过渡代理（TA）构建对偏置转换的支持。这本质上看起来像是一个用于“清理”页面的DMA引擎，这本质上意味着刷新主机的缓存中属于该页面的行。
3. 构建对基本负载和存储对加速器本地内存的访问，以支持主机。

        下面详细描述了偏置模式。

2.2.2.1 Host Bias

        主机偏置模式通常指主机在提交工作期间写入内存的操作数或在工作完成后从内存中读取结果的循环部分。在主机偏置模式期间，一致性流允许从主机到设备连接内存的高吞吐量访问（如图2-4中的双向蓝色箭头到/从主机管理的设备内存、CXL设备中的DCOH和主机中的主代理），而设备对设备连接内存的访问不是最佳的，因为它们需要通过主机（如图2-4中的绿色箭头所示，在CXL设备中的DCOH与主机中的相干桥之间，以及CXL设备中的DCOH与主机管理的设备内存之间）。

Figure 2-4. Type 2 Device - Host Bias

2.2.2.2 Device Bias

        设备偏置模式是在设备执行工作时，在工作提交和完成之间使用的，在这种模式下，设备需要对设备附加内存的高带宽和低延迟访问。

        在这种模式下，设备可以访问不咨询主机的一致性引擎的设备附加内存（如图2-5中的红色箭头所示，在CXL设备中的DCOH和主机管理的设备内存之间循环）。主机仍然可以访问设备连接的内存，但可能会被迫放弃所有权加速器（如图2-5中的绿色箭头所示，它在CXL设备中的DCOH和主机中的相干桥之间循环）。这导致设备从设备连接的内存中看到理想的延迟和带宽，而主机看到性能受损。

2.2.2.3 Mode Management

        有两种设想的偏置模式管理方案——软件辅助和硬件自主方案。CXL支持这两种模式。附录a中有偏置流的例子。

        虽然下面描述了两种模式，但值得注意的是，设备不需要实现任何偏置。在这种情况下，所有设备连接的内存都退化为主机偏置。这意味着所有对设备连接的内存的访问都必须通过主机进行路由。加速器可以自由选择自定义的软件辅助和硬件自主偏置管理方有两种设想的偏置模式管理方案——软件辅助和硬件自主方案。CXL支持这两种模式。附录a中有偏置流的例子。虽然下面描述了两种模式，但值得注意的是，设备不需要实现任何偏置。在这种情况下，所有设备连接的内存都退化为主机偏置。这意味着所有对设备连接的内存的访问都必须通过主机进行路由。加速器可以自由选择自定义的软件辅助和硬件自主偏置管理方案。主机实现与上述任何一种选择都无关。主机实现与上述任何一种选择都无关。

2.2.2.4 Software-assisted Bias Mode Management

        有了软件协助功能，我们就可以依靠软件来了解一个给定的页面，即该页面所在的工作执行流的状态。这对于具有具有常规访问模式的分阶段计算的加速器非常有用。在此基础上，软件可以通过适当地选择主机或设备偏置模式来最佳地优化页面粒度上的一致性性能。

        以下是软件辅助偏差模式管理的一些特点：

1. 软件辅助可以用来在计算之前在加速器上准备好数据。
2. 如果数据没有提前移动到加速器存储器中，那么它通常会根据加速器对数据的一些尝试引用来根据需要移动。
3. 在“按需”数据获取场景中，加速器必须能够找到要执行的工作，其中的数据已经正确放置，否则加速器必须停止。
4. 加速器停滞的每一个周期都会侵蚀其在核心上的软件增加价值的能力。
5. 简单的加速器通常不能隐藏数据获取延迟。

        高效的软件辅助数据/一致性管理对于上述一类简单加速器至关重要。

2.2.2.5 Hardware Autonomous Bias Mode Management

        软件辅助一致性/数据管理是简单加速器的理想选择，但对于复杂、可编程的加速器价值较小。与此同时，复杂的问题经常映射到复杂的可编程加速器上，如果需要软件辅助的一致性/数据移动，这对程序员来说是一个非常复杂的问题。对于在主机和加速器之间分割计算的问题或基于指针、基于树或稀疏数据集的问题尤其如此。

        硬件自主偏差模式管理，不依赖于软件来适当地管理页面级的一致性偏差。相反，是硬件根据给定页面的请求者对偏差模式进行预测，并相应地进行调整。该模型的主要优点是：

1. 提供与软件辅助模型相同的页面粒度一致性偏差能力。
2. 消除了在卸载执行之前对软件来识别和安排页面偏差转换的需要。
3. 在卸载执行期间为动态偏置转换提供硬件支持。
4. 对此模型的硬件支持可以是对软件辅助模型的一个简单扩展。
5. 链接流和主机支持不受影响。
6. 影响主要限于当主机触摸“设备偏置”页面时在加速器上采取的操作，反之亦然。
7. 注意，即使这是一个表面上的硬件驱动解决方案，硬件不需要自动执行所有转换——尽管如果需要，它可以这样做。

        如果硬件提供提示（例如，“过渡页面X现在偏向Y”），但将实际的过渡操作留在软件控制下，这就足够了。

2.3 CXL Type 3 Device

        CXL Type 3设备支持CXL.io和CXL.mem协议。CXL Type 3设备的一个示例是主机的内存扩展器，如下图所示。

Figure 2-6. Type 3 Device - Memory Expander

        由于这不是在主机内存上操作的传统加速器，因此该设备不会通过CXL.cache发出任何请求。被动内存扩展设备将使用HDM-H内存区域，当内存暴露在主机上时，永远不会直接操作其内存。该设备主要通过CXL.mem操作到从主机发送的服务请求。CXL.io协议用于设备发现、枚举、错误报告和管理。允许设备将CXL.io协议用于其他特定于I/O的应用程序用途。CXL体系结构独立于内存技术，并根据在主机中实现的支持，允许一系列内存组织的可能性。作为HDM-DB公开的3型设备内存使设备能够直接管理与主机的一致性，以启用内存内计算和使用CXL.io上的UIO进行直接访问。

2.4 Multi Logical Device (MLD)

        3型多逻辑设备（MLD）可以将其资源划分为最多16个隔离的逻辑设备。每个逻辑设备都由CXL.io和CXL.mem协议中的一个逻辑设备标识符（LD-ID）进行标识。对虚拟层次结构（VH）可见的每个逻辑设备都作为3型设备操作。LD-ID对访问VH的软件是透明的。MLD组件对所有ld上的每个协议都有通用的事务层和链接层。因为LD-ID能力仅存在于CXL.io和CXL.mem协议中，MLD被限制在类型3型设备。

        一个MLD组件有一个为结构管理器（FM）保留的LD，最多有16个LD可用于主机绑定。FM拥有的LD（FMLD）允许FM跨LD配置资源分配，并管理与多个虚拟CXL交换机（VCSs）共享的物理链路。FMLD的总线掌握功能仅限于生成错误消息。由此Function生成的错误消息只能路由到FM。

        MLD组件包含一个MLD DVSEC（参见第8.1.10节），该DVSEC仅由FM访问，并可通过CXL LD-ID TLP前缀中的LD-ID为FFFF h的请求寻址。交换机实现必须保证FM是唯一被允许使用FFFF h的LD-ID的实体。

        允许MLD组件使用FM API来配置LD或已进行静态配置的LD。在这两种配置中，配置的LD资源都通过MLD DVSEC进行分配。此外，CXL开关还使用FMLD的MLD DVSEC LD-ID热重位矢量寄存器触发一个或多个LD的热重位。详见第8.1.10.2节。

2.4.1 LD-ID for CXL.io and CXL.mem

        LD-ID是一个16位的逻辑设备标识符，适用于CXL.io和CXL.mem的请求和响应。所有目标请求和MLD返回的响应必须包括LD-ID。

        请参考第4.2.6节中的CXL.mem报头格式来携带LD-ID字段。

2.4.1.1 LD-ID for CXL.mem

        CXL.mem只支持较低的4位的LD-ID，因此可以在链路上支持多达16个唯一的LD-ID值。通过MLD端口转发的请求和响应将用LD-ID进行标记。

2.4.1.2 LD-ID for CXL.io

        CXL.io支持为通过MLD端口转发的所有请求和响应携带16位的LD-ID。FFFF-ID是保留的，并且总是由FM使用。CXL。io利用供应商定义的本地TLP前缀来携带16位的LD-ID值。供应商定义的本地TLP前缀的格式如下。CXL LD-ID供应商定义的本地TLP前缀使用本地前缀L0本地TLP前缀类型。

Table 2-1. LD-ID Link Local TLP Prefix

+0								+1								+2								+3
7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
PCIe Base Spec Defined								LD-ID[15:0]																RSVD

2.4.2 Pooled Memory Device Configuration Registers

        每个LD作为一个或多个PCIe端点（EP）功能可见。虽然LD函数支持所有的配置寄存器，但影响公共链路行为的几个控制寄存器都是虚拟化的，并且对链路没有直接影响。LD的每个函数都必须实现PCIe基本规范中描述的配置寄存器。除非另有说明，配置寄存器的范围如PCIe基本规范中所述。例如，命令寄存器中的内存空间启用（MSE）位控制函数对内存空间的响应。

        表2-2列出了与PCIe基本规范相比，已经修改了行为的寄存器字段集。

Table 2-2. MLD PCIe Registers 

2.4.3 Pooled Memory and Shared FAM

        从支持多个主机的设备上公开的主机托管设备内存（HDM）称为结构连接内存（FAM）。通过逻辑设备（LDs）公开的FAM称为LD-FAM；使用基于端口的路由（PBR）链接以更可伸缩的方式公开的FAM称为Global-FAM（G-FAM）。

        每个HDM区域专用于单个主机接口的FAM被称为“合并内存”或“合并FAM”。将多个主机接口配置为并发访问单个HDM区域的FAM称为“共享FAM”，而不同的共享FAM区域可以配置为支持不同的主机接口集。

        LD-FAM包括几种设备变体。多逻辑设备（MLD）在单个共享链路上公开多个LDs。多头单逻辑设备（MH-SLD）公开多个ld，每个都有一个专用链路。多头MLD（MH-MLD）包含多个链路，其中每个链路支持MLD或SLD操作（可选地配置），并且至少有一个链路支持MLD操作。有关更多详细信息，请参见第2.5节，“多头设备”。

        G-FAM设备（GFD）目前采用支持多个主机接口的单一链路架构，其中传入的CXL.mem请求的主机接口由PBR消息中包含的源PBR ID（SPID）字段确定（详细信息见第7.7.2节）。

        MH-SLD和MH-MLD应该与任意多端口类型3组件区分，例如9.11.7.2节中描述的组件，该组件支持单个OS域中的多个CPU拓扑。

2.4.4 Coherency Models for Shared FAM

        每个共享的HDM-DB区域的一致性模型被FM指定为多主机硬件一致性或软件管理的一致性。        

        多主机硬件一致性要求MLD硬件跟踪主机一致性状态，如表3-31中定义的“元0状态值定义（HDM-D/HDM-DB设备）”为每个坐标轴，具体取决于MLD的实现特定跟踪机制，通常可以分类为窥探过滤器或完整目录。每个主机都可以通过获得对一个坐标线的独占访问来执行任意原子操作，并在其缓存内对其指令集体系结构（ISA）执行原子操作。使用缓存一致性对数据进行全局观察，并遵循正常的硬件缓存驱逐流。对此内存区域的MemWr命令必须将SnpType字段设置为NoOp，并设置为防止死锁，这要求主机必须在发出MemWr之前使用M2S请求通道获得所有权，从而在2个阶段中完成一次写入。这是共享FAM中对硬件一致性模型的一个独特要求。

        共享的FAM也可能将内存以简单的HDM-H的形式公开给主机，但这将只支持主机之间的软件一致性模型。

        软件管理的一致性不需要MLD硬件来跟踪主机的一致性状态。相反，每个主机上的软件使用特定于软件的机制来协调每个斜坐标线的软件所有权。软件可以选择依赖于其他HDM区域中的多主机硬件一致性来协调软件管理的一致性HDM区域中的粗线的软件所有权。软件协调斜坐标线所有权的其他机制不在本规范的范围之内。

2.5 Multi-Headed Device

        具有多个CXL端口的3型设备被认为是多头设备。每个端口都被称为一个“磁头”。有两种类型的多头设备，区分他们如何呈现自己在每个头：

1. MH-SLD，目前SLD所有头;
2. MH-MLD，它可能在他们的任何头上

        管理头的多头设备遵循模型定义的设备头：

1. 头目前的SLD可能支持端口管理和控制功能的SLD头可能支持端口管理和可用的控制功能
2. 存在MLD的磁头可能支持MLD可用的端口管理和控制功能

        多头设备中内存资源的管理遵循为MLD组件定义的模型，因为MH-SLD和MH-MLD都必须支持基于每个LD隔离内存资源、状态、上下文和管理。设备内的ld被映射到单个头。

1. 在MH-sld中，头部和ld之间有一个1：1的映射。
2. 在MH-Mld中，多个ld最多映射到一个头部。多头设备中的磁头应至少映射一个且不超过16个LD。带有一个LD映射的头应显示为SLD，而带有多个LD映射的头应显示为MLD。每个头部可能有不同数量的ld。

        图2-7和图2-8分别说明了MH-SLDs和MHMLDs的LDs到磁头的映射.

Figure 2-7. Head-to-LD Mapping in MH-SLDs

Figure 2-8. Head-to-LD Mapping in MH-MLDs

        多头设备公开了一个专用的组件命令接口（CCI），即LD池CCI，用于管理设备内的所有LD。LD池CCI可以被公开为基于MCTP的CCI，也可以通过头部的邮箱CCI通过隧道管理命令命令进行访问，详见第7.6.7.3.1节。LD池CCI应支持隧道管理命令，以便为设备内的所有LD执行隧道管理命令。

        多头设备报告的支撑头数量应保持不变。支持专有机制动态重新配置可访问头数量的设备（例如，将2 x8端口动态分叉为单个x16头等）。应报告最大数量。

2.5.1 LD Management in MH-MLDs

        MH-MLD中的LD池可能支持超过16个LDs。通过MH-MLD的头部暴露的mld使用相对于该头部从0到n-1的ld-id，其中n是映射到头部的ld的数量。MH-MLD将头部接收到的LD-id映射到MH-MLD LD池中设备范围的LD索引。MHMLD每个头内的FMLD应仅暴露和管理映射到该头的LDs。

        一个头上的LD或FMLD可以通过使用隧道管理命令访问LD池CCI，允许查看和管理设备内的所有LD，详见第7.6.7.3.1节。

2.6 CXL Device Scaling

        CXL支持在VH以下连接多达16个1型和/或2型设备。为了支持这种缩放，第2型设备需要在CXL.mem协议中使用BISnp通道来管理HDM区域的一致性。在CXL 3.0规范定义中引入的BISnp通道取代了使用CXL.cache协议来管理设备的HDM区域的一致性。使用CXL.HDM一致性管理缓存的第2类设备。缓存仅限于每个主机桥的单个设备。

2.7 CXL Fabric

        CXL Fabric描述了依赖于基于端口的路由（PBR）消息和流的特性，以实现可扩展的交换和高级交换拓扑。PBR支持一个灵活的低延迟体系结构，在每个结构结构中最多支持4096个PBRid。G-FAM设备连接（参见第2.8节）原生支持到结构中。主机和设备使用通过结构中的边缘开关转换到和从PBR格式转换的标准消息传递流。第7.7节定义了要求和用例。

        CXL Fabric是一个或多个交换机的集合，每个PBR都有能力，并与PBR链路相互连接。域是在单个相干的主机物理地址（HPA）空间中的一组主机端口和设备。CXL结构将一个或多个主机端口连接到每个域内的设备。

2.8 Global FAM (G-FAM) Type 3 Device

        G-FAM设备（GFD）是一种3型设备，它使用PBR链接连接到CXL Fabric，并依赖PBR消息格式为FAM提供比LD-FAM设备更高的可伸缩性。GFD的单一逻辑设备由结构管理器拥有。相关的FM API和host mailbox接口仍在开发中，并将在未来的规范更新中指定。

        与LD-FAM设备一样，gfd可以支持池化FAM、共享FAM，或者两者都支持。gfd完全依靠动态能力机制来进行容量管理。有关细节以及与LD-FAM设备的其他比较，请参见第7.7.2.3节。

2.9 Manageability Overview

        为了允许不同类型的管理系统，CXL支持多种类型的管理接口和管理互连。有些是由外部标准定义的，而有些是在CXL规范中定义的。

        CXL组件发现、枚举和基本配置均由PCISIG*和CXL规范定义。这些功能是通过访问配置空间结构和相关的MMIO结构来完成的。

        安全身份验证和数据完整性/加密管理在PCISIG、DMTF和CXL规范中定义。关联的管理流量可以通过使用配置空间的数据对象交换（DOE）进行传输，或者通过基于MCTP的传输进行传输。后者可以使用PCIevdm进行带内操作，也可以使用管理互连，如SMBus、I3C或专用的PCIe链路。                

        CXL设备的可管理性模型详见第9.18节。高级CXL特定组件管理使用一个或多个cci处理，这在9.19节中介绍。CCI命令分为4类：

1. 通用组件命令
2. 内存设备命令
3. FM API命令
4. 供应商特定命令

        所有4组都在第8.2.9节中介绍，具体来说：

1. 命令和能力确定
2. 命令前景和后台操作
3. 事件日志记录、通知和日志检索
4. 交互，基于组件类型和其他属性，

        每个命令都是强制性的、可选的或禁止的。命令可以发送到设备、交换机或两者都发送。

        CCIs使用多个传输和互连来完成其操作。在第8.2.8.4节中介绍了邮箱机制，并通过架构化的MMIO寄存器接口访问邮箱。基于MCTP的传输使用PCIe VDMs的带内连接或前面提到的任何带外管理互连。FM API命令可以通过CXL交换机通过隧道传输到mld。配置和MMIO访问可以通过CXL交换机通过隧道传输到mld中的ld。

        DMTF的平台级数据模型（PLDM）用于平台的监控和控制，并可用于组件固件的更新。PLDM使用MCTP与目标CXL组件进行通信。

        鉴于CXL使用了多种可管理性标准和互连，因此在设计包含CXL组件的系统时考虑互操作性是很重要的。

好难理解！！！