2.3 接收到的TLP的处理

本节描述了当接收到的TLP从接收数据链路层传送到接收事务层，并且在数据链路层已经验证了接收到的TLP的完整性后，如何处理所有接收到的TLP。规则在图2-41所示的流程图中进行了图解。

• 保留字段中的值必须由接收器忽略。
• 如果Fmt字段的值指示存在至少一个TLP前缀：
  • 通过检查后续DW中第一个字节的Fmt字段，直到Fmt字段不匹配TLP前缀的Fmt字段，来检测头标中是否还有额外的TLP前缀。
  • 根据TLP前缀处理规则处理所有接收到的TLP前缀（见第2.2.10节）。
• 如果设置了扩展Fmt字段支持位，使用Fmt和Type编码的接收到的TLP，如果Fmt和Type是保留的，则为畸形TLP（见表2-1和表2-3）。
  • 这是一个与接收端口相关联的报告错误（见第6.2节）。
• 如果清除了扩展Fmt字段支持位，处理Fmt[2]设置的接收到的TLP是未定义的。
• 所有Fmt[2]清除且使用未定义的Type字段值的接收到的TLP都是畸形TLP。
  • 这是一个与接收端口相关联的报告错误（见第6.2节）。
• 所有接收到的畸形TLP都必须被丢弃。
  • 接收到的畸形TLP如果关于要释放哪个缓冲区不明确，或者映射到未初始化或已禁用的虚拟通道，则必须在不更新接收流控制信息的情况下被丢弃。
  • 所有其他接收到的畸形TLP都必须被丢弃，可以选择不更新接收流控制信息。
• 否则，更新接收流控制跟踪信息（见第2.6节）。
• 如果Type字段的值表明TLP是一个请求，根据请求处理规则进行处理；否则，TLP是一个完成，根据完成处理规则进行处理（后续章节）。

Switch必须处理同时针对Switch内部资源以及位于Switch外部的资源的TLP。Switch根据上述规则处理所有针对Switch内部资源的TLP。通过Switch的TLP，或者既针对Switch又通过它的TLP，根据以下规则进行处理（见图2-42）：

• 如果Type字段的值表明TLP不是消息（Msg）或带有数据的消息（MsgD）请求，TLP必须根据所使用的路由机制进行路由（见第2.2.4.1节和第2.2.4.2节）。
• Switch使用完成中的请求者ID字段中的信息来路由完成（Completions）。
• 如果Type字段的值表明TLP是消息（Msg）或带有数据的消息（MsgD）请求，根据Type字段中r[2:0]子字段指示的路由机制路由请求。
  • 如果r[2:0]的值表明Msg/MsgD被路由到根复合体（000b），Switch必须将Msg/MsgD路由到Switch的上游端口。
    • 在Switch的上游端口接收到指定000b路由的Msg/MsgD请求是一个错误。Switch可以检查此规则的违规情况 - 违规的TLP是畸形TLP。如果进行了检查，这是一个与接收端口相关联的报告错误（见第6.2节）。
  • 如果r[2:0]的值表明Msg/MsgD通过地址进行路由（001b），Switch必须按照它路由地址内存请求的方式路由Msg/MsgD。
  • 如果r[2:0]的值表明Msg/MsgD通过ID进行路由（011b），Switch必须按照它路由ID完成的方式路由Msg/MsgD。
  • 如果r[2:0]的值表明Msg/MsgD是来自根复合体的广播（011b），Switch必须将Msg/MsgD路由到Switch的所有下游端口。
    • 在Switch的下游端口接收到指定011b路由的Msg/MsgD请求是一个错误。Switch可以检查此规则的违规情况 - 违规的TLP是畸形TLP。如果进行了检查，这是一个与接收端口相关联的报告错误（见第6.2节）。
  • 如果r[2:0]的值表明Msg/MsgD在接收器处终止（100b或保留值），或者消息代码字段的值被定义并且对应于Switch必须理解的消息，则Switch必须根据消息处理规则处理该消息。
  • 如果r[2:0]的值表明聚集并路由到根复合体（101b），请参阅第5.3.3.2.1节了解消息处理规则。
  • 接收任何指定101b路由的Msg/MsgD请求，除了PME_TO_Ack之外，都是一个错误。
  • 在Switch的上游端口接收到PME_TO_Ack是一个错误。Switch可以（但非必须）检查这些规则的违规情况。这些检查是独立的可选检查（见第6.2.3.4节）。如果进行了检查，违规是畸形TLP，并且是与接收端口相关联的报告错误（见第6.2节）。

