PCIe扫盲（10）

系列文章目录

PCIe扫盲（一）
PCIe扫盲（二）
PCIe扫盲（三）
PCIe扫盲（四）
PCIe扫盲（五）
PCIe扫盲（六）
PCIe扫盲（七）
PCIe扫盲（八）
PCIe扫盲（九）
PCIe扫盲（10）

PCIe 错误定义与分类

  前面的文章提到过，PCI 总线中定义两个边带信号（PERR# 和 SERR#）来处理总线错误。其中 PERR# 主要对应的是普通数据奇偶校检错误（Parity Error），而 SERR# 主要对应的是系统错误（System Error）。具体如下：

• 普通的数据奇偶校检错误——通过 PERR# 报告

• 在多任务事务（Multi-task Transaction，又称为 Special Cycles）时的奇偶校检错误——通过 SERR# 报告

• 地址和命令的奇偶校检错误——通过 SERR# 报告

• 其他错误——通过 SERR# 报告

  一个简单的例子如下图所示：

  PCIe 作为一种高速串行总线，取消了 PCI 总线中的这两个边带信号，采用错误消息的方式来实现错误报告。但是，在软件层面上，PCIe 仍是兼容 PCI 总线的，具体后面会详细描述。

  在 PCIe 总线的错误报告机制中，有如下四个比较重要的概念：

• 错误检测（Error Detection）：指的是检测某个错误是否存在的过程。

• 错误登记（Error Logging）：指的是将相关寄存器（配置空间中的）的对应位置位，以等待软件中的相关错误处理程序来处理该错误。

• 错误报告（Error Reporting）：通知系统某个（或多个）错误发生了。在 PCIe 总线中，发生错误的设备会通过错误消息（Error Message）逐级将错误信息发送至 Root ，Root 接收到错误消息后，会产生对应的中断通知系统。

• 错误发送（Error Signaling）：指的是通过发送错误消息（或者带有 UR，CA 的 Completion 和 Poisoned TLP ）来传递错误信息的过程。

  注：“带有 UR，CA 的 Completion ”在前面的文章中介绍过，不熟悉的可以回顾一下。“Poisoned TLP” 是 PCIe 总线错误报告机制中的 Error Forwarding 的方式，具体会在后面详细介绍。

  PCIe 总线 Spec 定义了两个错误报告等级。第一个为基本的（Baseline Capability），是所有 PCIe 设备都需要支持的功能。第二个是可选的，称之为高级错误报告（Advanced Error Reporting Capability）。

  在基本的错误报告机制中，有两组相关的配置寄存器（配置空间中），分别为：

• 兼容 PCI 总线的寄存器（PCI-compatible Registers）

• PCIe 总线中新增的寄存器（PCI Express Capability Registers）

  高级错误报告机制（AER）中，又使用了一组专用的配置寄存器（配置空间中）。借助 AER 可以获得更多的错误信息，有助于软件定位错误源和分析错误原因。

  PCIe 总线的错误可以分为可校正错误（Correctable Errors）和不可校正错误（Uncorrectable Errors）。其中，可校正错误可以自动地被硬件识别并被自动的校正或恢复。而不可校正错误又被分为非致命的（Non-Fatal）和致命的（Fatal）。非致命的错误一般由设备驱动软件（Device Specific Software）直接处理，且链路（Link）可恢复，甚至链路上的数据有可能得到恢复（不丢失数据）。致命的错误只能由系统软件（System Software）处理，且一般需要进行复位等操作，因此链路上的数据必然会丢失。

