✨1. TLP Prefix
1.1 基本介绍
通用的TLP包括Prefix、Header、Data、Digest这4部分,格式如图所示,其中Prefix及Digest是可选的。本文主要介绍TLP Prefix。
图1 通用TLP格式
TLP Prefix由PCIe V2.1引入,实现方法为通过在TLP Header之前附加1或多个DW的前缀数据来使TLP携带更多额外的信息,从而实现TLP PH、PASID、MR-IOV及其他verndor自定义的功能。
TLP Prefix功能是可选的,为了发送带有TLP Prefix的TLP,请求者到完整者之间所有的设备组件都应支持TLP Prefix能力。
图2 TLP Prefix格式
TLP Prefix与Header一样有Fmt和Type两个字段(图2),其中Fmt用以指示TLP 前缀的DW数,Type用以指示TLP Prefix的类型。接收者通过检测Byte0的Fmt字段来判断是否为TLP Prefix,若Fmt=100b,则表示当前DW为TLP Prefix(的开始)。TLP Prefix分为两大类:Local 和End-End,其中Local TLP Prefix用以在PCIe链路两侧传递信息,End-End用以在两个EP端点之间传递信息。这两大类通过Type字段第4bit来加以区分,Local TLP Prefix及End-End TLP Prefix大类又可以细分为几小类,如表1所示。
表1 TLP Prefix类型
1.2 TLP Prefix处理
1.2.1 基本规则
对于带有TLP Prefix的TLP,应遵循以下规则:
- TLP Fmt[2:0]字段设置为100b来指示当前为TLP Prefix,Type[4]位为0b表示该TLP Prefix为Local类型,为1b表示该TLP Prefix为End-End类型;
- TLP Prefix的Byte1~Byte3依据TLP Prefix类型进行指定;
- 携带TLP Prefix的TLP在Prefix之后仍需有一个头标,否则作为畸形包处理;
- 单个TLP包可以携带多个相同或不同类型的TLP Prefix,所有的Local TLP Prefix须在End-End TLP Prefix之前,否则作为畸形包处理;
- 每个TLP Prefix大小为1DW,可多次重复来负载更多的数据;
- Local及End-End TLP Prefix按照其各自的处理方式进行处理。
1.2.2 Local TLP Prefix处理
Local TLP Prefix中Type字段Type[4]位为0b,用Type[3:0] (L[3:0])作更细的Local TLP Prefix分类,分类如表1所示。
- 各类型的Local TLP Prefix的大小、路由、流控不一而论;
- 若接收者收到了不支持类型的Local TLP Prefix则为出现错误。若设备能力2寄存器(图3)中开启了Extended Fmt Field Supported则按照畸形包处理,并在接收端口处上报错误;若未开启Extended Fmt Field Supported,错误处理方式由设备自行决定;
- Local TLP Prefix不受ECRC的保护,此时其后续TLP仍然可以受ECRC保护。
VendPrefixL0及VendPrefixL1是预留给供应商的两类Local TLP Prefix。为了最大限度地提高这类Local TLP Prefix的互操作性和灵活性,以下规则适用于Local TLP Prefix:
- 组件不可以私自使用这两类Local TLP Prefix,除非其采用了供应商体提供的相关机制;
- 支持VendPrefixL0及VendPrefixL1类型Local TLP Prefix的组件必须支持3bit Fmt并开启Extended Fmt Field Supported;
- 建议在组件中vendPrefix类型可配。
图3 Device Capability 2 Register
1.2.3 End-End TLP Prefix处理
End-End TLP Prefix遵循以下规则:
- End-End TLP Prefix中Type字段Type[4]位为1b,用Type[3:0] (E[3:0])作更细的End-End TLP Prefix分类,分类如表1所示。
- End-End TLP Prefix的最大数目为4,若接收者接收到的End-End TLP Prefix数目大于4,应按照畸形包处理;
- End-End TLP Prefixd的出现不会破该TLP原本的路由规则;
- function支持的最大End-End TLP Prefix数目通过设备能力2寄存器进行配置(图3);
- 支持End-End TLP Prefix的switch应支持转发最高携带4个End-End TLP Prefix的TLP;
- 多个支持End-End TLP Prefix的RP间,支持的最大End-End TLP Prefix数目可以不同;
- 若后续TLP受ECRC保护,则End-End TLP Prefix同样受ECRC保护;
- 若接收者不支持End-End TLP Prefix但收到了带有End-End TLP Prefix的TLP,则为出现错误,按照畸形包处理,接收端口上报错误;
- 软件应确保携带End-End TLP Prefix的TLP不会发给不支持End-End TLP Prefix的组件,因为该组件会曲解End-End TLP Prefix;
- 若上行端口某function支持End-End TLP Prefix但收到了不支持类型的End-End TLP Prefix,该上行端口所有function都应把其收到的地址请求按照UR处理,地址Complition按照CA处理,接收端口上报错误;
- 对于一些其路由作用的元素,若某出端口开启了End-End Prefix Blocking功能,则携带End-End TLP Prefix的TLP会被阻塞在该出端口;一旦被阻塞,不仅是TLP Prefix,整个TLP都会被丢掉,并上报TLP Prefix阻塞错误;若被阻塞的是非转发请求TLP,该出端口会返回一笔完成状态为不支持请求的完成的消息;
- 若某元素开启了组播功能,复制到每一个组播组的TLP都会携带原TLP的End-End TLP Prefix。
VendPrefixE0及VendPrefixE1是预留给供应商的两类End-End TLP Prefix。为了最大限度地提高这类End-End TLP Prefix的互操作性和灵活性,以下规则适用于此类前缀:
组件不可以私自使用这两类End-End TLP Prefix,除非其采用了供应商体提供的相关机制;
建议在组件中verdPrefix类型可配。
📌 支持End-End TLP Prefix的RP
PR间可以选择其是否支持带End-End TLP Prefix的P2P TLP路由,且各自独立实现。若RC支持多个RP间的End-End TLP Prefix路由,则应配置相关RP的设备能力2寄存器开启End-End TLP Prefix Supported能力。
对于RC中所有支持End-End TLP Prefix的RP,RC无需支持所有RP间的End-End TLP Prefix路由。若在一对不支持End-End TLP Prefix的RP之间发起End-End TLP Prefix路由请求,按照UR处理,对应的completion按照UC处理。
所有支持End-End TLP Prefix转发的RP需开启End-End TLP Prefix能力。不同RP支持的最大End-End TLP Prefix可以不同。
若RC为提升RP间P2P路由性能而把一笔较大的TLP拆分成多笔较小的TLP, 拆分后的每一笔TLP都应携带原TLP的End-End TLP Prefix。
1.2.4 TLP Prefix错误记录及处理
接收者接收到带有TLP Prefix的TLP有以下几类错误:
- 有TLP Prefix但没有TLP Header;
- End-End TLP Prefix出现在了Local TLP Prefix之前;
- 出现了不支持类型的Local TLP Prefix类型;
- End-End TLP Prefix的数目超过4笔;
- End-End TLP Prefix的数目超过设置的最大数目。
对于支持TLP Prefix及AER的device function,在开启了TLP Prefix Log Present Bit后,AER机制会把TLP Prefix错误记录到TLP Prefix Log Register,遵循的规则与TLP Header Log Register相同。但⚠️ AER机制仅支持记录End-End类型的TLP Prefix错误 ⚠️,错误记录在TLP Prefix Log register中。Local类型的TLP Prefix错误单独记录在他处,比如MR-IOV TLP Prefix错误直接记录在Mr-IOV结构中,而非记录在AER寄存器中。
Extended Fmt Field Supported位置一时,若不支持TLP Prefix的function收到了带有TLP Prefix的TLP,其把该TLP当作畸形TLP处理,并把TLP前四个DW记录在TLP Header Log寄存器中。
若function收到的End-End TLP Prefix超出了function定义的最大值则报错,并把第一笔溢出的End-End TLP Prefix存入Header Log寄存器的第一个DW中(其余未定义)。
✨2. PASID TLP Prefix
2.1 基本介绍
PASID(Process Address Space ID) ,地址空间ID,是EP的本地ID,每个function都有一组不同的PASID,不同function间的PASID互不相关。带有PASID的TLP Prefix是一种End-End的TLP前缀,PASID与Requester ID一起共同作为请求TLP地址空间的唯一标识。同一PASID在同一系统中可以重复使用。
PASID TLP Prefix能力适用于EP及RCiEP,具备PASID扩展能力的EP支持发送和接收带有PASID TLP Prefix的TLP。PASID仅可用于以下类型的TLP:
- 带有未转换地址的存储器访问请求,包括atomic请求;
- 地址转换请求;
- ATS作废消息;
- 页请求消息;
- 页请求组PRG响应消息。
除以上TLP外的其他TLP不可以采用PASID。
PASID TLP Prefix能力与ATS(Address Translation Services)及PRI(Page Request Interface)相互独立,具备PASID TLP Prefix能力的组件可以不支持ATS或PRI,支持ATS或PRI的组件也可以不支持PASID TLP Prefix。
2.2 软件配置
组件必须实现PASID TLP Prefix能力结构才能使用PASID TLP Prefix能力。PASID TLP Prefix能力结构如图4所示,有PASID TLP Prefix的扩展能力头标、PASID控制寄存器及PASID控制寄存器三部分。
图4 PASID Extended Capability Structure
分别介绍如下:
- PASSID Extended Capability Header:PASID扩展能力头标(图5),用以指明该组件具备PASID扩展能力、扩展能力版本及下一扩展能力的地址偏移。
- PASID Capability Register:PASID能力寄存器(图6),Max PASID Width用以指示该EP支持的最大PASID位宽,范围为[0~20],0表示只支持PASID=0的情况;Priviledged Mode Supported置一时表示支持特权模式,置零表示不支持特权模式;Execute Permission Supported置一表示EP中的Excute Request位可以置一。
- PASID Control Register:PAISID控制寄存器(图7),用以使能PASID、Execute Permisison及特权模式。若相关bit未使能,则PASID能力寄存器中相关配置无效。
图5 PASID Extended Capability Header
图6 PASID Capability Register
图7 PASID Control Register
2.3 PASID TLP Prefix格式
PASID TLP Prefix格式如图8所示。
图8 PASID TLP Prefix
图中各域解释见下表(表2):
表2 PASID TLP Prefix
2.3.1 PASID字段
EP中,PASID字段位宽20bit,实际使用的位宽为PASID能力寄存器中设置的Max PASID Width值,支持的最大PASID值为2Max_PASID_Width-1。RC中也应实现这样一种机制。
若PASID控制寄存器中PASID Enable bit未置一,则EP不能发送及接收带有PASID的 TLP Prefix,接收到带有PASID TLP Prefix的TLP按照UR处理。
RC可以选择性地支持PASID TLP Prefix,且应提供一种机制来检测RC是否支持PASID TLP Prefix。
EP发送和接收带有PASID TLP Prefix的TLP应遵循以下规则:
EP发出的TLP中PASID最大为2^Max_PASID_Width-1;
若EP收到TLP中PASID≥2^Max_PASID_Width,按照UR处理,是否报错是可选的。
RC发送和接收带有PASID TLP Prefix的TLP应遵循以下规则:
RC发送的PASID值不能超出其允许的范围;
若RC收到TLP中PASID超出范围,按照UR处理,是否报错是可选的。
完成者接收带有PASID TLP Prefix的TLP应遵循以下规则:
对于未转换地址的存储器访问请求,PASID和未转换地址一起决定转换后的地址;
对于转换地址的TLP,规则参照ATS规范。
📌 PASID位宽同质性
理论山,每个function的PASID值都是不同的,且PASID位宽也应按照各function的实际需求进行设置。但实际实现时,系统软件往往不遵循改规则,而是在所有的function中都采用相同的PASID访问某块特定地址范围。这种情况下,为了确保改通用的PASID位宽能够正常工作在RC及TA(Translation Agent,转换代理)上,系统软件应关闭热插拔EP或PASID位宽小于通用PASID位宽的TA的ATS服务。
考虑到RC、EP及TA等硬件组件的实现往往独立于系统软件,为实现软硬件友好交互,因此力荐这些硬件实现位宽20bit的PASID。
2.3.2 Execute Requested字段
在PASID能力寄存器及控制寄存器中Execute permission Supported及Execute Permission Enable位均有效(置一)时该Execute Requested位才能置一,若Execute Request位置一,表示该EP请求执行该TLP地址对应的指令。
对于RC,其遵循以下规则:
RC是否支持execute requested是可选的;
支持execute requested的RC应提供一种机制来使能该功能;
支持execute requested的RC可以以RP、Bus Number、Requester ID等为参考实现更细粒度的execute requested位设置。
对于完成者,其遵循以下规则:
完成者对execute requested有效性进行检查,必须在Execute permission Supported、Execute Permission Enable及Execute Requested同时有效时该execute请求才有效;
对于未转换地址的存储器读请求,若完成者检测到请求execute请求无效,完成者把该地址当作空地址(未作映射的地址)处理;
对于未转换地址的存储器请求,除未转换地址读请求之外的其他储存器访问请求,execute requested位预留;
对于地址转换相关的TLP,该execute requested位使用方法请参考ATS服务相关规范。
2.3.3 Privileged Mode Requested字段
只有在EP支持并使能了特权模式时才能启用Privileged Mode Requested,若Privileged Mode Requested位置一,表示该TLP为一笔特权模式的请求。特权与非特权模式介绍请参考:链接。
对于RC,应遵循以下规则:
Privileged Mode Requested对RC是可选配的;
支持Privileged Mode Requested的RC应提供一种机制来使能该功能;
支持Privileged Mode Requested的RC可以以RP、Bus Number、Requester ID等为参考实现更细粒度的Privileged Mode Requested位设置。
对于完成者,其遵循以下规则:
完成者对execute requested有效性进行检查,必须在Execute permission Supported、Execute Permission Enable及Execute Requested同时有效时该execute请求才有效;
对于未转换地址的存储器读请求,若完成者检测到请求execute请求无效,完成者把该地址当作空地址(未作映射的地址)处理;
对于地址转换相关的TLP,该execute requested位使用方法请参考ATS服务相关规范。
2.4 PASID TLP Prefix使用管理
只有开启了PASID能力的组件才能使用PASID TLP Prefix,否则不能发送和接收带有PASID的TLP Prefix。
EP/RCiEP中的function在使用PASID TLP Prefix时需遵循以下规则:
只有实现了PASID能力结构且使能了PASID的function才能发送或接收带有PASID TLP Prefix的TLP;
function需有一套机制来将该function云内的PASID动态关联起来,该机制由设备指定;
function需有一套机制来请求停止使用某特定PASID。
RC中的function在使用PASID TLP Prefix时需遵循以下规则:
RC需有设备指定的机制来指示该function支持PASID TLP Prefix;
支持PASID TLP Prefix的RC需有一套机制来开启PASID TLP Prefix;
支持PASID TLP Prefix的RC可以选择行地由设备指定更多PASID相关规则,比如对不同RP、Requester、Bus等分别控制PASID使能,实现更精细的控制。
📚参考
PCI Express Base Specification Revision 5.0 Version 1.0 (22 May 2019)
PCI Express Technology - Comprehensive Guide to Generation1.x, 2.x and 3.0. Mike Jacson, Ravi Budruk, MindShare, Inc.