2.3.1 请求处理规则

本节描述了对所有TLPs进行初步处理后，如何处理接收到的请求。规则在图2-43所示的流程图中进行了图解。

• 如果请求类型不被设备支持（由于设计或配置设置），该请求就是不支持的请求（Unsupported Request），并根据第6.2节进行报告。
  • 如果请求需要完成，将返回一个状态为未知请求（UR）的完成状态（见第2.2.8.10节）。

• 如果请求是一条消息，并且消息代码、路由字段或Msg/MsgD指示符对应于未定义的组合，或者对应于设备功能不支持的消息（非厂商定义type1，不视为错误 - 见表F-1），该请求就是不支持的请求（Unsupported Request），并根据第6.2节进行报告。

  • 如果消息代码是支持的值，根据相应的消息处理规则处理消息；如果消息代码是被忽略的消息，并且接收器正在忽略它，则忽略该消息而不报告任何错误（见第2.2.8.7节）。

• 如果请求是一条消息，并且路由字段指示按ID路由，如果请求被具有type0头标的设备功能接收，强烈建议无论请求的目的ID字段中指定的总线号和设备号如何，都应将设备视为消息的目标。

  • 如果在目的ID中指定的功能未实现，强烈建议将请求作为不支持的请求处理，并按照第6.2节的规定进行报告。

如果请求不是消息，并且是支持的类型，硬件设计可能会根据一个定义好的编程模型进行优化，该模型确保某些类型的（否则合法的）请求永远不会发生。这样的实现可能会利用以下规则：

• 如果请求违反了设备功能的编程模型，功能可以选择性地将请求视为完成者中止（Completer Abort），而不是正常处理请求。
  • 如果请求被视为完成者中止，这是一个与功能相关联的报告错误（见第6.2节）。
  • 如果请求需要完成，将返回一个状态为完成者中止（CA）的完成状态（见第2.2.8.10节）。
