本文主要是介绍CXL事务层,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
3.1 CXL.io
CXL.io为IO设备提供非一致性的load/strore接口。事务类型、事务数据包格式、信用流量控制、虚拟通道管理、事务顺序的规则等遵循PCIe协议。CXL.io的事务层如下图中的黄色部分所示。
3.1.1 CXL.io端点(Endpoint)
CXL设备需要支持在CXL 1.1和CXL 2.0模式下运行。当链路配置为在CXL 1.1模式下运行时,CXL.io端点必须作为PCIe RCiEP;而当配置为在CXL 2.0模式下运行时,必须作为PCI Express端点。
RCiEP是Root Complex Integrated Endpoints的缩写,PCIe端点的一种。
3.1.2 CXL电源管理VDM(Vendor Defined Message)格式
CXL电源管理消息使用PCIe的VDM Type 0,带有4DW的负载数据,包括PMREQ,PMRSP和PMGO消息。
CXL电源管理VDM的格式如下:
如果接收方CXL组件接收到“有毒”的电源管理VDM,则应丢弃此类消息。由于接收方在接收到此类VDM后能够继续正常运行,因此应将此事件视为非致命性错误(non-fatal)。如果接收方的电源管理单元(PMU)不理解电源管理VDM数据负载的内容,则应无声地丢弃该消息,并且不发出无法纠正错误(uncorrectable error)的信号。
数据负载的字段定义比较多,就不贴图了。
电源管理信用和初始化过程是本地链接。设备和主机之间通过CXL.io通道发送的消息类型主要涉及两种,分别是CREDIT_RTN和AGENT_INFO,其中PM2IP是主机发给设备的电源管理消息,而IP2PM是设备发给主机的电源管理消息。至于“信用”机制就不解释了,在前面讲CCIX的时候已经介绍过了。
所谓的上游端口(Upstream Port)指的是设备的端口;而下游端口(Downstream Port)是主机端口。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消息为上游端口PMU分配PM_AGENT_ID。此ID通过CREDIT_RTN消息中的TARGET_AGENT_ID字段进行通信。在启动任何IP2PM消息之前,上游端口PMU必须等待来自下游端口PMU的CREDIT_RTN消息
参考下图,第一条消息,PM2IP.CREDIT_RTN(Target_Agent_ID,Num_Credits=1) ,这个消息里面包含了2个内容,一个是Target_Agent_ID,另一个是主机给了设备1个信用值。之后,设备也给主机发送了一个消息IP2PM. CREDIT_RTN(Num_Credits=2),授权了主机2个信用值。在初始化的时候,设备必须先等待接受来自主机的CREDIT_RTN消息,而不能先向主机发送消息。
上游端口PMU必须遵循的规则:
-
在启动任何IP2PM消息之前,上游端口PMU必须等待接收PM2IP.CREDIT_RTN消息。
-
上游端口PMU必须从下游端口PMU接收到的第一条PM2IP消息中提取TARGET_AGENT_ID字段,并将其用作未来消息中的PM_AGENT_ID。
-
上游端口PMU必须实现足够的资源来接收和处理任何CREDIT_RTN消息,而不依赖于任何其他PM2IP或IP2PM消息或其他消息类。
-
上游端口PMU必须实现至少一个信用,以接收PM2IP消息。
-
上游端口PMU必须尽快向下游端口PMU返回信用,以防止通过CXL链路阻塞电源管理消息通信。
-
建议上游端口PMU占用信用额度不得超过10us。
插播一句,是不是看的晕晕的?这里简单介绍一下供应商定义的消息(VDM),PCIe协议里是这么说的“The Vendor Defined Messages allow expansion of PCI Express messaging capabilities, either as a general extension to the PCI Express Specification or a vendor-specific extension”。
3.1.3 CXL错误VDM格式
CXL错误消息使用PCIe的VDM Type 0,没有负载数据,格式如下。
3.1.4 CXL所需的可选PCIe功能
3.1.5 错误传播
设备检测到的CXL.cache和CXL.mem错误通过CXL.io通信流传播到上游端口。这些错误在PCIe AER寄存器中记录为可纠正(Correctable)和不可纠正(Uncorrectable)的内部错误。
3.1.6 ATS上的存储器类型指示
对某些内存区域的请求只能在CXL.io上发出,而不能在CXL.cache上发出。由主机决定这些内存区域是什么。例如,在x86系统上,主机可以选择仅通过CXL.io限制对不可缓存(Uncacheable)类型内存的访问。主机通过ATS完成(ATS Completion)向设备来指示这些区域。
插播一句,ATS是Address Translation Services的缩写。PCIe协议里面有一整章讲ATS。为节省CPU资源,I/O Function常采用DMA方式访问内存。一般I/O Function看到的物理地址空间与CPU一样。但有时候,I/O Function看到的地址空间不是真实的物理地址,需要RC将DMA请求进行处理,通过一次地址转换才能将访问到真实的物理地址。这种地址转换机制有利于访问权限检查。
一般PCIe设备在本地实现一个地址缓存(Address Translation Cache,ATC),类似CPU中的TLB。Function发送存储器读写请求前,先在本地的ATC中查找是否有该地址的条目。如果在ATC中查找成功,直接采用转换后地址进行访问。如果在ATC中没有找到该地址的条码,则给TA(Translation Agent)发送该地址的地址转换请求。在ARM体系中,TA的功能由SMMU(System Memory Management Unit)承担,此外SMMU还要显式的负责同步TLB和与它相连的分布ATC中的数据一致性。关于SMMU,之前的文章介绍过。
3.1.7 可延迟写
CXL规范中定义的可延迟写入仅在CXL 1.1模式下运行时适用。在CXL 2.0模式下操作时,请参阅PCIe规范以了解此功能。
这篇关于CXL事务层的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!