PCIe 错误检测机制

  PCIe 总线错误检测囊括了链路（Link）上的错误以及包传递过程中的错误，如下图所示。用户设计的应用程序层中的错误不属于链路传输中的错误，不应当通过 PCIe 的错误检测与处理机制处理，一般可借助设备特殊中断（Device Specific Interrupt）等合适的方式进行报告与处理。

  包传递过程的错误主要通过 CRC 编码来检测。PCIe 定义了两种 CRC —— LCRC 和 ECRC。其中 LCRC（Link CRC）由数据链路层产生和校检，用于检测从一端的数据链路层发送到另一端的数据链路层的 TLP 是否发生的错误。而 ECRC（End-to-end CRC）由事务层产生和校检，且 ECRC 是可选的。

  有人可能会质疑 ECRC 存在的必要性，因为 LCRC 已经对 TLP 进行了 CRC 校检，在此基础上多加一层 ECRC 可能是没有必要的。这里来简单地说明一下，一般情况下（尤其是没有 Switch 的简单 PCIe 总线系统中），ECRC 的确是没有必要存在的。ECRC 主要为解决 Switch 中传输的可能存在的传输错误问题的，换句话说，如果用户的设计中并没有 Switch （只是简单的 Root 与 Endpoint 的端对端直连），完全可以不使用 ECRC 。

  如下图所示，假设来自 Endpoint 的 TLP 被正确地传输到 Switch 的 Downstream 输入端口（Ingress Port），Downstream 输入端口中的数据链路层也完成了对其的 LCRC 校检，且未发现错误。然后 Switch 会将该 LCRC 移除，并添加新的序列号（Sequence Number），随后重新计算 LCRC，再将该 TLP 发送至 Switch 的 Upstream 输出端口（Egress Port）。显然，在此过程中 TLP 是不受保护的，一旦期间数据传输遇到错误等异常，可能会导致重新计算 LCRC 前的数据已经受到了破坏，且仅仅使用 LCRC 是无法发现这样的错误的。

  注：关于序列号（Sequence Number），可以参考前面的关于 Ack/Nak 的相关文章。

  需要注意的是，ECRC 是 AER 中的一部分，要想使用 ECRC，该 PCIe 设备必须是支持 AER 的。

  如果按照错误产生的层（Layer）来分，则可以分为物理层错误，数据链路层错误和事务层错误。

物理层错误

  物理层错误（Physical Layer Errors）主要有：

• 8b/10b 编解码异常

• Framing 异常（8b/10b 编码中是可选的，128b/130b 中是必选的）

• Elastic Buffer 错误（可选的）

• 起始字符失锁（Loss of Symbol Lock）或者通道对齐失锁（Lane Deskew）（可选的）

数据链路层错误

  数据链路层错误（Data Link Layer Errors）主要有：

• LCRC 校检失败

• 序列号（Sequence Number）异常

• DLLP 中的 16-bit CRC 校检失败

• 链路层协议错误（Link Layer Protocol Errors）

事务层错误

  事务层错误（Transaction Layer Errors）主要有：

• ERCR 校检失败（可选的）

• 异常的 TLP（Malformed TLP）（即 TLP 的格式异常）

• 流量控制协议异常（Flow Control Protocol Violation）

• 不支持的请求

• 数据损坏（Data Corruption，又称为 Poisoned Packet）

• Completer Abort（可选的）

• 接收端溢出（Receiver Overflow）（可选的）

• 返回包超时（Completion Timeout）

• 不对应的返回包（Unexpected Completion，即 Completion 与发出的 Request 不一致）

错误优先级

  当接收端的物理层检测到 TLP 存在错误时，如果再将该 TLP 继续传送至数据链路层和事务层必然也会发现错误。而过多的错误会让错误分析与处理变得困难。因此，没有必要在向上传递该 TLP ，而是将其直接扔掉，并报告相应的错误。

  然而，即使这样，PCIe 总线的错误报告中也有很多错误源自同一个错误源。因此需要对错误进行优先级排序，使得错误源（最底层的错误）的优先级更高，能够最先得到处理。PCIe 总线中的错误优先级排序如下（优先级从高到低）：

• 不可更正的内部错误（Uncorrectable Internal Error）

• 接收端 Buffer 溢出

• 流量控制协议错误

• ECRC 校检失败

• 异常的 TLP（Malformed TLP）

• AtomicOp Egress Blocked

• TLP 包头异常（TLP Prefix Blocked）

• 访问控制服务（Access Control Services，ACS）异常

• MC（Multi-cast） Blocked TLP

• 不支持的请求（Unsupported Request，UR），Completer Abort（CA）或者不对应的返回包（Unexpected Completion）

• 接收到损坏的数据包（Poisoned Packet）

PCIe 错误源详解（一）

  这篇文章来详细地分析一下各种错误源的产生原理，由于内容较多，因此分为两篇文章。第一篇介绍一下 ECRC 校检错误和 Data Poisoning 等；第二篇文章介绍事务（Transaction）错误、链路流量控制（Link Flow Control）相关的错误、异常的 TLP（Malformed TLP）以及内部错误（Internal Errors）等。

