【PCIe】FLR应用

声明：

• 文章目的在于学习记录，知识分享。因个人能力有限：如有错误之处，请帮忙指出；如有疑问，欢迎随时交流。
• 感谢“点评赞”，期待大家提出问题进行深度讨论。
• 如有侵权，请随时联系。

应用场景

FLR存在如下应用场景：

● 控制某个Function的软件可能会遇到问题，并且已无法正常运行。防止数据损坏需要重置该Function，但该设备内的其他Function仍然正常工作，此时只需要reset有问题的Function。

● 在虚拟化环境中，应用程序可以从一个硬件迁移到另一个硬件。当应用程序从此Function 移除时，希望清除Function上关于此应用程序的information，以避免机密消息泄露。最简单方式是完成APP迁移后进行function reset。

● 当软件为Function重建软件堆栈时，有时需要首先将此Function放入未初始化状态。此时进行FLR，不会影响到公用链路的其他function。

● 服务器上电时，有些版本的固件会尝试对支持FLR功能的Endpoint进行FLR，如果Endpoint没有在规定时间内完成FLR操作，会导致服务器启动失败。

复位作用范围

1. FLR 会复位对应 Function 的内部状态，寄存器，需要重点关注如下寄存器：bme、mse、mrrs,10bit_tag_en,ser_en,ecrc_gen_en,sriov_ctl_vf_en。这些寄存器会影响TL层和用户逻辑对TLP的处理，例如，bus master en（bme）为0时，不允许Endpoint发起mwr、mrd请求，即俗称的dma请求。如果用户逻辑实现了此类控制寄存器（例如使用寄存器对信号打拍），在FLR复位期间，需要将此类寄存器进行清零。

2. FLR 会复位对应 Function 的内部状态，寄存器，但是以下寄存器不会受到影响：Sticky bits（cold reset 和 warm reset 也对其不起作用）hardware‐initialized bits（HwIint 类型的寄存器。在 PCIe 设备中，Vendor ID和Device ID 以及Device Capabilities 2 Register中的10-Bit Tag Requester Supported等等通常都是HwInit类型寄存器。常见的设计实现中，此类寄存器通常是由用户逻辑实现的可配置寄存器，连接到PCIe ctrl的输入接口上。）link‐specific 寄存器，比如 Captured Power, ASPM Control, Max_Payload_Size 或者 Virtual Channel。

3. FLR 不会改变 Device 的 LTSSM 状态。

NOTE: FLR复位function时，要求与function关联的外部活动停止；If an outstanding Assert INTx interrupt message was sent, a corresponding Deassert INTx message must be sent 。

---

FLR 流程要求与复位时间

协议规定一个FLR需要在 100ms 内完成。但是软件在启动 FLR 前，要注意是否有还没返回的CplD，遇到这种情况，要么等这些 CplD 返回再开始 FLR，要么启动 FLR 以后等 100ms 以后再重新初始化这个 Function。这种情况如果没有处理好，可能会导致 data corruption: 前一批请求的返回报文被当做了后一批请求的返回报文。为了避免此类问题，协议要求软件进行FLR时需要满足如下要求：

1. 与其他可能访问该功能的软件进行协调，以确保它在FLR期间不会尝试访问。

2. 清除整个命令寄存器，从而停止Function。

3. 通过轮询Transactions Pending bit（in the Device Status register）被清零来确保先前请求的完成报文已返回，或等待足够长的时间来确保完成报文不会返回。（多久才够长了？如果正在使用完成超时，请等待超时时间后再发送FLR。如果禁用了超时，那么至少等待100ms）

4. 启动FLR并等待100ms（此处的100ms确保）。

5. 设置Function的配置寄存器，最后配置command enable使能，使其正常工作。

FLR复位期间，Endpiont需要遵守的规则

在FLR复位期间，function的行为需要满足协议如下规定：Function 必须为产生FLR的配置写返回一个CPLD，然后启动FLR。在FLR复位期间，接收到的完成报文被视为Unexpected Completions或者直接丢弃，既不记录也不报错。在外部接口上，此Function体现为非活跃状态，不能响应请求。如何设计可以自定义，协议没有规定。（例如，在用户侧接口，如果收到dma请求，则返回err ack）Function不能保留任何软件可读的状态，这些状态可能包括Function留下的秘密信息。例如，internal memory必须清零或者随机化。下一个驱动程序必须可以正常地配置该Function 。在FLR复位期间，function的对报文的响应需要满足如下要求：FLR操作必须在100ms内完成，但之后的初始化可能需要更长的时间。如果在初始化完成之前出现了配置请求，则该Function 必须返回一个带有CRS（Configuration Retry Status）状态的完成报文。一旦完成返回任何其他状态，CRS状态将不再合法，直到功能重新重置。Function收的mwr/mrd请求允许直接丢弃，而且不记录，也不产生错误信号。不过，Flow control credits must be updated to maintain the link operation.

退出复位

退出复置状态后，链路训练和初始化必须在20ms内开始。不同的设备可能在不同的时间退出复置状态，因为复置信号是异步的，且必须在这段时间内开始训练。被复位的组件需要执行内部初始化，系统软件在reset结束后至少等待100ms，才能向它们发起配置请求。如果软件在100ms等待时间之后向设备启动配置请求，但设备仍未完成自动初始化，设备会返回状态为CRS的完成报文。由于配置请求只能由CPU启动，所以状态为CRS的完成TLP将传送到到RC。作为响应，Root 可以自动重新发出配置请求或使故障对软件可见。该规范还指出，如果CRS Software Visibility已经启用，软件应该等待100个ms后就重新发起配置请求，避免长时间超时或处理器暂停。设备在reset后1.0秒内（0%/+50%）必须对配置请求作出适当的响应，否则系统会认为此device已经损坏。

本文完，感谢大家阅读！