• 否则（支持的请求类型，不是消息），处理请求。
  • 如果完成者由于设备特定的错误条件而永久无法处理请求，完成者必须（如果可能的话）将请求作为完成者中止（Completer Abort）来处理。
    • 这是一个与接收功能相关联的报告错误，如果错误可以隔离到组件中的特定功能，或者如果错误无法隔离，则与接收端口相关（见第6.2节）。
  • 对于配置请求，仅在重置后，设备有可能终止请求，但指示它暂时无法处理请求，但将来将能够处理请求 - 在这种情况下，使用配置请求重试状态（CRS）完成状态（见第6.6节）。设备被允许返回CRS的有效重置条件包括：
    • 冷复位（Cold Reset）、暖复位（Warm Reset）和热复位（Hot Reset）。
    • 功能层级重置（FLR）。
    • 为响应D3Hot到D0未初始化设备状态转换而启动的复位。

  • 设备功能明确不允许在软件启动的重置（FLR之外）后返回CRS，例如，通过设备的软件驱动程序写入设备特定的重置位。设备功能在表明它是配置就绪的（见第6.23节）之后，没有中间的有效重置（即FLR或常规重置）条件，或者如果功能的状态寄存器中的立即就绪位被设置，也是不允许返回CRS的。此外，设备功能在之前已经返回了成功完成状态后，没有中间的有效重置（即FLR或常规重置）条件，也是不允许返回CRS的。

  • 在服务请求的过程中，完成者可能会决定（通常是可以接受的）请求必须作为错误处理，在这种情况下，请求根据错误的类型进行处理。

    • 示例：一个PCI Express/PCI桥可能最初接受一个请求，因为该请求指定了一个映射到桥的次级侧的内存空间范围，但该请求在桥的PCI侧可能会执行主中止（MasterAbort）或目标中止（Target Abort）。从PCI Express的角度来看，这种情况下请求的状态是未知请求（UR，对于主中止）或完成者中止（CA，对于目标中止）。如果请求在PCI Express上需要完成，将返回相应的完成状态。

  • 如果请求是需要返回完成包的类型，根据完成结构规则生成完成包（见第2.2.9节）。
    • 完成状态由处理请求的结果确定。
    • 如果请求有ECRC校验失败错误，那么是否返回完成以及如果返回，使用哪个架构定义的值作为其完成状态，这是硬件设计的。然而，强烈建议完成者返回一个状态为未知请求（UR）的完成。
  • 在正常运行条件下，PCI Express端点和传统端点必须在不超过10微秒的时间内接受转发请求，这称为转发请求接受限制。设备必须（a）设计为在必要的时间限制内处理接收到的转发请求并返回相关的流量控制信用，或（b）依赖于一个受限的编程模型，以确保在设备无法在必要的时间限制内接受新的转发请求时，软件或其他设备永远不会向设备发送转发请求。

    • 不视为适用转发请求接受限制的正常运行条件包括：

      • 紧接着基础重置后的阶段（见第6.6节）。
      • TLP重传或链路重新训练。
      • 一个或多个丢失的流量控制包（FCPs）。
      • 设备处于诊断模式。
      • 设备处于不适合正常使用的设备特定模式。
    •  以下条件被视为正常运行条件，但它们引起的任何延迟不计入转发请求接受限制：
      • 上游TLP流量延迟上游FCPs。
      • 链路从低功耗状态退出。
      • 与其他虚通道上的流量进行仲裁。

  • 虽然不是要求，但强烈建议RCiEPs（根复合体集成端点）也遵守转发请求接受限制。

• 如果设备支持作为I/O写请求的目标，这些是非转发请求，强烈建议每个关联的完成在与转发请求接受相同的时间限制内返回，尽管这不是一个要求。

2.3.1.1 读请求的数据返回

• 针对内存读取请求的单个完成可能提供少于请求的全部数据量，只要对于给定请求的所有完成在组合起来时返回了读取请求中请求的数据量。
  • 不同请求的完成不能组合。
  • I/O和配置读取必须用恰好一个完成来完成。

  • 对于完成（Completion），完成状态仅对应于与该完成一起返回的数据的状态。

    • 状态不是成功完成的完成将终止单个读取请求的完成。

      • 在这种情况下，长度字段中的值是未定义的，并且必须由接收器忽略。

• 完成不得包含超过Max_Payload_Size允许的最大数据量。
  • 接收器必须检查此规则的违规情况。请参阅第2.2节。

注意：这只是适用于所有带有数据有效载荷的TLPs的规则的一个特定案例。

• 内存读取请求可以通过一个或在某些情况下多个完成来完成。

• 读取完成边界（Read Completion Boundary，RCB）决定了完成者被允许将单个读取请求的响应分成多个完成的自然对齐地址边界。

  • 对于根复合体，RCB是64字节或128字节。 这个值在链路控制寄存器中报告（见第7.5.3.7节）。

注意：桥接器和端点可以实现一个相应的命令位，该位可以由系统软件设置，以指示根复合体的RCB值，允许桥接器或端点在根复合体的RCB为128字节时优化其行为。

• 对于所有其他系统元素，RCB（读取完成边界）是128字节。
• 不跨越RCB字节整数倍自然对齐地址边界的请求的完成必须包含请求中指定的所有数据。
• 跨越RCB字节整数倍地址边界的请求允许使用多个完成来完成，但须遵守以下规则：

  • 第一个完成必须从请求中指定的地址开始，如果成功，必须结束于以下之一：

    • 满足整个请求的地址。
    • 请求的开始和结束之间的地址边界，位于RCB字节的整数倍。

  • 如果最终的完成是成功的，它必须结束于满足整个请求的地址。

  • 第一个和最终完成之间的所有完成（不包括第一个和最终完成），其长度必须是RCB字节的整数倍。