ECRC

  前面的文章中提到过，ECRC 是可选的，主要用于包含有 Switch 的 PCIe 总线系统中。且只有支持 AER 的 PCIe 设备才有能力支持 ECRC 功能。配置软件通过检查配置空间，确认 PCIe 设备的某个功能（Function）支持 ECRC 后，可以通过向错误功能控制寄存器（Error Capability and Control Register）中的响应为写 0 或者 1 来禁止或者使能 ECRC 功能。

  如果使能了 ECRC 功能，可以通过 TLP 包头中的 TD（TLP Digest，ECRC 也被称为 Digest ）位来标记当前的 TLP 是否使用 ECRC，如下图所示。需要特别注意的是，如果 TD 为 1 （表示使用 ECRC），但是 TLP 中却没有 ECRC ；或者 TD 为 0 ，TLP 中却包含了 ECRC ，则会被判定为 TLP 格式错误，即 Malformed TLP 错误。

  ECRC 是基于 TLP 的包头和数据（Header and Data Payload）计算的，接收端会重新基于这些内容计算并与收到的 TLP 中的 ECRC （发送端计算的）作对比，如果不一致，则认为数据传输过程中发生了问题，数据被破坏了，进而产生 ECRC 校检错误。需要注意的是，在 TLP 包头中，有两位实际上是不参与 ERCR 计算的 —— Type 域的 bit0 和 EP 位。这两位通常被称为 Variant bits，且在 ECRC 计算的时候，这两位的对应位置始终被认为是 1 ，而非使用实际的数值。

  当接收端（Completer）接收到的请求（Request）TLP 中存在 ECRC 校检错误时，接收端通常会选择不对该请求发送返回 TLP（Completion），并将 ECRC 错误状态位（配置空间中的）置位。发送端由于长时间未接收到 Completion，进而会产生 Completion 超时错误（Timeout Error）。而大部分发送端，会选择重新发送先前的请求 Request 。

  当发送端（Requester）在发送完请求后收到了来自接收端返回的 TLP（Completion）时，却发现该 Completion TLP 中存在 ECRC 校检错误，会将 ECRC 错误状态位（配置空间中的）置位。发送端可以选择重新发送先前的请求 Request ，还可以选择通过特殊功能中断（Function Specific Interrupt）向系统报告错误。

  以上两种情况中，如果使能了错误消息报告功能的话，不可校正的非致命错误消息（Uncorrectable Non-fatal Error Message）会被发送至系统。

Data Poisoning（Poisoned Data or Error Forwarding）

  Data Poisoning 也被称为错误传递（Error Forwarding），指的是在已知 TLP Data Payload 被破坏（Corrupted）的情况下，该 TLP 仍然被发送至其他的 PCIe 设备。此时，该 TLP 包头的 EP 位（Error Poisoned）被置位为 1，表明该 TLP 已经被破坏。如下图所示：

  有人可能要有疑惑了，你既然都已经知道该 TLP Data Payload 被破坏了，为什么还要再将其进一步传递呢？实际上，这样做主要是针对某些特殊的应用的：

• 便于发送端（Request）和系统分析错误：假设发送端（Request）向接收端（Completer）发送了读数据请求，接收端从某个内存设备中读取数据后通过 Completion 返回数据给发送端。但是在此过程中发生了错误，接收端（Completer）因此不向发送端（Request）返回 Completion，则发送端只会产生 Completion Timeout 错误，却难以分析错误原因。如果接收端返回 Poisoned Completion TLP 给发送端（TLP 包头中 EP 为 1 ），则发送端至少可以确认接收端正确地接收到了其发出的请求（Request）。

• 便于发现 Switch（或其他桥设备）中的错误：假设 TLP 中的 Data Payload 是在 Switch 中被破坏的，采用错误传递的方式有助于发现该错误。

• 有些应用允许接收存在错误的数据：比如实时的音频或者视频传输，其宁可接收到有些许错误的数据，也需要尽量保证数据传输的实时性。

• 数据可能通过应用层恢复：有些应用可能采用了特殊的编码 ，该编码可以恢复某些被破坏的数据（如 ECC 可恢复 1 位的错误）。

  需要特别注意的是，错误传递（Data Poisoning or Error Forwarding）只是针对 TLP 中的 Data Payload 是否被破坏，和 TLP 包头的内容无关。也就是说错误传递只是针对那些带有 Data Payload 的 TLP 的，如 Memory、Configuration、I/O 写或者带有返回数据的 Completion 。PCIe Spec 没有定义对没有 Data Payload 的 TLP ，其 TLP 包头中的 EP 却为 1 的情况，应当如何处理。

  注：需要注意的是，Poisoning 操作只能在事务层进行。原因很简单：数据链路层和物理层在任何情况下，都不会检查 TLP 包头的内容，更不会修改 TLP 包头。

