PCIe prefix总结

这周研究了一下spec中关于prefix的部分，在此做一个总结，欢迎大家指正补充。

TLP Prefix基本介绍

• TLP 第 0 字节的 Fmt [2:0] 字段值为 100b 表示当前 DW 为 TLP Prefix 。

• TLP Prefix 分为两大类： Local 和 End-End ，其中 Local TLP Prefix 用以在 PCIe 链路两侧传递信息， End-End 用以在 Requester 和 Completer 之间传递信息。

• 通过 Type 字段 第 [4]bit 来加以区分， 0 为 Local TLP Prefix ， 1 为 End-End TLP Prefix 。

• 允许一个 TLP 包含 多个 任何类型的 TLP 前缀

• 当 TLP 中存在 Local 和 End-End TLP 前缀的组合时，需要所有 Local TLP 前缀位于任何 End-End TLP 前缀 之前 。

• 每个 TLP 前缀的大小为 1DW 。

下图为prefix基本组成。

下图为Type编码及对应的prefix类型

Local TLP Prefix处理

• Local TLP Prefix 中 Type 字段 Type[4] 位为 0b ，用 L[3:0] 作更细的 Local TLP Prefix 分类。

• 各类型的 Local TLP Prefix 的大小、路由、流控不一而论。

• 若接收者收到了不支持类型的 Local TLP Prefix 则为出现错误。若设备能力 2 寄存器中开启了 Extended Fmt Field Supported 则按照畸形包处理，并在接收端口处上报错误。若未开启 Extended Fmt Field Supported ，错误处理方式由设备自行决定。

    Local TLP Prefix不受ECRC的保护，此时其后续TLP仍然可以受ECRC保护

下图为Local TLP prefix类型

“VendPrefixL0”和“VendPrefixL1”类型保留作为厂商自定义的本地TLP前缀。为了最大限度地提高互操作性和灵活性，以下规则应用于这些前缀:

    •组件不得发送包含供应商定义的本地TLP前缀的TLP，除非已明确启用(使用供应商特定的机制)。

    •支持任何供应商定义的本地TLP前缀的组件必须支持Fmt字段的3位定义，并具有扩展Fmt字段支持位集。

    •建议组件是可配置的(使用供应商特定的机制)，以便所有供应商定义的前缀都可以使用两种供应商定义的本地TLP前缀编码中的任何一种发送。这样的配置不必是对称的(例如，链路的每一端可以使用不同的编码传输相同的前缀)

下图为Extended Fmt Field Supported 字段所在寄存器位置。

Extended Fmt Field Supported : If Set, the Function supports the 3-bit definition of the Fmt field. If Clear, the Function supports a 2-bit definition of the Fmt field. Must be Set for Functions that support End-End TLP Prefixes. All Functions in an Upstream Port must have the same value for this bit. Each Downstream Port of a component may have a different value for this bit.It is strongly recommended that Functions support the 3-bit definition of the Fmt field.

End-End TLP Prefix处理

• End-End TLP Prefix 中 Type 字段 Type[4] 位为 1b ，用 E[3:0] 作更细的 End-End TLP Prefix 分类。

• End-End TLP Prefix 的 最大数目为 4 ，若接收者接收到的 End-End TLP Prefix 数目大于 4 ，应按照畸形包处理。

• End-End TLP Prefixd 的出现不会改变该 TLP 原本的路由规则。

• Function 支持的最大 End-End TLP Prefix 数目通过 Device Capabilities 2 register 的 Max End-End TLP Prefixes field 进行配置；

• 支持 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

下图为End-End TLP prefix类型

还没写完，发现总结的文档没带回来，后面补上。

来补坑了。接着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 的 Device Capabilities 2 Register 开启 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 。

TLP Prefix Logging

Receiver接收到带有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相同。 (当First Error Pointer有效时，TLP前缀日志和Header日志寄存器总是对应First Error Pointer中显示的错误)。

• TLP Prefix Log Present 位表示 TLP Prefix Log 寄存器中包含信息。

• AER 机制仅支持记录 End-End 类型的 TLP Prefix 错误 ，错误记录在 TLP Prefix Log register 中。 Local 类型的 TLP Prefix 错误单独记录在他处，比如 MR-IOV TLP Prefix 错误直接记录在 Mr -IOV 结构中，而非记录在 AER 寄存器中。  

• End-End TLP 前缀记录在 TLP 前缀日志寄存器中。底层的 TLP 报头记录在报头日志寄存器中，但有两种情况例外 :

ü     如果设置了 Extended Fmt Field Supported bit ，一个不支持 TLP 前缀的 Function 接收到一个包含 TLP 前缀的 TLP ，将发出畸形 TLP 信号， the Header Log register 将包含 该 TLP 的前四个 DW (TLP 前缀后跟尽可能多的 TLP 报头 ) 。

