来源PCI5.0 SPEC

1.错误报告范式ERROR REPORTING PARADIGMS

PCI Express定义了两种错误报告范式：baseline capability and the Advanced Error Reporting Capability。baseline错误报告能力是所有PCI Express设备都需要具备的，它定义了最低限度的错误报告要求。高级错误报告能力是为了更强大的错误报告而定义的，并且通过特定的PCI Express能力结构来实现。

2.Error Classification错误类型

PCI Express（PCIe）的错误可以分为两种类型：不可纠正错误（Uncorrectable Errors）和可纠正错误（Correctable Errors）。这种分类有助于区分导致功能失效的错误和导致性能下降的错误。

不可纠正错误可以进一步分为两个子类型：致命错误和非致命错误。

1. 致命错误：这些是严重错误，通常导致功能丧失或系统崩溃。当发生致命错误时，受影响的事务或组件无法恢复，系统可能需要重新启动或进行复位才能恢复正常运行。

2. 非致命错误：这些错误较轻微，不会导致功能丧失，但可能仍会导致性能下降。非致命错误可以通过重新尝试失败的事务或使用错误处理机制来恢复，而无需进行系统复位。这些错误可能会影响到重新尝试失败的事务或利用错误处理机制来确保数据完整性。

2.1可纠正错误Correctable Errors

可纠正的错误是指硬件能够在不丢失任何信息的情况下恢复的错误条件。这些错误可以由硬件自行纠正，无需软件介入。例如，一个TLP中的LCRC错误可能通过数据链路层重试进行纠正，被视为可纠正的错误。

2.2不可纠正的错误Uncorrectable Errors

不可纠正的错误是指影响接口功能的错误。在该规范中没有定义纠正这些错误的机制。报告不可纠正的错误类似于在PCI/PCI-X中断中断中断（SERR＃）。为了实现更强大的系统错误处理，该规范进一步将不可纠正的错误分类为致命错误和非致命错误。

2.2.1致命错误Fatal Errors

致命错误是指不可纠正的错误情况，使得特定的链路和相关硬件变得不可靠。对于致命错误，可能需要对链路上的组件进行复位以恢复可靠运行。

2.2.2非致命错误Non-Fatal Errors

非致命错误是指不可纠正的错误，导致某个特定的事务变得不可靠，但链路本身是完全可用的。将非致命错误与致命错误分离开来，可以提供从错误中恢复的机会，而无需对链路上的组件进行复位并干扰其他正在进行的事务。

3.错误信号Error Signaling

有三种互补机制，使得代理程序可以检测到错误并通知系统或其他设备发生了错误。

第一种机制是通过完成状态Completion Status来实现的，

第二种方法是通过内部错误消息Error Messages来实现，

第三种方法是通过错误转发Error Forwarding (Data Poisoning)来实现的。

3.1完成状态Completion Status 

当请求处理完成后，系统会返回一个完成头部（Completion header），其中包含有关请求完成状态的信息。这个完成状态可以指示请求的执行结果，比如是否成功完成或是否出现了错误。

在PCI Express协议中，Completion Status字段用于指示关联请求的执行结果。如果完成状态是成功完成（Successful Completion），则表示请求已经按预期完成。然而，如果完成状态不是成功完成，则表示与请求相关的操作失败了，可能由于某种错误而产生。

通过读取Completion Status字段，请求方可以了解到请求的执行结果，并根据这个结果采取后续的处理措施，比如修复问题或重新发出请求等。这个机制允许请求方在更高层次的协议中处理错误，并根据需要进行进一步的操作。

3.2错误信息Error Messages 

错误消息根据错误的严重性被发送到 Root Complex端口以报告错误的检测情况。从PCI Express或传统端点发出的错误消息将发送到相应的Root Ports。从Root Port本身发出的错误将通过同一Root Port进行报告。

如果实现了可选的Root Complex Event Collector，那么从RCiEP（Root Complex integrated Endpoint）发出的错误将发送到相应的Root Complex Event Collector。Root Complex Event Collector本身发出的错误也通过同一根Root Complex Event Collector进行报告。Root Complex Event Collector必须在其功能中声明支持的RCiEPs，而每个RCiEP只能与一个Root Complex Event Collector关联。