PCIe 错误源详解（二）

  这篇文章主要介绍事务（Transaction）错误、链路流量控制（Link Flow Control）相关的错误、异常的 TLP（Malformed TLP）以及内部错误（Internal Errors）等。

事务（Transaction ）错误

  事务错误主要包括不支持的请求（Unsupported Request）、Completer Abort、非预期的 Completion 和 Completion 超时。该错误类型主要通过返回的 Completion TLP 包头中的 Compl. Status 告知 Requester，如下图所示。另外，之前介绍 TLP Header 的文章中也简单地提到过相关内容，可以回顾一下：TLP Header详解（三）

不支持的请求（Unsupported Request）

  不支持的请求（Unsupported Request）主要包括：

1. 请求类型不被当前 PCIe 设备支持

2. 消息中使用了不支持或者未定义的消息编码

3. 请求的地址空间超出（或者不在）设备的地址空间中

4. 针对 Completer 的 IO 或者存储映射控制空间（Memory-mapped Control Space）进行的 Poisoned 写操作（EP = 1）

5. Root 或者 Switch 的 Downstream 端口接收到针对其二级总线（Secondary Bus）上的不存在的设备的配置请求（Configuration Request）

6. Endpoint 接收到 Type1 型的配置请求

7. Completion 中使用了保留的 Completion 状态编码（参考上面的表格）

8. 设备（的某个功能，Function）处于 D1、D2 或者 D3hot 电源管理状态时，却接收到了除了配置请求和消息之外的内容

Completer Abort

  Completer Abort（CA）主要包括：

1. Completer 接收的特殊请求，只有在违背其规则的情况下才能对该请求进行响应（返回 Completion）

2. 因为某些恒定的错误状态（Permanent Error Condition），导致 Completer 无法响应接收到的请求

3. Completer 接收到存在访问控制服务错误（Access Control Services Error，ACS Error）的请求

4. PCIe-to-PCI 桥接收到针对其连接的 PCI 设备的请求，但是该 PCI 设备无法处理该请求

非预期的 Completion

  非预期的 Completion 主要包括：

1. Requester 接收到的 Completion 和其发出的 Request 不一致

Completion 超时

  所有的 PCIe 设备都必须支持 Completion 超时定时器，除非该设备只是用于初始化配置事务的。需要注意的是，PCIe 设备必须能够针对多个事务（Transaction）分别计时。PCIe 1.x 和 2.0 的 Spec 建议超时时间最好设置为 10ms 至 50ms 之间，对于一些特殊情况，超时时间最低可设置为 30us 。PCIe 2.1 Spec 开始，增加了第二设备控制寄存器（Device Control Register 2）用于查看和控制超时时间的值。如下图所示：

  如果，某个请求对应多个 Completion，那么除了最后一个 Completion，其他的 Completion 不会造成该请求的定时器停止计时。

链路流量控制（Link Flow Control）相关的错误

  链路流量控制相关的错误主要有：

1. 在 FC 初始化时，链路相邻设备无法完成针对任何一个 VC 的，最小的 FC Credits 的交换更新（Advertises）

2. 链路相邻设备交换更新（Advertises）的 FC Credits 超过了最大值（Data Payload 最大为 2047，Header 最大为 127）

3. 链路相邻设备交换更新时，FC Credits 为非零值，且该链路的 FC Credits 之前已经被初始化为无限值了

4. 接收端 Buffer 溢出，导致数据丢失（可选的，但是如果使能，则认为是 Fatal Error ）

  关于 Flow Control 可以参考之前的文章：Flow Control基础（一） 和 Flow Control基础（二）

异常的 TLP（Malformed TLP）

  异常的 TLP（Malformed TLP）错误主要有：

1. Data Payload 超过了最大值（Max Payload Size）

2. 数据长度（Data Length）与包头中的长度值不一致

3. 存储地址起始位置跨越了 4KB 边界（Naturally-aligned 4KB Boundary）

4. TD（TLP Digest）的值与 ECRC 是否使用不一致

5. 字节使能冲突（Byte Enable Violation）

6. 未定义的类型值（Type Field Values）

7. Completion 违反了 RCB（Read Completion Boundary）值