• 接收器可以（但非必须）检查RCB的违规情况。如果实施此检查的接收器确定一个完成违反了此规则，它必须将该完成作为畸形TLP处理。
  • 这是与接收端口相关联的报告错误（见第6.2节）。
• 单个读取请求的多个内存读取完成必须按递增的地址顺序返回数据。
• 如果单个读取请求的所有内存读取完成都有成功的完成状态，它们的负载之和必须等于请求的大小。
• 对于每个内存读取完成，字节计数字段必须指示完成请求所需的剩余字节数，包括与完成一起返回的字节数，除非设置了BCM（字节计数修改）位。
  • 完成内存读取请求所需的总字节数如表2-38所示计算。

  • 如果内存读取请求是通过使用多个完成来完成的，那么每个连续完成的字节计数值是前一个完成指示的值减去前一个完成返回的字节数。

• 完成数据区域从请求中指定的双字（DW）地址开始。在第一个或唯一的完成的第一个或唯一数据双字中，只有在请求中的first BE（字节使能）字段配置为有效的字节才包含有效数据。在first BE字段中配置为无效的字节将返回未定义的内容。
• 在最后一个成功的完成的最后一个数据双字中，只有在请求中的last BE字段配置为有效的字节才包含有效数据。在last BE字段中配置为无效的字节将返回未定义的内容。
• 所有完成数据字节，包括那些内容未定义的字节，在所有的CRC（循环冗余校验）计算中都会被包含。
• 图2-44展示了上述情况的一个示例。该示例假设返回了一个完成TLP（事务层包）。

• 对于所有内存读取完成，低地址字段必须指示与完成一起返回的使能的首字节数据的字节地址的低位。

  • 对于第一个（或唯一的）完成，完成者可以从请求地址的最低有效5位与如表2-39所示形成的2位字节级地址连接起来生成该字段。

  • 对于任何后续的完成，低地址字段总是为零，除非由具有64字节RCB（读取完成边界）值的根复合体生成的完成。在这种情况下，低地址字段的最低有效6位总是为零，而低地址字段的最高位将根据64字节数据负载的对齐方式进行切换。

• 当生成的状态不是成功完成的读取完成时：
  • 不包括完成中的数据。
    • 代替使用Cpl（或CplLk）编码，而不是CplD（或CplDLk）。
  • 这个完成是请求的最终完成。

    • 完成者不得为该请求传输额外的完成。

      • 示例：完成者将请求分成四个部分进行服务；第二个完成具有完成者中止（Completer Abort）的完成状态；完成者终止了对该请求的服务，并没有传输剩余的两个完成。

  • 字节计数字段必须指示完成请求所剩余的字节数（就好像完成状态是成功完成一样）。

  • 低地址字段必须指示如果完成状态是成功完成，将与完成一起返回的使能的首字节数据的字节地址的低位。 

2.3.2 完成处理规则

• 当设备接收到的完成与该设备发出的任何未完成请求的事务ID不匹配时，该完成被称为“意外完成”（Unexpected Completion）。
• 如果接收到的完成与未完成请求的事务ID匹配，但在其他方面与相应的请求不匹配（例如，属性、流量类别、字节计数、低地址等存在问题），强烈建议接收器将完成作为畸形TLP（事务层包）处理。
  • 完成者不得检查完成中的IDO属性（属性位2），因为如第2.2.6.4节和第2.2.9节所述，请求者不需要将IDO的值从请求复制到该请求的完成中。
  • 然而，如果完成在其他方面正确形成，允许接收器将完成作为意外完成处理。
• 当Switch的入口端口接收到无法转发的完成时，该入口端口必须将完成作为意外完成处理。这包括针对以下目标的完成：
  • 与上游端口关联的设备中不存在的功能。
  • 与上游端口关联的总线上不存在的设备。
  • Switch内部结构中不存在的设备或功能。
  • 上游端口的总线号范围内但不被任何下游端口声明的总线号。
