热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

PCIe系统复位

PCIe总线中定义了四种复位名称:冷复位(ColdReset)、暖复位(WarmReset)、热复位ÿ

PCIe总线中定义了四种复位名称:冷复位(Cold Reset)、暖复位(Warm Reset)、热复位(Hot Reset)和功能层复位(Function-Level Reset,FLR)。其中FLR是PCIe Spec V2.0加入的功能,因此一般把另外三种复位统称为传统的复位方式(Conventional Reset)。其中冷复位和暖复位是基于边带信号PERST#的,又被统称为基本的复位方式(Fundamental Reset)。


Fundamental Reset

基本复位由硬件自动处理,会复位整个PCIe设备,初始化所有与状态机相关的硬件逻辑,端口状态以及配置空间中的配置寄存器等等。但是,也有一个例外,就是前面介绍PCIe错误报告机制的相关文章中提到过Sticky(不受复位影响)的概念。这里指的不受复位影响的前提是,PCIe设备的电源并未被完全切断。Sticky这一功能有助于系统定位错误与分析错误起因。


Cold Reset

基本复位中的冷复位(Cold Reset)指的是因为主电源断开后重新连接导致的复位。需要注意的是,即使主电源断开了,如果PCIe设备仍有辅助电源Vaux为其供电,该复位仍不会影响到Sticky的bits。

PCIe Spec允许两种实现基本复位的方式。一是直接通过边带信号PERST#(PCI Express Reset),比如PCIe设备在主电源被切断时,IO Controller Hub (ICH)会自行产生一个复位信号(比如从L2恢复出来的情况)。
二是不使用边带信号PERST#,那么device需要自己检测自己的power state,并产生自己的Fundamental Reset。
image.png


Warm Reset

暖复位(Warm Rest)是可选的,指的是在不关闭主电源的情况下,产生的复位。然而,PCIe Spec并未明确规定暖复位的产生机制,因此,如果产生暖复位完全是由系统设计者决定的。


Hot Reset

热复位(Hot Reset)是一种In-band 复位,其并不使用边带信号。PCIe设备通过向其链路(Link)相邻的设备发送数个TS1 Ordered Set(其中第五个字符的bit0为1),如下图所示。这些TS1OS在所有的通道(Lane)上同时发送,并持续2ms左右。
image.png
主要注意的是,如果Switch的Upstream端口收到了热复位,则会将其广播至所有的Downstream端口,并复位其自己。如果PCIe设备的Downstream端口接收到热复位,则只需要复位其自己即可。如下图为switch A的只复位左侧一个downstream port。
在这里插入图片描述
如下图为switch B的upstream port收到hot reset,则两个downstream port均被复位。
在这里插入图片描述

当PCIe设备接收到热复位后,LTSSM会进入Recovery and Hot Reset状态,然后返回值Detect状态,并重新开始链路初始化训练。其该PCIe设备的所有状态机,硬件逻辑,端口状态和配置空间中的寄存器(除了Sticky bits)都将被初始化值默认状态。

软件可以通过向桥设备的,特定端口的配置空间中的二级总线复位(Secondary Bus Reset)bit先写0再写1,来产生热复位,如下图所示:
需要注意的是,如果软件设置的是Switch的Upstream端口的二级总线复位bit,则该Switch会往其所有的Downstream端口广播热复位信号。而PCIe-to-PCI桥则会将接收到的热复位信号转换为PRST#置位,发送给PCI设备。
二级总线复位(Secondary Bus Reset)bit在配置空间的位置如下图所示:
image.png


Disable

PCIe Spec还允许软件禁止某个链路(Link),强制使其进入电气空闲状态(Electrical Idle)。如果将某个链路禁止,则该链路所有的下游PCIe设备都将收到链路禁止信号(通过TS1OS,如下图所示)。
image.png
在这里插入图片描述


Function Level Reset

PCIe总线自V2.0加入了功能层复位(Function Level Reset,FLR)的功能。该功能主要针对的是支持多个功能的PCIe设备(Multi-Fun PCIe Device),可以实现只对特定的Function复位,而其他的Function不受影响。当然,该功能是可选的,并非强制的,软件可以通过查询配置空间中的设备功能寄存器(Device Capability Register)来查询该PCIe设备是否支持FLR。如下图所示:
在这里插入图片描述

并可以通过设备控制寄存器(Device Control Register)中的将Initiate Function Level Reset bit置1,来产生FLR。
在这里插入图片描述

FLR只复位对应Function的内部状态和寄存器(使其暂时不变化,Making it quiescent),但是并不影响Sticky bits、有硬件初始化的值(Hardware-initialized bits)和链路专用寄存器(比如Captured Power,ASPM Control、Max Payload Size以及VC等寄存器)。如果该设备在FLR前,发出了Assert INTx中断消息,必须在开始FLR之前在发出对应的Deassert INTx消息,除非该INTx已经被与其他Function共享了。当收到FLR后,该Function的所有的其他功能都应被立即停止(Required to cease)。

此外,PCIe Spec还明确给出了FLR的完成时间应在100ms以内。

PCIe Spec还明确规定了,当某个Function处于FLR状态时的一些特性:

· 该Function不能有任何与外界通信的(外部)接口;

· 该Function必须将任何软件可读取的状态(可能包括加密信息等)打乱。换句话说,任何内部存储都必须被清零或者随机化;

· 该Function必须可以被另一个Diver配置为一般模式;

· 该Function必须为其收到的包含有FLR信息的配置写(Configuration Write)返回一个Completion,然后再进行FLR操作。

