pcie-rx处理过程

rx如何处理一个cpl？req？msg？结合databook

1.Request Handling Rules

1.如果request type是识别的但是由于设计或者配置设置等问题导致的不支持，那么此时这个request是一个UR（Unsupported request），如果这个request需要一个completion，那么此时completion的状态也是UR。

2.如果request是一个message，并且message code、routing field、Msg/MsgD的结合指示的一个未定义的字段，或者说是对应的设备不支持的message，那么这个请求是一个UR，并且是一个和接收端口相关的报告错误。需要指出的是，对于设备不支持的message中来说，其中Vendor_Defined Type 1不被认为是一个错误。另外，如果message code是一个ignored message，并且接收方正在忽略它，那么就不需要报告任何错误。

3.如果该请求是一个按照ID路由的message，并且如果该请求被一个header type为0的Function接收，不管bus number是多少，该设备必须被视为消息的目标，而对于non-ART设备，device number存放在request中的destination ID域中（如果此时destination ID 的信息是无效的，那么这个request将会被视做UR，并且这个错误是和接收错误相关的错误）

4.针对DMWr来说，存在具体准则。

5.对于其他的request（不是message/DMWr），

（1）如果completer由于设备特定的错误而永远无法处理请求，completor必须将这个请求作为completer abort。如果错误可以隔离到组件中的特定function，则这个错误是一个和rx function相关的错误;如果错误无法隔离到接收端口，则报告与rx port相关的错误。

（2）对于配置的过程中的请求消息，如果设备支持device Readiness Status (DRS) ，那么需要注意：

  a:在任何DRS事件之后，一旦链路处于L0，与上游端口相关的function将返回RRS的完成状态，直到上游端口发送了设备就绪状态消息。

  b:一旦上游端口发送了Device Readiness Status Message，上游端口的所有non-VF function针对cfg req必须响应正确带SC的cpl。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

注：什么是DRS?(参考网络)

Readiness Notification（RN）旨在缩短PCIe Device/Function启动或复位之后到软件可以发送Cfg TLP之间的等待时间。RN通知机制包括DRS（Device Readiness Status）和FRS（Function Readiness Status）两种事件，该机制直接标志Device/Function进入到Configuration-Ready状态（Configuration-Ready，Function能够对其收到的配置请求回复以带有Success状态的有效Completion，则该Function为Configuration-Ready状态）。

（1）DRS:设备发送DRS消息，此时设备还没有分配Bus号，所以Host并不能根据RequesterID确认Configuration-Ready的设备。但是该设备对接的Switch下游端口会置DRS Message Revieved为高，Host在枚举过程中可以通过该位域确认下游设备是否Ready。（2）FRS:Function在Configuration-Ready之后发送FRS消息，RC中的FRS Queue记录消息的RequesterID和Reason，Host通过该队列可以确认下挂Function是否Ready。

PCIe RN (Readiness Notification)介绍_pcie readiness notification-CSDN博客 

PCIe RN（Readiness Notification）介绍 (ngui.cc)

----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

（3）对于配置的过程中的请求消息，如果设备不支持Readiness Status (DRS) ，那么复位后允许function终止请求，并表明它暂时无法处理请求，但将来能够处理请求。在这种情况下，completion必须使用请求重试状态(RRS)完成状态。允许device/function返回RRS以响应配置请求的有效重置条件是：

  a： Cold, Warm和 Hot Resets；

  b：FLRs（Function Level Reset）

  C：为了响应设备从D3Hot到D0uninitialized状态转换而启动的重置

（4）

a：function不可以在设备的软件启动复位(FLR除外)之后返回RRS来响应配置请求，例如，通过设备的软件驱动写入设备特定的复位位。

b：在function已经表明它是配置就绪的，没有中间的有效复位(即FLR或常规重置)条件，或者如果函数的状态寄存器中的立即就绪位被设置时，function不允许返回RRS来响应一个配置请求。

c：function不允许在之前返回成功完成而中间没有有效复位(即FLR或常规重置)条件后就返回RRS来响应配置请求。

（5）实现Readiness Time Reporting Extended Capability的function不能返回RRS来响应在Extended Capability中规定的相关时间之后收到的配置请求。

（6）在处理请求的过程中，completer可能确定(否则这个request就是可以接受的)请求必须作为错误处理，在这种情况下，请求根据错误的类型进行处理。比如，PCI Express/PCI桥可能最初接受一个请求，因为它映射到桥的secondary side的内存空间范围，但请求可能在桥的PCI侧的Master Abort或者Target Abort 。从PCI Express角度来看，在这种情况下，请求的状态是UR(用于Master Abort)或CA(用于Target Abort )。

8.如果device/function可以作为I/O写请求的目标（也就是Non-Posted Requests），建议每个相关的completion在与Posted Request acceptance遵循相同的时间限制，并在这个时间限制内返回（非强制，但是建议）。

9.如果device/function支持作为DMWr请求的目标，每个相关的completion必须在Posted Request Acceptance Limit内返回。

2.Data Return for Read Requests

Read request的completion可能会有多个包，但是针对IO操作和read configuration操作必须使用一个completion包就完成。

1.除Successful Completion外，completion的完成状态（Completion Status）必须是:(1)为Cpl或CplLk类型，(2)对于读请求，包括ATS Translation请求，是最终完成返回（ be the final Completion returned）。（这里有问题？？）

2. completion不能包含超过传输的function的Tx_MPS_Limit允许的数据，接收function必须检查其Rx_MPS_Limit是否违反。

3.需要注意RCB，在RCB上将数据拆成多个completion进行传输（具体内容参见RCB部分）；另外需要指出，如果单个读请求的所有内存读完成都具有成功的完成状态，那么它们的有效负载之和必须等于请求的大小，但是关于内存读取是ATS转换请求时存在例外。（协议10.2.4）

4.在第一个或”唯一一个completion的第一个或唯一一个”的数据DW中，只有在请求中的First DW BE字段中配置为active的字节包含有效数据。在请求中的第一个DW BE字段中配置为inactive的字节将返回未定义的内容。

5.在上一次successful Completion的最后一个Data DW中，只有在请求中的last DW BE字段中配置为active的字节包含有效数据。在请求中的Last DW BE字段中配置为inactive的字节将返回未定义的内容。

6.所有Completion的数据字节，包括那些未定义的内容，都包括在所有的CRC计算。 

8.对于所有Memory Read Completions，Lower Address字段必须指示completion返回的数据的第一个启用字节的字节地址的下一位。对于第一个(或唯一的)completion，Completer可以从请求的地址中最低的有效的5位（the least significant 5 bits of the address of the Request ）与2位字节级地址连接起来生成该字段。除了由RCB值为64字节的RC生成的completion，对于后续的completion，Lower Address字段将始终为零。在这种情况下，Lower Address字段的最低的6位将始终为零，Lower Address字段的最高位将按照64字节数据对齐的方式进行写入（也就是最高位需要保证64字节数据对齐）。

9.当生成一个read completion时，其完成状态不是successful completion时：

（1）当completion中没有包含数据，使用Cpl(或CplLk)编码代替CplD(或CplDLk)；

（2）当此completion是请求的最终completion，completor此时不能为request提供额外的completions，比如completer将请求分成四部分进行服务;第二个完成出现Completer Abort Completion状态;completer终止了对该request的服务，并且没有传输剩下的两个completion。（这里优点问题？？）

10.字节计数字段必须指示完成请求所需的剩余字节数。

11. Lower Address字段必须指示如果成功完成，则将和completion一起返回的第一个启用的数据字节的字节地址的下一位。

 

3.msg receive

待补充