ü     如果一个 Function 收到的 TLP 包含的 End-End TLP 前缀数 超过了 Function 的 Max End-End TLP 前缀数 ，则必须将该 TLP 作为错误处理，并将 第一个溢出 的 End-End TLP 前缀存储在 Header Log 寄存器的第一个 DW 中 ， Header Log 寄存器的其余部分未定义。

以下各图分别为： TLP Prefix Log Register，TLP Prefix Log Present Bit所在寄存器及该位解释，First Error Pointer 位所在寄存器及该位解释。

TLP Prefix 错误

脑洞一下

假设传输路径为 RC-USP-DSP-EP （ RC-SW-EP ）， 前缀组成为 LELE(Local---End

-End--- Local---End-End前缀交替出现)的前缀在何处处理（EP/SW?），怎么处理？

该错误的类型为Malformed TLP     Transaction Layer Errors       Uncorrectable (Fatal)

处理方式是:

Receiver:Send ERR_FATAL to Root Complex.Log the prefix/header of the TLP

that encountered the error.

故，在EP处作为畸形包处理；

在SW处正常报错，但不处理？还是不检测？（本人倾向于后者）

（此问题不确定，欢迎讨论）

PASID TLP Prefix

• 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 ：

            带有未转换地址的Memory Requests ，包括Atomic请求；（Memory Requests (including AtomicOp Requests) with Untranslated Addresses）

            地址转换请求(Address Translation Requests）

            ATS作废Message（ATS Invalidation Messages）

            页请求Message（Page Request Messages）

            页请求组PRG响应消息（PRG Response Messages ）

PASID TLP Prefix能力与ATS（Address Translation Services）及PRI（Page Request Interface）相互独立，具备PASID TLP Prefix能力的组件可以不支持ATS或PRI，支持ATS或PRI的组件也可以不支持PASID TLP Prefix。

一个TLP最多只能包含一个PASID TLP前缀。

PASID Extended Capability Structure

组件必须实现PASID TLP Prefix能力结构才能使用PASID TLP Prefix能力。有PASID TLP Prefix的扩展能力头标、PASID控制寄存器及PASID能力寄存器三部分。

• PASSID Extended Capability Header ： PASID 扩展能力头标，用以指明该组件具备 PASID 扩展能力、扩展能力版本及下一扩展能力的地址偏移。

• PASID Capability Register ： PASID 能力寄存器， Max PASID Width 用以指示该 EP 支持的最大 PASID 位宽，范围为 [0~20] ， 0 表示只支持 PASID=0 的情况； Priviledged Mode Supported 置一时表示支持特权模式，置零表示不支持特权模式； Execute Permission Supported 置一表示 EP 中的 Excute Request 位可以置一。

• PASID Control Register ： PAISID 控制寄存器，用以使能 PASID 、 Execute Permisison 及特权模式。若相关 bit 未使能，则 PASID 能力寄存器中相关配置无效

以下各图为 PASID Extended Capability Structure组成，及各部分内部组成及解释。

PASID field

• PASID 字段的宽度为 20 位 。 EP 和 RC 不需要支持整个域范围。对于 EP ，最大 PASID 宽度字段表示支持的 PASID 值范围。对于 RC ，使用特定于实现的机制来提供此信息。

• 除非设置了 PASID enable bit, 否则 EP 不允许发送带有 PASID TLP 前缀的 TLP 。

• 支持 PASID TLP 前缀的 EP 在接收到带有 PASID TLP 前缀且 PASID Enable 位为 Clear 的 TLP 时，必须发出 Unsupported Request ( UR ) 信号。

• RC 可以选择支持带有 PASID TLP 前缀的 TLP 。检测 RC 是否支持 PASID TLP 前缀的机制取决于具体实现。

• 对于 EP ，以下规则适用 :

ü     EP 不允许发送 PASID 值大于或等于 2 Max PASID Width 的 tlp 。

ü    当接收到一个 PASID 值大于或等于 2 Max PASID Width 的请求时，按照 UR 处理。 EP 可选择允许发出错误信号。

• 对于 RC ，遵循以下规则 :

ü     RC 不允许发送超过其支持的 PASID 值的 TLP 。

ü     当 RC 接收到一个 PASID 值大于它所支持的值的请求时，按照 UR 处理。是否报错可选。

ü For Completers , the following rules apply:

n        对于 Untranslated 的内存请求， PASID 值和 Untranslated 的地址一起用于确定满足请求的 translated 地址。

        对于地址translated相关的tlp，该字段的使用在ATS中定义

PASID位宽同质性  

    理论上，每个function的PASID值都是不同的，且PASID位宽也应按照各function的实际需求进行设置。但实际实现时，系统软件往往不遵循该规则，而是在所有的function中都采用相同的PASID访问某块特定地址范围。

    这种情况下，为了确保改通用的PASID位宽能够正常工作在RC及TA（Translation Agent，转换代理）上，系统软件应关闭热插拔EP或PASID位宽小于通用PASID位宽的TA的ATS服务。

    考虑到RC、EP及TA等硬件组件的实现往往独立于系统软件，为实现软硬件友好交互，因此力荐这些硬件实现位宽20bit的PASID。

Execute Requested

  在PASID能力寄存器及控制寄存器中Execute permission Supported及Execute Permission Enable位均有效时该Execute Requested位才能置一，若Execute Request位置一，表示该EP请求执行该TLP地址对应的指令

For RC,the following rules apply:

• 支持由 RC 请求的执行是 可选的 。用于确定 RC 是否支持执行请求的机制是特定于实现的。

• 支持 Execute Requested bit 的 RC 应该有一个特定的实现机制来允许 它使用该位。

• 支持 Execute Requested bit 的 RC 可能具有特定的实现机制，以便在更细的粒度上使用该位 (e.g., for a specific Root Port, for a specific Bus Number, for a specific Requester ID, or for a specific Requester ID/PASID combination), 它的默认值是特定于实现的。

• For Completers, the following rules apply:

• Completer 对 execute requested 有效性进行检查，必须在 Execute permission Supported 、 Execute Permission Enable 及 Execute Requested 同时有效时该 execute 请求才有效

• 对于给定的请求，如果支持执行请求位，并且该请求启用了它的使用，则该位的有效值是请求中的值 ; 否则该位的有效值为 0b 。

• 对于 Untranslated Memory Read Requests ， Completers 使用该位的有效值作为保护检查的一部分。如果此保护检查失败，则 Completers 将请求视为未映射内存（空地址）。

• 对于 Untranslated 的内存请求，除了 Untranslated Memory Read Requests ，这个位是保留的。

Privileged Mode Requested

只有在EP支持并使能了特权模式时才能启用Privileged Mode Requested，若Privileged Mode Requested位置一，表示该TLP为一笔特权模式的请求。

For Root Complexes, the following rules apply:

• Root Complex 是否支持 Privileged Mode Requested bit 是可选的。用于确定 RC 是否支持 e Privileged Mode Requested bit 的机制是特定于实现的。

• 支持 Privileged Mode Requested bit 的 RC 应该有一个特定的实现机制来允许它使用该位

• 支持特权模式请求位的 RC 可能具有特定的实现机制，以便在更细的粒度上使用该位 , (e.g., for a specific Root Port, for a specific Bus Number, for a specific Requester ID, or for a specific Requester ID/PASID combination).

• For Completers, the following rules apply:

• 完成者对 Privileged Mode Requested 有效性进行检查，必须在 Privileged Mode Supported 、 Privileged Mode Enable 及 Privileged Mode Requested 同时有效时该 execute 请求才有效；

• 对于一个给定的请求，如果特权模式请求位被支持并且它的使用为请求启用，则该位的有效值是请求中的值 ; 否则该位的有效值为 0b 。

• 对于 Untranslated Memory Requests ， Completers 使用该位的有效值作为保护检查的一部分。如果此保护检查失败，则 Completers 将请求视为未映射内存。

PASID TLP Prefix 使用管理

只有开启了PASID能力的组件才能使用PASID TLP Prefix，否则不能发送和接收带有PASID的TLP Prefix。

RC中的function在使用PASID TLP Prefix时需遵循以下规则：

• RC 必须具有设备特定的机制来表示对 PASID TLP 前缀的支持。

• 支持 PASID TLP 前缀的 RC 必须具有 特定于设备的使能机制 。

缺省情况下，不允许使用PASID TLP前缀。

• 支持 PASID TLP 前缀的 RC 可以选择具有特定于设备的机制，以更细的粒度启用它们 . (e.g., distinct enables for a specific Root Port,Requester ID, Bus Number, Requester ID, or Requester ID/PASID combination).

EP/RCiEP中的function在使用PASID TLP Prefix时需遵循以下规则：

• 只有实现了 PASID 能力结构且使能了 PASID 的 function 才能发送或接收带有 PASID TLP Prefix 的 TLP ；

• function 需有一套机制来将该 function 云内的 PASID 动态关联起来，该机制由设备指定；

• function 需有一套机制来请求停止使用某特定 PASID

◦一个Function可能同时支持有限数量的PASID停止请求。软件应该延迟发出新的停止请求，直到旧的停止请求完成。

◦一个function中的停止请求不能影响任何其他函数的运行。

◦停止请求不得影响Function内任何其他PASID的操作。

◦停止请求不能影响与PASID无关的事务的操作

◦当停止请求机制指示完成时，该function已：

    ▪ Stopped queuing new Requests for this PASID.

    ▪ Completed all Non-Posted Requests associated with this PASID.

    ▪ Flushed to the host all Posted Requests addressing host memory in all TCs that were used by the PASID. The mechanism used for this is device specific (for example: a non-relaxed Posted Write to host memory or a processor read of the Function can flush TC0; a zero length read to host memory can flush non-zero TCs).

    ▪ Optionally flushed all Peer-to-Peer Posted Requests to their destination(s). The mechanism used for this is device specific.

TLP Prefix Register

以下主要针对prefix涉及到的寄存器及字段进行介绍

欢迎补充讨论。