在进入FLR状态后,还需要:

· 该Function接收到的任何请求都应该被直接丢弃,且不登记(Logging),也不报错误。但是FC Credits必须要被更新,以维持链路的正常操作;

· 该Function接收到的任何Completion都应该被当做Unexpected Completions,然后直接丢弃,且不登记,也不报错。

An FLR causes a Function to lose track of any outstanding non-posted Requests. Any corresponding Completions that later arrive are referred to as being “stale”. If software issues an FLR while there are outstanding Requests, and then re-enables the Function for operation without waiting for potential stale Completions, any stale Completions that arrive afterwards may cause data corruption by being mistaken by the Function as belonging to Requests issued since the FLR. Software can avoid data corruption from stale Completions in a variety of ways. Here’s a possible algorithm:


  1. Software that’s performing the FLR synchronizes with other software that might potentially access the
    Function directly, and ensures such accesses do not occur during this algorithm.
  2. Software clears the entire Command register, disabling the Function from issuing any new Requests.
  3. Software polls the Transactions Pending bit in the Device Status register either until it is clear or until it has been long enough that software is reasonably certain that Completions associated with any remaining outstanding Transactions will never arrive. On many platforms, the Transactions Pending bit will usually clear within a few milliseconds, so software might choose to poll during this initial period using a tight software loop. On rare cases when the Transactions Pending bit does not clear by this time, software will need to poll for a much longer platform-specific period (potentially seconds), so software might choose to conduct this polling using a timer-based interrupt polling mechanism.
  4. Software initiates the FLR.
  5. Software waits 100 ms.
  6. Software reconfigures the Function and enables it for normal operation.

参考资料

PCIe扫盲——复位机制介绍(Fundamental & Hot)
PCIe扫盲——复位机制介绍(FLR)


推荐阅读
  • MySQL 数据库迁移指南:从本地到远程及磁盘间迁移
    本文详细介绍了如何在不同场景下进行 MySQL 数据库的迁移,包括从一个硬盘迁移到另一个硬盘、从一台计算机迁移到另一台计算机,以及解决迁移过程中可能遇到的问题。 ... [详细]
  • 本文深入探讨了 Java 中的 Serializable 接口,解释了其实现机制、用途及注意事项,帮助开发者更好地理解和使用序列化功能。 ... [详细]
  • 基于KVM的SRIOV直通配置及性能测试
    SRIOV介绍、VF直通配置,以及包转发率性能测试小慢哥的原创文章,欢迎转载目录?1.SRIOV介绍?2.环境说明?3.开启SRIOV?4.生成VF?5.VF ... [详细]
  • 本文介绍如何使用 Android 的 Canvas 和 View 组件创建一个简单的绘图板应用程序,支持触摸绘画和保存图片功能。 ... [详细]
  • 本文基于刘洪波老师的《英文词根词缀精讲》,深入探讨了多个重要词根词缀的起源及其相关词汇,帮助读者更好地理解和记忆英语单词。 ... [详细]
  • DNN Community 和 Professional 版本的主要差异
    本文详细解析了 DotNetNuke (DNN) 的两种主要版本:Community 和 Professional。通过对比两者的功能和附加组件,帮助用户选择最适合其需求的版本。 ... [详细]
  • 360SRC安全应急响应:从漏洞提交到修复的全过程
    本文详细介绍了360SRC平台处理一起关键安全事件的过程,涵盖从漏洞提交、验证、排查到最终修复的各个环节。通过这一案例,展示了360在安全应急响应方面的专业能力和严谨态度。 ... [详细]
  • 本题探讨如何通过最大流算法解决农场排水系统的设计问题。题目要求计算从水源点到汇合点的最大水流速率,使用经典的EK(Edmonds-Karp)和Dinic算法进行求解。 ... [详细]
  • 本文深入探讨了HTTP请求和响应对象的使用,详细介绍了如何通过响应对象向客户端发送数据、处理中文乱码问题以及常见的HTTP状态码。此外,还涵盖了文件下载、请求重定向、请求转发等高级功能。 ... [详细]
  • 本文详细介绍如何使用Python进行配置文件的读写操作,涵盖常见的配置文件格式(如INI、JSON、TOML和YAML),并提供具体的代码示例。 ... [详细]
  • 本文介绍如何使用阿里云的fastjson库解析包含时间戳、IP地址和参数等信息的JSON格式文本,并进行数据处理和保存。 ... [详细]
  • 本教程涵盖OpenGL基础操作及直线光栅化技术,包括点的绘制、简单图形绘制、直线绘制以及DDA和中点画线算法。通过逐步实践,帮助读者掌握OpenGL的基本使用方法。 ... [详细]
  • 如何彻底清除顽固软件如360
    本文详细介绍了如何彻底卸载难以删除的软件,如360安全卫士。这类软件不仅难以卸载,还会在开机时启动多个应用,影响系统性能。我们将提供两种有效的方法来帮助您彻底清理这些顽固软件。 ... [详细]
  • Git管理工具SourceTree安装与使用指南
    本文详细介绍了Git管理工具SourceTree的安装、配置及团队协作方案,旨在帮助开发者更高效地进行版本控制和项目管理。 ... [详细]
  • 本文详细探讨了HTML表单中GET和POST请求的区别,包括它们的工作原理、数据传输方式、安全性及适用场景。同时,通过实例展示了如何在Servlet中处理这两种请求。 ... [详细]
author-avatar
少钧13
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有