当检测到多个严重性相同的错误时，具有相同请求者ID的相应错误消息可能会被合并，用于表示不同的相同严重性错误。对于每个严重性级别检测到的错误，必须发送至少一条错误消息。

3.2.1不可纠正错误严重性可编程Uncorrectable Error Severity Programming (Advanced Error Reporting)

对于实现高级错误报告功能的设备功能，"Uncorrectable Error Severity"寄存器允许将每个不可纠正的错误设置为致命（Fatal）或非致命（Non-Fatal）。不可纠正错误无法使用定义的PCI Express机制进行恢复。

基线错误处理不支持严重性编程。

3.2.2屏蔽错误Masking Individual Errors

The transmission of these error Messages by class (correctable, non-fatal, fatal) is enabled using the Reporting Enable bits of the Device Control registeror the SERR# Enable bit in the PCI Command register

 

对于实现高级错误报告功能的设备，"Uncorrectable Error Mask"寄存器和"Correctable Error Mask"寄存器允许独立屏蔽每个错误条件。这意味着可以通过设置对应的错误屏蔽寄存器来阻止特定的错误条件生成错误报告消息。

当某个错误被屏蔽时，该错误的状态位仍然会被设置，但不会生成错误报告消息，也不会记录在相关的错误日志中（如头部日志、TLP前缀日志或第一个错误指针）。通过屏蔽错误，可以控制哪些错误条件需要进行报告，以满足特定的错误处理需求。

3.2.3错误污染Error Pollution

错误污染发生在给定事务的错误未被隔离。假设物理层Physical Layer检测到接收器错误，这个错误在物理层Physical Layer被检测到，并且向Root Complex报告一个错误。为了避免这个错误传播并导致上层出现后续错误（例如数据链路层 Data Link Layer的TLP错误），从而更加困难地确定错误的根本原因，对于同一数据包发生的后续错误，数据链路层 Data Link Layer或事务层Transaction layers将不会报告它们。类似地，当数据链路层检测到错误时，事务层将不会报告同一数据包发生的后续错误。此行为仅适用于与特定数据包相关的错误 - 其他错误将按每次出现报告。已纠正的内部错误是由组件掩盖或解决的错误；有关详细信息，请参阅第6.2.9节。因此，已纠正的内部错误不会导致错误污染，并且在检测到时应该报告。对于在事务层检测到的错误和无法纠正的内部错误，建议每个接收到的TLP只报告不多于一个错误，并使用以下优先顺序（从高到低）：

• Uncorrectable Internal Error
• Receiver Overflow
• Malformed TLP
• ECRC Check Failed
• AtomicOp Egress Blocked
• TLP Prefix Blocked
• ACS Violation
• MC Blocked TLP
• Unsupported Request (UR), Completer Abort (CA), or Unexpected Completion
• Poisoned TLP Received or Poisoned TLP Egress Blocked

3.2.4Advisory Non-Fatal Error Cases

Advisory Non-Fatal Error Cases 在某些情况下，非致命错误的检测器不确定错误是否可恢复，或者是否需要任何恢复动作，甚至可能根本不需要进行任何恢复动作。例如，如果软件尝试从不存在的设备或功能执行配置读取操作，则完成中的UR状态将向软件发出错误信号，软件不需要通过发送ERR_NONFATAL消息来进一步向Completer发出错误信号。实际上，在某些平台上，使用ERR_NONFATAL来标志错误会导致系统错误，这将打破正常的软件探测。

 

Advisory Non-Fatal Error Cases主要由检测agent（Requester,Completer, or Receiver）和特定错误情况来确定。在这种情况下，如果打开AER通过发送ERR_COR，而不是发送ERR_NONFATAL，没有AER的情况不会发送任何错误消息。

3.2.5Completer Sending a Completion with UR/CA Status

Completer通常发送一个带有Unsupported Request或Completer Abort (UR/CA)状态的Completion，以表示non-post request的不可纠正错误。如果UR/CA错误的严重性是非致命的，则程序必须将此情况作为Advisory Non-Fatal Error Cases处理。带有AER会发送ERR_COR消息来表示非致命错误，没有AER的不会发送错误消息。

如果Completer在Completion中返回数据，并且数据是坏的或可疑的，则允许Completer使用error Forwarding发出错误信号(Data Poisoning))机制，而不是将其作为UR或CA处理。