• 接收到意外完成是一个错误，必须根据以下规则处理：
  • 接收到意外完成的组件必须丢弃完成。
  • 意外完成是与接收端口相关联的报告错误（见第6.2节）。

注意：意外完成主要假设是由于Switch错误路由完成引起的。在这种情况下，请求的请求者可能不会为其请求接收到完成，请求者的完成超时机制（见第2.8节）将终止请求。

• 状态不是成功完成或配置请求重试状态（仅响应配置请求）的完成必须导致请求者：
  • 释放与请求关联的完成缓冲区空间和其他资源。
  • 通过请求者特定的机制处理错误（见第6.2.3.2.5节）。
  • 如果完成在已启动FLR（功能层级重置）和目标功能完成FLR之间到达，允许将完成作为意外完成处理或在更新流量控制信用后默默丢弃（不记录或将其标记为错误）。一旦FLR完成，接收到的对应于FLR之前发出的请求的完成必须作为意外完成处理，除非该功能已重新启用以发出请求。
• 根复合体对配置请求的配置请求重试状态的完成的处理是硬件实现的，除了系统重置后的时间（见第6.6节）。对于支持CRS（配置请求重试状态）软件可见性的根复合体，适用以下规则：
  • 如果未启用CRS软件可见性，根复合体必须将配置请求作为新请求重新发出。
  • 如果启用了CRS软件可见性（见下文）：

  • 对于包含设备功能配置空间头标的供应商ID字段的两个字节的配置读取请求，根复合体必须通过返回供应商ID字段的读数据值为0001h以及请求中包含的任何额外字节的全1的值来完成对主机的请求。这个读数据值已被PCI-SIG特别为此用途保留，并不对应任何分配的供应商ID。

  • 对于配置写请求或任何其他配置读取请求，根复合体必须将配置请求作为新请求重新发出。

  • 根复合体实现可以选择限制配置请求/CRS（配置请求重试状态）完成状态循环的次数，然后再确定请求的目标存在问题并采取适当的行动，例如，将请求作为失败的事务完成到主机。

  • 可以通过根控制寄存器中的CRS软件可见性使能位（见第7.5.3.12节）启用CRS软件可见性，以控制单个根端口的根复用体行为。或者，可以通过根复合体寄存器块（RCRB）控制寄存器中的CRS软件可见性使能位管理根复用体行为，如第7.9.7.4节所述，允许通过单个使能位控制一个或多个根端口或RCiEPs的行为。对于这种替代情况，每个根端口或RCiEP通过根复用体链路声明功能（见第7.9.8节）中的RCRB头关联声明其与特定使能位的关联。每个根端口或RCiEP最多可以被一个使能位控制。因此，例如，禁止在其根控制寄存器中包含使能位的根端口声明与在其RCRB头功能中也包含使能位的RCRB头关联。根端口或RCRB头功能中存在使能位由相应的CRS软件可见性位指示（见第7.5.3.13节和第7.9.7.3节）。

• 对于非配置请求的请求，使用配置请求重试状态的完成是非法的。接收器可以（但非必须）将这些违规报告为畸形TLP。

• 使用保留的完成状态值的完成被视为如果完成状态是不支持的请求（UR）。

• 状态为不支持请求或完成者中止的完成使用传统的PCI报告机制报告（见第7.5.1.1.4节）。

  注意，触发生成此类完成的错误条件由完成者在第6.2节中描述报告。

• 当接收到的读取完成或原子操作完成的状态不是成功完成时：

  • 不包括完成中的数据。
    • 使用Cpl（或CplLk）编码而不是CplD（或CplDLk）。
  • 这个完成是请求的最终完成。
    • 请求者必须认为请求已终止，并不期望更多的完成。
      • 对于早期接收到的部分完成的处理是硬件实现的。
      • 示例：请求者为其发出的128字节读取请求接收到了32字节的读取数据，然后它接收到一个具有完成者中止完成状态的完成。然后，请求者必须释放为该特定读取请求分配的内部资源。