✨ 1. 背景介绍

Readiness Notification，缩写为RN，PCIe 3.1提出并在PCIe 4.0时正式引入。在未使用CRS（Configuration Request Retry Status）时，PCIe设备启动或复位后要等1s左右的时间软件才能发送配置请求，启动CRS后将这个时间缩减到了100ms左右。但CRS使用起来比较繁琐，RN机制在CRS基础上更进一步，是一种更为简便的通知机制，同样能够减少PCIe Device/Function 启动或复位到软件发送配置请求间的等待时间。

 RN机制包括两种通知机制：DRS消息（Device Readiness Status） 和 FRS消息（Function Readiness Status）。该机制是Device/Function进入Configuration-Ready状态的直接标志。

 ✔️ 在PCIe系统实现过程中，强烈建议firmware/software减少一切不必要的延时 ❗️❗️❗️

 ✔️ 强烈建议硬件设计能够舍弃或尽可能减少时延需求，充分利用RN机制提供的便利，依据RN通知来决定所需的时延 ❗️❗️❗️

💡 注：

Configuration-Ready，Function能够对其收到的配置请求回复以带有Success状态的有效Completion，则该Function为Configuration-Ready状态。

✨ 2. DRS消息

2.1 DRS触发事件

DRS用以指示Device进入了Configuration-Ready状态。以下Device-Level的事件用以触发DRS，称为为DRS事件：

       设备退出冷复位

       设备退出暖复位、热复位、回环，或设备被关闭

       设备退出L2、L3完毕

       其他场景，例如端口由DL_Down变为DL_Up状态

💡 注：

DL_Down：DL层通知Transaction层当前端口对端未检测到其他设备；

DL_Up：DL层通知Transaction层当前PCIe链路已连接其他设备。

2.2 DRS消息格式

  DRS协议采用PCI-SIG定义的VDM（Vender-Defined-Mechanism）机制，DRS消息是一种没有数据载荷的Type 1类型的VDM消息，其帧格式如图1所示。

图1 DRS消息帧格式

 DRS消息的TLP Type为Msg，Fmt为001b，Type为10100b（目的为Local或Receiver），TC[2:0]为000b，Attr[2:0]及Tag字段预留，Message Code为01111111b，Vender ID为0001h，Subtype字段为08h。

 ⚠️ 注意：在未分配Bus Number时Function发出DRS消息是合法的，该DRS消息Requester ID中的Bus Number为0。若此时Switch下行端口开启了ACS来源验证，该消息有可能会触发ACS违例报错。

2.3 DRS协议规则

  DRS消息协议遵循以下规则：

• DRS没有开关机制。对于支持DRS的下行端口而言，其链路能力2寄存器的DRS Supported位必须为1（图2）；对于上行端口而言，同样建议将其链路能力2寄存器的DRS Supported位置1，即便该位为0，上行端口也能够发送DRS消息 ✔️。

• 端口由DL_Down变为DL_Up状态且当前Logical Bus上跟该上行端口相关的所有非VF Function都Ready之后，DRS消息必须由具备DRS能力的上行端口发出。对Type 0类型的 Function及非Switch上行端口的Type 1类型Function而言，该Function进入Configuration-Ready后该Function即Ready；对Switch上行端口的Type 1类型Function而言，该Function及其所有二级bus的Function均为Configuration-Ready时，该Function才Ready。

• Device发出DRS消息后，除非发生了DRS事件，否则跟该DRS对应的Configuration-Ready的非VF Function不应返回CRS Completion消息。

• 实现了DRS的Switch，所有端口都应支持DRS机制。对Switch下行端口下游的Device而言，Switch发出的DRS消息并不意味着这些Device Ready了，这些Device是否Ready是独立于Switch的。

• Switch下行端口及RP中需实现DRS Message Received位，以指示其接收到了DRS消息。

图2 Link Capabilities 2 Register  

✨ 3. FRS消息

3.1 FRS触发事件

FRS用以指示Function进入了Configuration-Ready状态。以下Function-Level的事件用以触发FRS，称为FRS事件：