8. 针对非配置请求返回的 Completion 中的状态为配置请求重试状态（Configuration Request Retry Status）

9. TC 域包含了一个未被分配到当前使能的 VC 的值（也被称为 TC Filtering）

10. IO 或者配置请求冲突（可选的）

11. 中断 Emulation 消息向下发送（可选的）

12. TLP 前缀错误（具体请参考 PCIe Spec V2.0的2.2~2.6 相关章节）

内部错误（Internal Errors）

  一般指的是 Switch 等桥设备内部产生的错误

PCIe 错误报告机制

  PCIe 总线有三种错误报告方式，分别是：

1. Completions：通过 Completion 中的状态位向 Requestor 返回错误信息

2. Poisoned Packet（又称为错误传递，Error Forwarding）：告知接收端当前 TLP 的 Data Payload 已经被破坏

3. Error Message（错误消息）：向主机报告错误信息

  前两种之前的文章都已经提及，本文主要介绍错误消息。错误消息的格式和对应的消息编码如下所示：

  为了兼容 PCI 总线的错误报告机制（使用 PERR# 和 SERR#），PCIe 设备会自动将 CA、UR 和 Poisoned TLP 转换为对应的错误信息。具体这里就不详细介绍了，有兴趣的可以自行阅读 PCIe Spec 的相关章节。

  PCIe 设备的配置空间中的状态与控制寄存器如上图所示，通过这些寄存器可以使能（或禁止）通过错误消息（Error Message）发送错误报告、查询错误状态信息，以及链路训练和初始化状态等。

  前面的文章介绍过，默认的错误分类如下表所示：

  这些错误类型可以通过设备控制寄存器（Device Control Register）中的相关位，进行使能或者禁止：

  也可以通过设备状态寄存器（Device Status Registers）相关位查询错误状态：

  当然，当 Root 接收到错误消息后，怎么处理还要取决于 Root Control Register 的设置：

  链路错误（Link Errors）一般发生在物理层与数据链路层通信的过程中。对于 Downstream 的设备，如果链路上发生了 Fatal 错误，此时，该设备并不能够向 Root 报告错误。这种情况下，需要 Upstream 设备向 Root 来报告错误。为了消除链路错误，一般需要对链路进行重新训练（Retrain）。如下图所示，在链路控制寄存器中，可以通过往 Retrain Link 这一位写 1 ，来强制进行链路重训练。

  当发起重训练请求后，软件可以检查链路状态寄存器（Link Status Register）中的 Link Training 位，来确认链路训练是否已经完成，如下图所示。当该位为 1 时，表明链路训练尚未完成（或者还没有开始），如果链路训练已经完成，硬件会自动将该位清零。

  PCIe 总线的错误登记与报告的流程图如下图所示：

高级错误报告 AER（一）

  前面的文章提到过高级错误报告（Advanced Error Reporting，AER），接下来详细地介绍一下这一功能。在已有的 PCIe 错误报告机制上（之前文章介绍的），AER 还支持以下特性：

• 在登记实际发生的错误类型时，有更好的粒度（Granularity，可以理解为区分度或者精确度）

• 区分各种不可校正错误的严重程度

• 支持登记包头中的错误

• 为 Root 通过中断报告接收到的错误消息提供了标准化的控制机制

• 可以定位错误源在 PCIe 体系结构中的位置

• 能够独立地屏蔽某种（或者多种）错误类型的报告

  配置空间中的 AER 相关寄存器结构如下图所示：

  前面的文章中多次提到过，ECRC 的产生于校检需要 AER 的支持，相关控制 bit 位于高级错误功能控制寄存器中，如下图所示：

  其中，最低 5bits 为当前错误指针（First Error Pointer），当相关错误状态更新时，该指针由硬件自动更新。一般情况下，当前错误指针指向的错误是优先级最高的错误，需要最先被处理的，往往也是其他错误的根源。PCIe Spec V2.1 还支持多个错误的追踪（Tracking Multiple Errors）。

  图中的 ROS、RWS、RO 等字符的意义如下：

• RO——只读（Read Only），由硬件控制

• ROS——只读且不被复位（Read Only and Sticky）

• RsvdP——保留且不可以用于其他用途

• RsvdZ——保留且只能被写 0

• RWS——可读可写且不被复位（Readable，Writeable and Sticky）

