错误上报_PCIe错误的上报方式

       按Spec定义的原则和内容，前面讲的所有错误类型，包括不可修复错误(Uncorrectable Errors)和可修复错误(Correctable Errors)。这些错误的错误检测，都是由各个硬件设备制造商按照协议内容实现的。这些错误是如何通知上报呢？

error reporting	In a broad context, the general notification of errors. In the context of the Device Control register, sending an Error Message. In the context of the Root Error Command register, signaling an interrupt as a result of receiving an Error Message.
error signaling	One agent notifying another agent of an error either by (1) sending an Error Message, (2) sending a Completion with UR/CA Status, or (3) poisoning a TLP.

   协议里还是蛮(咬)严(文)谨(嚼)的(字)，对于错误上报和错误通知机制定义的很详细。本篇文章，我们仅讨论上报(通知)的几种机制。这里的所谓上报，是指上报给相关的对象，如请求者、RootComplex等。对于上报之后的处理我们后续再展开。

PCIe Spec规定了3种错误上报机制：

•  对于Non-Post请求，通过完成报文的状态上报。如UR/CA/CRS。

• 通过错误消息(Error Message)，包括三种类型的错误消息：ERR_COR/ERR_NONFATAL/ERR_FATAL。

• 对于链路中间的Switch，检测到的报文错误，使用错误转发(Error Forwarding)，也称为数据中毒(Data Poisoning)。

完成状态

---

对于Non-Post事务，完成者(Completer)通过在完成报文头里面置位完成状态(Completion Status)，来告诉请求者(Requester)本次请求事务的完成情况。具体的状态包括如下表的几种：只要完成包的状态不是SC(Successful Completion)，就代表对应的请求失败了。

       注意：完成者在完成报文里报告自己的完成状态以外，也有可能直接通过错误消息(Error Message)向系统报告一条错误。另外，在完成报文不一定能够正常返回的情况下，依赖请求者的完成超时机制(Completion Timeout)来识别错误。

错误消息

---

       对于Post事务，例如Memory Write、Message等，是没有完成报文的。如果有错误，是无法通过完成报文上报的。这种情况下，Spec定义需要通过错误消息(Error Message)上报。上报给谁呢？上报给PCIe领域的老大：Root Complex。小弟搞不定了，但一定要告诉老大，让他来处理好咯。

     错误消息的报文头里面，包含请求者的ID和错误消息码，以告诉Root Complex是谁报告了错误，以及报告了什么类型的错误。错误类型包括ERR_COR/ERR_NONFATAL/ERR_FATAL，跟昨天讲的错误类型是对应的。

错误转发(数据中毒)

---

       在有Switch的地方，还会有另外一种场景，就是错误转发。考虑如下场景：Requester发起读请求到Completer，Completer收到请求，把对应的包含完成数据的报文返回。在这条路径的中间，多了一个Switch。当Switch收到完成报文的时候，假设这个数据报文的CRC校验失败，Switch需要置位报文头的EP(Error Poisoning)bit。并继续向请求者返回这个报文。

出现Data poisoning时，TLP的EP比特会置1。

注意：Switch即使判断出数据中毒，也不能修改数据报文的CRC！它只能告诉请求者数据中毒这个状态。中间转发者就是转发者，对经过它的内容没有修改的权利。另外，如果Switch支持DPC或者在Multicast等场景下，错误转发(数据中毒)的处理会有一些不一样。这里不展开讨论。