• Function Level复位（FLR）

• D3_Hot到D0转换完成

• SR-IOV系统中PF开启或关闭VF功能

3.2 FRS消息格式

  同DRS一样，FRS协议采用PCI-SIG定义的VDM机制，FRS消息是一种没有数据载荷的Type 1类型的VDM消息，其帧格式如图3所示。

图3 FRS消息格式

 FRS消息的TLP Type为Msg，Fmt为001b，Type为10000b（路由到RC），TC[2:0]为000b，Attr[2:0]及Tag字段预留，Message Code为01111111b，Vender ID为0001h，Subtype字段为09h。FRS Reason字段用以指示产生FRS消息的原因，如

表1所示。

表1 FRS Reason  

DRS消息的接收者可有选择性地对消息各字段有效性进行检查确认，若检查不通过则当作畸形包处理。

3.3 FRS协议规则

  FRS消息协议遵循以下规则：

• FRS消息的Requester ID需指示Readiness状态发生变化的Function。

• FRS消息中的FRS reason字段需指示Function Readiness状态发生变化的原因。

• Function发出FRS消息后，除非发生DRS或FRS事件，该Function不应返回CRS Completion消息。

• 实现了FRS的Switch，所有端口都应支持FRS机制，且上行端口应能够发送FRS消息。

• SR-IOV系统中PF开启或关闭VF功能时，PF应上行发送FRS消息。

• RP及RC中应实现FRS排队扩展能力，以收集FRS消息。

✨ 4. FRS消息队列

4.1 FRS消息规则

支持FRS机制的RP及RC事件收集器中必须实现FRS队列扩展能力结构。对RP而言，器FRS消息队列中包含了该RP收到及发出的FRS消息。对RC而言，其FRS消息队列中包含了该RC事件收集器发出及其相关RCiEP发出的FRS消息。

  FRS队列满足以下需求：

• Reset之后FRS消息队列需为空。

• 链路比那位DL_Down后RP的FRS消息对应需为空。

• 若收到FRS消息后或生成FRS消息过程中FRS消息队列非满，需将FRS消息压入队列并将FRS消息接收指示位置一。

• 若收到FRS消息后或生成FRS消息过程中FRS消息队列已满，则丢弃该FRS消息并将FRS消息溢出位置一。

• 最陈旧的FRS消息需体现在FRS消息队列寄存器中。

• 写FRS消息队列寄存器时需移除队列中最陈旧的元素。

• FRS消息接收指示或溢出位由0变1时，若支持中断应产生对应中断。

4.2 FRS队列扩展能力结构

  FRS队列扩展能力结构如图4所示，该结构中各寄存器释义如下：

• FRS Queueing Extended Capability Header，FRS队列扩展能力头标（图5），用以指示该组件具备FRS队列能力、能力版本及下一能力的地址偏移。

• FRS Queueing Capability Register，FRS队列能力寄存器（图6），用以指示FRS消息队列的最大深度及FRS中断的消息号。FRS深度最低为1，可配置的最大深度为4095。

• FRS Queueing Status Register，FRS队列状态寄存器（图7），用以指示接收到了FRS消息或FRS消息队列溢出。

• FRS Queueing Control Register，FRS队列控制寄存器（图8），用以开启FRS中断。

• FRS Message Queue Register，FRS消息队列寄存器（图9），RC/RP事件收集器中既有的最陈旧的FRS消息的Requester ID记录在FRS Message Queue Function ID字段，FRS Reason记录在FRS Message Queue Reason字段。FRS Message Queue Depth用以指示当前队列中的FRS消息数目，0代表队列为空。

图4 FRS Queueing Extended Capability  

图5 FRS Queueing Extended Capability Header  

图6 FRS Queueing Capability Register  

图7 FRS Queueing Status Register  

图8 FRS Queueing Control Register  

图9 FRS Message Queue Register  

📚 参考

   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.

   PCIe® 3.1 & M-PCIe™ Protocol