• RW1CS——可读，写 1 清零，且不被复位

  不被复位是指该 bit 的内容不会因为复位（断电后的上电复位除外）而发生改变。PCIe 总线中有多种复位概念，Sticky bit（不被复位的位）不会受到功能层复位（Function Level Reset， FLR）、热复位（Hot Reset）和暖复位（Warm Reset）的影响，甚至不受冷复位（Cold Reset）的影响（当主电源切断后，V_aux 等二级电源仍保持正常供电）。关于 PCIe 总线的复位机制，后续的文章会详细地介绍。

高级错误报告 AER（二）

  这一篇文章讲一讲，高级错误报告（Advanced Error Reporting，AER）关于可校正和不可校正错误的相关寄存器，以及 Root 如何处理来自其他 PCIe 设备的错误消息等内容。

高级可校正错误处理（Advanced Correctable Error Handling）

高级可校正错误状态

  高级可校正错误状态寄存器如下图所示，当相关错误发生后，硬件会自动地将对应 bit 置 1 。软件可以通过向对应 bit 写 1 ，来清零。

高级可校正错误屏蔽

  高级可校正错误屏蔽寄存器如下图所示，默认情况下，这些 bit 的值都是 0 。也就是说，只要发生相关错误，且该错误报告功能被使能，则相关错误便会被报告（不被屏蔽）。当然，软件可以通过将相关 bit 置 1 ，来屏蔽相关的错误报告信息。

高级不可校正错误处理（Advanced Uncorrectable Error Handling）

高级不可校正错误状态

  高级不可校正错误状态寄存器如下图所示，当相关错误发生时，不管这些错误会不会被报告到 Root，相关的 bit 都会被置 1 。

  回顾一下，前一篇文章中的当前错误指针（First Error Pointer）。假设该指针的值为 18d，则表明不可校正错误状态寄存器中的第 18 位对应的错误——异常的 TLP（Malformed TLP）将会被最先处理。一旦该错误被处理后，软件将会向不可校正错误状态寄存器的第 18 位写 1 ，来清除该 bit 。然后，当前错误指针将会被更新到下一个值。

  软件可以通过高级不可校正错误严重度寄存器（Advanced Uncorrectable Error Severity Register）来修改不可校正错误是否被作为致命的（Fatal）错误处理，进而使得这些错误得到区分处理。如下图所示，其中，0 表示非致命的（Non-Fatal），1 表示致命的（Fatal）。

高级不可校正错误屏蔽

  高级不可校正错误评级寄存器如下图所示，当相关 bit 被置 1 时，对应的错误类型将不会被报告。

  配置空间中的高级错误报告结构中包含有一个 4DW 的子空间，用于缓存接收到的，发生不可校正错误的（未被屏蔽的）的 TLP 的包头。PCIe Spec 规定，当设备支持 AER 功能时，必须有能力至少缓存一个 TLP 包头（4DW）。当然，有些设备可能支持缓存更多的 TLP 包头。该子空间被称为包头缓存寄存器（Header Log Register），其支持的错误类型如下图所示。

  在 PCIe 总线拓扑结构中，Root 是所有其他 PCIe 设备错误报告的目标（Target）。当 Root 接收到来自其他 PCIe 设备的错误消息（Error Message）后，Root 会根据系统的参数设置选择是否向系统报告错误，并以何种方式（中断等）报告。

  注：关于 PCIe 的中断机制会在后续的文章中详细介绍。

  当 Root 接收到错误消息后，便会将 Root 错误状态寄存器中的对应位置位。需要注意的时，由于 Root 自身也是 PCIe 设备，当其自身发生错误时，也会导致 Root 错误状态寄存器中的对应位置位，就像是其收到了错误消息了一样。该寄存器如下图所示：

  前面的文章介绍过，错误消息也是消息（Message）的一种。错误消息中包含了错误源设备的 ID 信息（BDF，Bus，Device and Function），根据 ID 信息，便可以确定错误源的位置等信息，同时将该信息缓存在高级源 ID 寄存器中，如下图所示。

  可以通过 Root 错误命令寄存器（Root Error Command Register）的相关 bit 来使能或者禁止相关类型的错误是否被报告至系统。如下图所示：

转载链接

1. PCIe 错误定义与分类
2. PCIe 错误检测机制
3. PCIe 错误源详解（一）
4. PCIe 错误源详解（二）
5. PCIe 错误报告机制
6. 高级错误报告 AER（一）
7. 高级错误报告 AER（二）

☆