本文将从PCIe角度讲SR-IOV。
PCIe 系列SR-IOV导航：
【PCIe 5.0 - 100】SR-IOV【1】
【PCIe 5.0 - 101】SR-IOV【2】
【PCIe 5.0 - 102】SR-IOV【3】
【PCIe 5.0 - 103】SR-IOV 【4】
PCIe Single Root I/O Virtualization and Sharing
9.1 架构概述
行业内，通过使用虚拟化技术来提高硬件资源的有效利用率（即应用程序执行）已经付出了巨大的努力。SR-IOV使多个系统映像 (SI) 能够共享 PCI 硬件资源。
为了说明如何使用该技术来提高有效资源利用率，可以考虑图 9-1 中所示的通用平台配置。
- PCI Root Complex(RC),含：
- 处理器 – 通用、嵌入式或专用处理元件
- 内存 – 通用或嵌入式
- Root Complex Integrated Endpoints (RCiEPs)
- PCIe Root Port (RP) – 每个 RC 可以支持一个或多个 RP，每个 RP 代表一个单独的层次结构。 每个层次都被称为一个单一的根层次，以将其与 MR-IOV 中定义的多层次技术区别开来。
- PCIe Switch – 提供 I/O 扇出和连接
- PCIe 设备 – 多种 I/O 设备类型（如，网络、存储等）
- 系统映像 – 软件，例如用于执行应用程序的操作系统或受信任的服务，（例如，共享或非共享的 I/O 设备驱动程序。）
为了减少平台资源开销，PCI-SIG® 开发了包含在该规范中的 SR-IOV 技术。SR-IOV 技术的好处是：
- 能够避免 VI 参与主要数据移动操作——DMA、内存空间访问、中断处理等。消除 VI 拦截和每个 I/O操作的处理可以提供重要的应用程序和平台性能改进。
- 通过Single Root PCI Manager (SR-PCIM) 控制 SR-IOV 资源配置和管理的标准化方法。SR-PCIM 实现不在PCIe规范的范围。
- 能够通过在设备内配置潜在的大量 I/O Functions来降低硬件要求和相关成本。
- 能够将 SR-IOV 与其他 I/O 虚拟化技术（例如地址转换服务 (ATS)、地址转换和保护表 (ATPT) 技术以及中断重映射技术）集成，以创建强大、完整的 I/O 虚拟化解决方案。
图 9-3 说明了一个支持 SR-IOV 的平台示例。
- SR-PCIM – 负责配置 SR-IOV Extended Capability、PFs和VFs以及处理相关错误事件和整体设备的软件控制，例如功耗管理和热插拔服务。
- 可选的Translation Agent (TA) – TA 是负责将 PCIe事务中的地址转换为相关平台物理地址的硬件或硬件和软件的组合。TA 可能包含Address Translation Cache (ATC) 以加速访问转换表。TA还可以支持Address Translation Services(ATS)，它使 PCIe Function能够在 DMA 访问相关内存之前获得转换地址。
- 可选的Address Translation and Protection Table(ATPT)——ATPT包含TA访问的一组地址转换，以处理 PCIe 请求——DMA Read、DMA Write或中断请求。
- 在 PCIe 中，中断被视为Memory Write操作。通过Requester Identifier和PCIe事务中包含的地址的组合，可以将中断路由到对相关 I/O Function透明的任何目标（例如，处理器内核）。
- DMA Read和Write请求通过Routing ID 和 PCIe 事务中包含的地址的组合进行转换。
- 可选的Address Translation Cache (ATC) – ATC可以存在于一个平台内的两个位置 – 位于 TA 内，可集成在 RC 内或位于其上方；或位于 PCIe 设备内。在 RC 中，ATC 可以加速translation查找。在设备内，ATC 通过 ATS 技术填充，表明它们包含转换地址的 PCIe 事务可能会绕过平台的 ATC，以提高性能而不影响与 ATPT 相关技术的好处。
- 可选的Access Control Services (ACS) – ACS 定义了 PCIe拓扑中的一组控制点，以确定 TLP 是否应正常路由、阻塞或重定向。在支持 SR-IOV 的系统中，ACS 可用于防止分配给 VI 或不同 SI 的设备的Functions相互或配对设备进行通信。重定向可以允许Translation Agent在做出对等转发决定之前转换Upstream内存TLP地址。可选的 ACS P2P Egress Control可以提供选择性阻塞。ACS 受制于与 ATS 的交互。
- Physical Function(PF) – PF 是一种 PCIe 功能，它支持 SR-IOV 功能并且可由 SR-PCIM、VI 或 SI 访问。
- Virtual Function(VF) – VF 是一种轻量级PCIe 功能，可由 SI 直接访问。
- 至少，与Function主要数据移动相关的资源可供 SI 使用。配置资源应限于受信任的软件组件，例如 VI 或 SR-PCIM。
- 一个 VF 可以由不同的 SI 串行共享，（即，一个 VF 可以分配给一个 SI，然后重置并分配给另一个 SI。）
- 一个 VF 可以有选择地从一个 PF 迁移到另一个PF。迁移过程可以通过PCIe定义的配置控制来推动。
- 与 PF 关联的所有 VF 必须与 PF 具有相同的设备类型（例如，相同的网络设备类型或相同的存储设备类型。）
要将 PCIe 设备与支持 PCIe SR-IOV 的设备进行比较和对比，请查看以下一组图。图 9-4 显示了一个示例 PCIe 兼容设备。
此图说明了具有以下特征的Multi-Function PCIe 设备：
- PCIe设备共享公共PCIe链路。所有Function共享的链路和PCIe Functions通过Function 0进行管理。
- 虽然此图仅说明了三个Functions，但通过使用Alternative Routing Identifier(ARI) Function，PCIe 设备最多可支持256个Functions。
- 所有Function都使用通过PCI枚举过程捕获的单个Bus Number。 - 在本示例中，每个PCIe Function都支持ATS capability，因此有一个关联的 ATC 来管理 ATS获得的转换地址。
- 每个PCIe Function都有一组独特的物理资源，包括单独的配置空间和BAR。
- 每个PCIe Function可以分配给一个SI。为了防止一个SI影响另一个SI，所有 PCIe 配置操作都应该由VI拦截和处理。
如该图所示，硬件资源随着提供的Function数量而扩展。根据设备的复杂性和大小，每个Function的增量成本会有所不同。为了减少增加的硬件成本，可以使用SR-IOV构建设备以支持单个 PF和多个VF，如图 9-5 所示。
- PF兼容PCIe。
- 最初和Conventional Reset后，支持本规范中定义的支持SR-IOV capabilities的PCIe Function应禁用SR-IOV。
- 要发现PF支持的page大小及其关联的VF，需要读取Supported Page Sizes配置字段。
- PF命名PF M 表示Function编号为M 的PF。
- VF命名VF M,N 表示与PF M 关联的第N 个VF。VF 从1 开始编号，因此与PF M 关联的第一个VF 是VF M,1。
- 每个VF与PF共享许多公共配置空间字段；（即，字段适用于所有VF并通过单个PF 控制。共享减少了实现每个VF的硬件资源需求。）
- VF使用与PF相同的配置机制和报头类型。
- 与给定PF关联的所有VF共享一个VF BAR集，并共享控制访问的 SR-IOV extended capability中的 VF Memory Space Enable(MSE)位到VF 存空间。也就是说，如果VF MSE 位为Clear，则为所有VF分配的内存映射空间都被禁用。
- InitialVFs和TotalVFs字段用于发现可以与PF关联的最大VF数。
- 如果设备不支持VF迁移，则TotalVFs和InitialVFs应包含相同的值。如果Device支持VF迁移，则在读取TotalVFs时，PF必须返回可以分配给PF的VF 数量。对于这样的设备，当读取InitialVFs时，PF必须返回分配给PF的初始VF数。
- 每个Function、PF和VF都分配有唯一的Routing ID。每个PF的Routing ID按照2.2.4.2节构造。每个VF的Routing ID是使用其关联PF的Routing ID和该PF的SR-IOV Extended Capability中的字段确定的。
- 所有 PCIe 和 SR-IOV 配置访问都假定是通过可信软件组件（例如VI或SR-PCIM）进行的。
- 每个VF都包含提供特定Function服务所需的一组非共享物理资源（例如，工作队列、数据缓冲区等资源）。这些资源可以由SI直接访问，无需VI或SR- PCIM干预。
- 一个或多个VF可以分配给每个 SI。
- 虽然此示例说明了PF内的单个 ATC，但任何ATC的存在都是可选的，不排除实现设备内每个VF的ATC。
- 内部路由是特定实现的。
- 虽然存在许多关于PF操作的潜在使用模型，但一个常见的使用模型是使用PF来引导设备或平台，并严格在VI的控制下进行。一旦配置了SR-IOV功能，VF能够分配给单个SI，PF将承担更多的监督角色。例如，PF可用于管理特定设备的功能，例如对每个VF的内部资源分配、对共享资源的VF仲裁，例如 PCIe Link或特定Function的Link（例如，网络或存储链路）等. 这些策略、管理和资源分配操作超出了本规范的范围。
另一个示例使用模型如图 9-6 所示。在此示例中，设备支持多个 PF，每个 PF 都有自己的一组 VF。
- 每个 PF 可以分配任意数量的 VF。对于设备内的所有 PF，每个 PF 的 VF 数量不需要相同。
- ARI Extended Capability允许将Functions分配给Function Groups并定义如何配置Function Group仲裁。PF和VF可以分配给Function Groups并利用相关的仲裁功能。但是，在每个Function Groups内，仲裁仍然是特定实现的。
- PF 和 VF 之间的内部路由是特定实现的。
- 对于某些使用模型，所有 PF 可能是相同的设备类型；（例如，所有 PF 都提供相同的网络设备或都提供相同的存储设备功能。）对于其他使用模型，每个 PF 可能代表不同的设备类型；（例如，在图 9-6 中，第一个 PF 可能代表网络设备，而另一个代表加密设备。）
- 在设备类型之间存在使用模型依赖关系的情况下，例如对于作为网络设备类型的每个VF，每个SI还需要一个VF，它是一种加密设备类型。SR-IOV 提供了一种指示这些依赖关系的方法。用于构建这些依赖关系以及将 VF 的依赖集分配给给定 SI 的策略超出了PCIe规范的范围。
如前面的示例所示，PF 和 VF 的数量可以根据使用模型要求而变化。为了支持广泛的选项，SR-IOV 设备可以支持以下数量和组合的 PF 和 VF：
- 使用Alternative Routing Identifier (ARI) 功能，设备最多可以支持 256 个 PF。Function Number分配是特定实现的，并且在整个 256 Function Number空间中可能是疏散的。
- PF 只能与设备捕获的Bus Number相关联，如图 9-7 所示。
- SR-IOV 设备可能消耗多个Bus Number。VF 可以与设备总线编号范围内的任何Bus Number相关联 - 捕获的总线编号加上由软件配置的任何其他Bus Number。有关详细信息，请参阅第 9.2.1.2 节。
- 使用多个Bus Numbers使设备能够支持非常多的VF – 最多可达Routing ID 空间的大小减去用于识别中间总线的位。
- 如果软件没有配置足够的附加Bus Numbers，则为附加Bus Numbers实施的VF可能不可见。
ARI 功能使设备能够支持多达 256 个Functions—Functions、PF 或任意组合的 VF—与捕获的Bus Number相关联。如果使用模型不需要超过 256 个Functions，则强烈建议实现将所有Functions、PF 和 VF 放在捕获的Bus Number内，并且不需要额外的Bus Number来访问 VF。
在最后一个示例（图 9-8）中，设备实现可以混合任意数量的Functions、PF 和 VF。
- 每个设备必须包含一个Function 0。Function 0 可能是一个PF（即，它可能包括SR-IOV扩展能力）。
- 任何Function组合都可以与捕获的Bus Number相关联。非VF只能与捕获的Bus Number相关联。
- 如果支持ARI Function，可以将Function分配给Function Groups。如果不支持ARI，Functions仍然可以使用 6.3.3.4 节中定义的Function仲裁。
9.2 PCI技术交互
建立明确的互操作性要求对于任何技术的成功都至关重要。为此，组织了 PCI-SIG I/O 虚拟化规范，以最大限度地提高兼容实施的互操作性潜力。从概念上讲，这被视为一组同心圆，用于定义功能如何分层以构建具有 IOV 功能的组件，如图 9-9 所示。
- 在其核心，I/O 虚拟化规范建立在 PCIe基本规范之上。所有IOV的实现都必须符合 PCIe1.1或更高版本。在适用的情况下，IOV规范会注明这些版本之间的相关差异。
- 没有任何IOV规范涉及物理层。
- SR-IOV不涉及PCIe中指定的数据链路或事务层。
- [MR-IOV]不涉及PCIe中指定的事务层。
- 所有I/O虚拟化功能都通过在PCI Express 扩展配置空间中实现的新PCI Express capabilities进行通信。
- I/O虚拟化规范对PCI或PCI-X规范没有影响。
- 层次结构可以由PCI Express 和 PCI Express 到 PCI/PCI-X 桥的混合组成。
- PCI Express 到 PCI/PCI-X Bridge和 PCI/PCI-X 设备可以由多个 SI 串行共享。
- ATS定义了适用于任何Function的可选功能。SR-IOV组件可以支持ATS。
- 设备要实现SR-IOV，SR-IOV要求设备完全符合PCIe。
- 层次结构可以由SR-IOV 和非SR-IOV组件的混合组成。例如，层次结构可能包含SR-IOV和非SR-IOV端点设备的任意组合。
9.2 SR-IOV初始化与资源分配
9.2.1 SR-IOV Resource
以下部分描述了软件如何确定设备是否支持 SR-IOV，并通过Virtual Function配置空间识别 VF 资源。
9.2.1.1 配置SR-IOV Capabilities
本节介绍在enable PF的IOV Capabilities之前必须配置的字段。通过在 SR-IOV Extended Capability中设置 PF的VF Enable位（参见第 9.3.3.3.1 节）来启用 VF。
NumVFs 字段（参见第 9.3.3.7 节）定义了在关联PF中设置VF Enable时启用的VF数量。
9.2.1.1.1 配置VF BAR
本节介绍如何配置 VF BAR 以映射内存空间。VF 不支持 I/O 空间，因此 VF BAR 不应指示 I/O 空间。
System Page Size字段（见9.3.3.13 节）定义了当 PF 的 IOV 功能启用时系统将用于映射 VF 的 PCIe 内存地址的page大小。PF 使用System Page Size字段将每个 VF BAR 定义的内存空间缝隙与system page边界对齐。为System Page Size选择的值必须是SR-IOV extended capability中支持的page size之一（请参阅第 9.3.3.12 节）。
VF BAR 的行为与PCI Memory Space BARs的行为相同（参见第 7.5.1.2.1 节），除了 VF BAR 描述每个 VF 的孔径，而 PCI BAR 描述单个Function的孔径。如果实现了VF Resizable BAR Extended Capability（请参阅第 9.3.7.5 节），则 VF BAR 中某些位的属性会受到影响。
- 7.5.1.2.1 节中描述的用于确定Function BAR 的内存空间的行为适用于每个VF BAR。即每个VF BAR所需的内存孔径大小可以通过写全“1”然后读取VF BAR来确定。回读的结果必须按照第 7.5.1.2.1 节中的描述进行解释。
- 分配与第一个 VF 关联的每个 BAR 的起始内存空间地址的行为也如第 7.5.1.2.1 节所述。即写入每个 VF BAR 的地址被 Device 用作第一个 VF 的起始地址。
- VF BAR 与第 7.5.1.2.1 节中描述的 BAR 之间的区别在于，对于每个 VF BAR，与第二个和更高 VF 相关联的内存空间来自第一个 VF 的起始地址和内存空间孔径。对于任何给定的 VF (v)，任何实现的 BAR (b) 的内存空间孔径的起始地址根据以下公式计算：
BARb VFV 起始地址 = VF BARb + (v – 1) x (VF BARb aperture size)
其中 VF BARb孔径大小是 VF BARb的大小，由9.3.3.14 节中描述的常用 BAR 探测算法确定。
直到 VF Enable 和 VF MSE 都已设置（参见 9.3.3.3.1 节和9.3.3.3.4 节）后，才会启用 VF 存储空间。请注意，更改System Page Size（ 9.3.3.13 节）可能会影响 VF BAR 孔径大小。
图 9-10 显示了 PF 和 VF 内存空间孔径的示例。
9.2.1.2 VF
SR-IOV extended capability中的 First VF Offset 和 VF Stride 字段是 16 位Routing ID偏移量。这些偏移用于计算具有以下限制的VF的Routing ID：
- PF 中 NumVFs 中的值（第 9.3.3.7 节）可能会影响First VF Offset（第 9.3.3.9 节）的值和VF Stride（第 9.3.3.10 节）中的那个 PF。
- 设备编号最低的 PF（例如 PF0）中的 ARI Capable Hierarchy（第 9.3.3.3.5 节）中的值可能会影响设备所有 PF 中的 First VF Offset 和 VF Stride 中的值。
- PF 的 NumVFs 只能在该 PF 的 VF Enable（第 9.3.3.3.1 节）为0时更改。
- ARI Capable Hierarchy（第 9.3.3.3.5 节）只能在设备的所有 PF 中的 VF Enable 为 Clear 时更改。
表 9-1 描述了用于确定与每个 VF 关联的Routing ID 的算法。
| VF Number | VF Routing ID |
|---|---|
| VF 1 | (PF Routing ID + First VF Offset) Modulo 216 |
| VF 2 | (PF Routing ID + First VF Offset + VF Stride) Modulo 216 |
| VF 3 | (PF Routing ID + First VF Offset + 2 * VF Stride) Modulo 216 |
| … | … |
| VF N | (PF Routing ID + First VF Offset + (N-1) * VF Stride) Modulo 216 |
| … | … |
| VF NumVFs (last one) | (PF Routing ID + First VF Offset + (NumVFs-1) * VF Stride) Modulo 216 |
此路由 ID 计算中使用的所有算法都是 16 位无符号整数。
所有 VF 和 PF 必须具有不同的Routing ID。任何PF或VF的Routing ID 不得与任何其他PF或VF的Routing ID 重叠，前提是设备的所有PF中的 NumVF 设置有效。
VF Stride和First VF Offset是常数。除非在本节前面有说明，否则它们的值可以不受设备的Functions的设置影响。
VF 可能驻留在与相关联的 PF 不同的Bus Number(s)上。如，这可能发生在：First VF Offset的值为 0100h。VF 不应位于数字小于其关联 PF 的Bus Number上。位于与其关联 PF 相同的Bus Number上的 VF 不应位于数字小于 PF 的Device Number上（紧接在Downstream Port下方的 SR-IOV 设备的设备编号始终为 0，因此始终满足这个条件）。
SR-IOV RCiEP 设备的 VF与其 PF 与相同的Root Complex Event Collector（如果有）相关联。此类 VF 不会在 Root Complex Event Collector 的 Root Complex Event Collector Endpoint Association Extended Capability 中报告。
根据第 2.2.6.2 节，与Upstream Port关联的支持 SR-IOV 的设备从任何Type 0 Configuration Write Request中捕获Bus Number。支持 SR-IOV 的设备不会从任何Type 0 Configuration Write Request中捕获Bus Number。支持SR-IOV的RCiEP使用特定实现的机制来分配它们的Bus Number。
Bus Number的切换处理与 PCIe 相同。在基本 PCIe 中，Switch将Secondary Bus Number（含）到Subordinate Bus Number（含）范围内的所有配置请求发送到设备。寻址Secondary Bus Number的Type 1 Configuration Requests被转换为Type 0 Configuration Requests，而寻址Secondary Bus Number（独占）和Subordinate Bus Number（含）之间的Bus Numbers的Type 1 Configuration Requests作为Type 1 Configuration Requests转发到设备。
注意：Bus Numbers是一种有限资源。建议设备避免在其Bus Number使用过程中留下“漏洞”，浪费Bus Number。
所有 PF 必须位于设备捕获的Bus Number上。
跨越多个Bus Numbers的 VF
作为一个例子，考虑一个支持单个 PF 的 SR-IOV 设备。最初，只有 PF 0 可见。软件设置支持 ARI 的层次结构。根据 SR-IOV Extended Capability确定：InitialVFs 为 600，First VF Offset 为 1，VF Stride 为 1。
- 如果软件将 NumVFs 设置在 [0 … 255] 范围内，则设备使用单个Bus Number。
- 如果软件将 NumVFs 设置在 [256 … 511] 范围内，则设备使用两个Bus Number。
- 如果软件将 NumVFs 设置在 [512 … 600] 范围内，则设备使用三个Bus Numbers。
PF 0 和 VF 0,1 到 VF 0,255 始终位于第一个（捕获到的）Bus Number上。VF 0,256 到 VF 0,511 始终位于第二个Bus Number（捕获到的总线编号加 1）上。VF 0,512 到 VF 0,600 始终位于第三个Bus Number（捕获到的总线编号加 2）上。
软件应配置 Switch Secondary 和 Subordinate Bus Number 字段以将足够的Bus Numbers路由到设备。如果没有足够的Bus Numbers可用，软件应通过在启用 SR-IOV 之前不启用 SR-IOV 和/或减少设备的部分或所有 PF 的 NumVF 来降低设备的Bus Numbers要求。
在某些 PF n 中设置 VF Enable 后，设备必须启用 VF n,1 到 VF n,m（含），其中 m 是 InitialVFs 和 NumVFs 中的较小者。接收到以enabled VF 为目标的Type 0 Configuration Request 的设备必须正常处理该请求。接收到针对未位于捕获的Bus Numbers上的eanbled VF 的Type 1 Configuration Request的设备必须正常处理该请求。接收以设备捕获的总线号为目标的Type 1 Configuration Request的设备必须遵循处理Unsupported Requests的规则。此外，如果设置了 VF MSE，则每个enabled VF 必须响应寻址与该 VF 关联的内存空间的 PCIe 内存事务。
PCIe结构中不存在没有enabled Function（即，m 以上的 VF 功能）。根据第 2.3.1 节，寻址不存在的Function将导致返回Unsupported Requests(UR)。这包括附加的Bus Numbers的Function。
带有PF和Switch Functions的Multi-Function Device
SR-IOV 设备可能消耗多个Bus Numbers。除了第一个Bus Number之外的其他Bus Numbers是连续的，并且紧跟在分配给设备的第一个Bus Number之后。如果 SR-IOV 设备还包含 PCI-PCI Bridge（带有Type 1 Configuration Space header），则在为这些Bridges programming Secondary Bus Number时必须考虑 SR-IOV 的使用情况。软件应首先确定 VF 使用的最后一个Bus Number，然后配置任何位于同一位置的网桥以使用高于该值Bus Number。
9.2.1.3 Function依赖表
PCI 设备可能在Function之间具有特定的依赖关系。例如，Function 0 和Function 1 可能提供不同的机制来控制相同的底层硬件。在这种情况下，设备编程模型可能要求将这些相关Functions作为一组分配给 SI。
Function依赖表用于描述这些依赖（或表明不存在Function依赖）。软件应将 PF 和 VF 分配给 SI，以满足相关性。
有关详细信息，请参阅9.3.3.8 节。
9.2.1.4 中断资源分配
如果分配了中断资源，PF 和 VF 支持 MSI、MSI-X 中断或两者。但VF 不应实现 INTx。
9.2.2 Reset 机制
本节介绍 PCI-base-defined-reset 机制如何影响支持 SR-IOV 的设备。它还描述了用于Rest单个 VF 和单个 PF 及其关联 VF 的机制。
9.2.2.1 SR-IOV Conventional Reset
根据6.6.1 节中的规则，对支持 SR-IOV 的设备进行Conventional Reset会导致所有Functions（包括 PF 和 VF）重置为其原始的上电状态。 9.3 节描述了定义的字段的行为。
注意：Conventional Reset会清除 PF 中的 VF Enable。因此，在Conventional Reset后 VF不再存在。
9.2.2.2 针对VF的FLR
VF必须支持Function Level Reset (FLR)。
注意：软件可能会使用 FLR 来重置 VF。VF 的 FLR 会影响 VF 的状态，但不影响其在 PCI Configuration Space或 PCI Bus地址空间中的存在。PF 的 SR-IOV extended capability中的 VFs BARn 值（参见第 10 节第 9.3.3.14 节）和 VF MSE（参见第 9.3.3.3.4 节）,以及VF Resizable BAR capability的值不受发给 VF 的 FLR 的影响。
9.2.2.3 针对PF的FLR
PF必须支持FLR。
FLR 发到 PF 会重置 PF 状态以及 SR-IOV extended capability，包括 VF Enable，这意味着 VF 不再存在。
9.2.3 IOV再初始化与再分配
如果 VF Enable 在前面设置后又被清除，则与 PF 关联的所有 VF 不再存在，并且不得再发出 PCIe 事务或响应Configuration Space或Memory Space访问。清除VF Enable后，VF 不得保留任何状态（包括粘滞位,sticky bit）。
9.2.4 VF Migration
VF 迁移是[MR-IOV]中的一个可选功能。不支持MR-IOV Extended Capability的设备不支持 VF 迁移功能。
在Multi-Root系统中，可以在Virtual Hierarchies之间迁移 VF。
要发生 VF 迁移，必须设置VF Migration Capable和VF Migration Enable。VF Migration Capable向 SR-PCIM 指示存在VF Migration Hardware并且Multi-Root PCI Manager(MR-PCIM) 已启用它。VF 迁移的硬件支持是可选的。SR-PCIM 对 VF 迁移的支持也是可选的。
VF Migration Enable 向设备硬件和 MR-PCIM 指示 SR-PCIM 也启用了 VF 迁移。
支持 VF Migration对 SR-PCIM 有以下要求：
- 需要确定 VF 是Active, Dormant（休眠）, 或Inactive。Active VF 可供Single Root(SR)使用。Dormant VF 可以由 SR 配置，但不会发出事务。SR 无法使用Inactive VF。
- 需要参与Migrate In操作。Migrate In 操作用于向 SR 提供 VF。Migrate In 操作由 MR-PCIM 发起。SR-PCIM 可以接受迁移操作并将 VF 移动到 Active.Available 状态。
- 需要参与Migrate Out操作。Migrate Out作用于请求从 SR 使用的Active VF 中正常删除。SR-PCIM 可以接受 Migrate Out 并将 VF 移动到 Inactive.Unavailable 状态。
- 需要处理Migrate In Retractions。这是发生在 MR-PCIM 撤回向 SR 提供的 VF 并且 VF 移回Inactive.Unavailable 状态时。
9.2.4.1 VF状态初始化
本节介绍VF Migration State Array中的初始值。
如果 InitialVFs不为零，则 VF1 到 VFInitialVFs处于 Active.Available 状态。如果 TotalVFs（第 9.3.3.6 节）大于 InitialVFs，则 VFInitialVFs+1 到 VFTotalVFs 处于Inactive.Unavailable状态。如果VF Migration Enable被清除，则不使用高于 InitialVF 的 VF。
如果 InitialVFs 为 0，则没有 VF处于Active.Available状态。如果 TotalVFs 等于 InitialVFs，则所有 VF 都处于 Active.Available 状态。如果 TotalVFs 为 0，则没有 VF 与此 PF 相关联，并且没有VF Migration State Array。
图 9-11 描述了这个初始 VF 状态。
9.2.4.2 VF 迁移状态转换
VF 迁移遵循图 9-12 所示的状态图。显示的状态值包含在与 VF 关联的 VF 状态数组条目中。实线指示的状态转换由 MR-PCIM 发起。由点划线表示的状态转换由 SR-PCIM 发起。
SR-PCIM 通过将新值写入 VF 迁移状态阵列来启动状态转换。当 SR-PCIM 尝试启动除表 9-2 之外的任何状态转换时，设备会忽略写入的事务并且不会发生状态转换：
| 当前VF Enable | 当前VF State | 写入的VF Enable | 写入的VF State | 含义 |
|---|---|---|---|---|
| 1 | Dormant.MigrateIn | 1 | Active.Available | SR Activate VF |
| 1 | Active.Available | 1 | Dormant.MigrateIn | SR Deactivate VF |
| 1 | Active.MigrateOut | 1 | Inactive.Unavailable | SR Complete Migrate Out |
| 1 | 任意值 | 0 | 任意值 | SR Disables all VFs |
| 0 | 任意值 | 1 | 任意值 | SR Enables all VFs。VF 根据 VF 编号和 InitialVF 转换为 Active.Available 或 Inactive.Unavailable。 |
软件状态迁移更改检测
SR-PCIM 通常需要通过在写入后重新读取 VF 迁移状态来验证状态更改是否生效。
处于 Inactive.Unavailable 状态的 VF 不能被软件以任何方式使用。针对Inactive VF 的请求收到Unsupported Request(UR)。在转换到Inactive或Dormant状态的 100 毫秒内，Device必须确保不会使用指定的 Routing ID发出新的事务。
MR-PCIM 通过使用[MR-IOV]指定的不同数据结构来启动状态转换。此类转换的影响在VF Migration State Array和VF Migration Status位中可见。由 MR-PCI发起的所有状态转换都会导致VF Migration Status位被Set。
每个支持VF Migration的 VF 都存在此迁移状态机。迁移状态机不受Function依赖表的影响。 VF Migration State不影响Function状态。如果作为移出和/或移入操作的一部分需要重置 VF 状态，则 SR-PCIM 必须发出 FLR 来完成此操作。未定义在没有FLR的情况下发生VF迁移时的VF行为。
FLR和VF Migration
VF 从系统 A 到系统 B 的迁移通常涉及在完成 Migrate Out 操作之前系统 A 中的一个 FLR，以及在接受 Migrate In 操作之后但在使用 VF 之前系统 B 中的第二个FLR。系统 A 使用第一个 FLR 来确保其数据不会泄漏。系统 B 使用第二个 FLR 来确保它从一个干净的Function开始。
9.3配置
9.3.1 SR-IOV配置概述
本节提供了 SR-IOV 添加的用于实现 PF 和 VF 的要求。
跟所有Function一样，PF 可以在配置空间中发现。PF 包含第 9.3.3 节中描述的SR-IOV Extended Capability。PF 用于发现、配置和管理与 PF 关联的 VF 以及本规范中描述的其他内容。
9.3.2 配置空间
支持 SR-IOV 的 PF 应实现以下部分中定义的 SR-IOV 能力。VF 应实现以下部分中定义的配置空间字段和功能。
9.3.3 SR-IOV Extended Capability
这里定义的 SR-IOV Extended Capability 是 PCIe 扩展能力，必须在每个支持 SR-IOV 的 PF 中实现。该能力用于描述和控制 PF 的 SR-IOV Capabilities。
对于Multi-Function Devices，每个支持 SR-IOV 的 PF 应提供本节定义的Capability结构。该Capability结构可以出现在任何具有Type 0 Configuration Space Header的Function中。此Capability不得出现在具有Type 1 Configuration Space Header的Functions中。
9.3.3.1 SR-IOV Extended Capability Header (Offset 00h)
表9-3定义了SR-IOV Extended Capability header。表示SR-IOV Extended Capability的Capability ID是0010h。
| Bit | Register | 属性 |
|---|---|---|
| 15:0 | PCI Express Extended Capability ID -SR-IOV Extended Capability的Extended Capability ID是固定值0010h | RO |
| 19:16 | Capability Version- 对PCIe5.0 spec来说是固定值1 | RO |
| 31:20 | Next Capability Offset:该字段包表示下一个 PCI Express Capability 结构的偏移量，如果没有下个capability，则为 000h。 对于在配置空间中实现的扩展功能，此偏移量相对于 PCI 兼容配置空间的开始，因此必须始终为 000h（用于终止功能列表）或大于 0FFh。 | RO |
9.3.3.2 SR-IOV Capabilities (04h)
| Bit | 寄存器 | 属性 |
|---|---|---|
| 0 | VF Migration Capable: 如果设为1，PF 是 Migration Capable 并且在 Migration Capable MR-PCIM 下运行。 | RO |
| 1 | ARI Capable Hierarchy Preserved PCI Express Endpoint ：如果设为1，则 ARI Capable Hierarchy 位在某些功耗状态转换中被保留。建议将此位置 0b。 | RO |
| 2 | VF 10-Bit Tag Requester Supported ：如果设为1，所有VF必须支持 10-Bit Tag Requester功能。如果清为0，则 VF 不支持 10-Bit Tag Requester功能。 如果 PF 的Device Capabilities 2 Register中的 10-Bit Tag Requester Supported 位被清为0，则该位必须为0。 | HwInit |
| 20:3 | Reserved | RsvdP |
| 31:21 | VF Migration Interrupt Message Number：表示用于迁移中断的 MSI/MSI-X 向量。如果 VF Migration Capable 为 Clear，则此字段中的值未定义。 | RO |
9.3.3.2.1 VF Migration Capable
VF Migration Capable 被设置表示PF 支持VF Migration。如果清除，则 PF 不支持 VF Migration。
VF Migration支持是[MR-IOV]可选功能。如果 PF 没有实现 VF Migration的硬件，则该位应实现为 RO，值 0b。如果 PF 为 VF Migration实现了硬件，则该位由[MR-IOV]的机制控制，并表示对 VF Migration的支持。
仅实现 SR-IOV 的设备应将此字段实现为 RO， 值0b。
支持 VF 迁移的 PF 必须实现 MSI 或 MSI-X 中断（或两者）。
9.3.3.2.2 ARI Capable Hierarchy Preserved
ARI Capable Hierarchy Preserved被置起来表示 PF 在某些功耗状态转换期间保留 ARI Capable Hierarchy 位（9.3.3.3.5 节）。组件必须设置该位或设置 No_Soft_Reset 位（参见第 9.6.2 节）。建议组件设置此位，即使它们也设置了 No_Soft_Reset。
ARI Capable Hierarchy Preserved 仅出现在设备编号最低的 PF（例如 PF0）中。ARI Capable Hierarchy Preserved 在设备的其他 PF 中RO，值为零。
ARI Capable Hierarchy Preserved 不适用于 RCiEP，其值未定义（9.3.3.3 节）。
9.3.3.2.3 VF 10-Bit Tag Requester Supported
如果 PF 支持 10-Bit Tag Requester 能力，则其关联的 VF 也被允许支持 10-Bit Tag Requester 能力，但这可选。特别是对于大量流量同时分布在多个 VF 的使用模型，单个 VF 可能没有必要使用 10-bit Tag，以便每个 VF 可以支持超过 256 个未完成的Non-Posted Requests。
对于给定的 PF，要求其关联的 VF 全部或都不 支持 10-Bit Tag Requester能力。这避免了不必要的实施和管理复杂性。见第 10.3.5.9 节。
支持 10-Bit Tag Requester功能的 VF 具有超出其他Function类型的额外要求，以简化错误处理并降低 10-Bit Tag相关错误的可能性导致其中一个 VF 影响其他流量。
如果 SR-IOV Control register中的 VF 10-Bit Tag Requester Enable位被设置，则每个 VF θ必须对它生成的所有Non-Posted Requests使用 10-Bit Tags。
对于每个未完成的10-Bit Tag Request，如果 VF 接收到未完成请求相匹配的Completions，而Tag[9:8]不是 00b，则 VF 必须防止该请求（最终）生成Completion Timeout错误，取而代之的是通过避免数据损坏的特定设备的机制处理错误。
强烈建议软件不要将Unexpected Completion错误配置为Uncorrectable Errors。这可避免它们触发系统错误或硬件错误控制机制，如Downstream Port Containment (DPC)。
VF没有10-Bit Tag Completer Supported位
没有VF 10-Bit Tag Completer Supported位。如果 PF 支持 10-Bit Tag Completer 功能，则其所有关联的 VF 都需要支持 10-Bit Tag Completer 功能，如第 10.3.5.9 节所述。这有助于避免 PCIe 层次结构的复杂性，其中一些 Completers 支持 10-Bit Tag功能，而另一些则不支持。简单来说，VF 值必须与 PF 值相同。
9.3.3.2.4 VF Migration Interrupt Message Number
VF Migration Interrupt Message Number必须包含用于与某些VF迁移事件相关联的中断消息的MSI或MSI-X向量编号。对于MSI，VF Migration Interrupt Message Number必须指出用于本节描述的某些SR事件的MSI消息编号[0 … 31]。Function需要更新此字段，以便在软件写入Message Control Register for MSI中的Multiple Message Enable字段时，如果分配给该Function的MSI Messages数量发生变化，该字段是正确的。
对于 MSI-X，VF Migration Interrupt Message Number表示用于生成中断消息的MSI-X Table条目15[0 … 2047]。
如果同时实现了MSI和MSI-X，则允许它们使用不同的向量，但软件一次只能启用一种机制。如果MSI和 MSI-X中断都被enable，则该字段未定义。
如果VF Migration Capable为0，则该字段未定义。
如果PF实现了MSI 并且软件将Multiple Message Enable 设置为小于Multiple Message Capable 的值，则可能会共享某些MSI 向量。这会创建复杂的软件结构，因为可能需要将单个向量同时指向 SR-PCIM 和 PF Device Driver。
9.3.3.3 SR-IOV Control Register (Offset 08h)
表 9-5 定义了 SR-IOV Control字段的布局。
| Bit | 寄存器 | 属性 |
|---|---|---|
| 0 | **VF Enable | RW** |
| 1 | VF Migration Enable：Enables/Disables VFs， 默认值为0 | RW or RO |
| 2 | VF Migration Interrupt Enable：Enables/Disables VF Migration Support，默认值为0 | RW |
| 3 | VF MSE：VF Memory Space Enable，默认值为0 | RW |
| 4 | ARI Capable Hierarchy ：PCI Express Endpoint：该bit在在Device最低编号的PF一定是RW，并且在所有其他 PF 中硬连线为 0b。如果该位的值为 1b，则允许设备在捕获的总线编号的Function Numbers 8 至 255 中定位 VF。否则，设备必须像非 ARI 设备一样定位 VF。该位不受任何 PF 或 VF 的 FLR 影响。默认值为 0b。RCiEP：不适用——该位必须硬连线到 0b。在RC中，始终允许将 VF 分配给First VF Offset和VF Stride规则允许的任何Function Number（第 9.3.3.8 和 9.3.3.9 节）。 | RW or RO |
| 5 | VF 10-Bit Tag Requester Enable：如果为1，所有VF必须对它们生成的所有非发布请求使用 10-Bit Tags。如果为0，则 VF 不得为它们生成的Non-Posted Requests使用 10-Bit Tags。见第 10.3.3.2.3 节。如果在任何 VF 具有未完成的非发布请求时软件更改了该位的值，则结果是不确定的。如果 SR-IOV 功能寄存器中的 VF 10-Bit Tag Requester Supported 位为 Clear，则允许将该位硬连线为0b。默认值为 0b。 | RW or RO |
9.3.3.3.1 VF Enable
VF Enable管理VF到关联 PF 的分配。如果设置了VF Enable，则可以在 PCIe结构中访问与PF关联的VF。设置后，VF 会根据 PCIe Endpoint Functions的规则响应并发出 PCIe 事务。
如果 VF Enable 为 Clear，则 VF 被禁用且在 PCIe结构中不可见；对这些 VF 的请求应接收 UR，并且这些VF不应发出PCIe事务。
为了允许组件执行内部初始化，在将 VF Enable位从0更改为1后，系统不许向由该 VF Enable位启用的 VF 发出请求，直到以下任一情况为真：
- 至少 100 ms过去了
- 已从 PF 收到一条 FRS Message，Reason Code为VF Enabled
- 至少VF Enable时间已过。VF Enable时间是
- 与 VF 相关的准备时间报告功能中的重置时间值，或
- 由系统软件/固件确定的值。
RC和/或系统软件必须允许在设置 VF Enable位后至少 1.0 秒，然后才能确定VF未能返回Successful Completion Status，因为有效Configuration Request已损坏。设置VF Enable位后，如果VF Enable位启用的 VF 尚未准备好为有效的Configuration Request提供Successful Completion Status，则允许由该 VF Enable位启用的 VF 将 CRS 状态最多 1.0 秒返回到配置请求。在 PF 发送Reason Code为 VF Enabled的FRS Message后，与该PF关联的任何VF都不允许返回没有介于VF 禁用或其他有效的重置条件的CRS，在向任何请求返回Successful Completion后，任何 VF 都不得返回没有介于VF 禁用或其他有效重置条件的 CRS。
由于VF没有 MSE 位（VF中的 MSE由PF中SR-IOV Extended Capability中的 VF MSE 位控制），因此软件有可能在 VF 准备好处理它之前发出Memory Request。因此，在至少满足以下条件之一之前，不得向 VF 发出Memory Request：
- VF 已成功响应（不返回 CRS）Configuration Request。
- 在向 VF 发出 FLR 后，至少满足以下一项：
- 自发出 FLR 以来至少已过去 1.0 秒。
- VF 支持 FRS，并且在发出 FLR 后，已从 VF 收到一条 FRS 消息，Reason Code为 FLR Completed。
- 自 发出FLR以来，至少已经过了 FLR 时间。FLR 时间是
- 与 VF 相关联的Readiness Time Reporting功能中的 FLR 时间或
- 由系统软件/固件确定的值
- 在 PF 中设置VF Enable后，以下至少一项为真：
- 自设置VF Enable以来至少已过去 1.0 秒。
- PF 支持 FRS，并且在设置了 VF Enable 之后，已经从 PF 接收到一个FRS Message，Reason Code为 VF Enabled。
- 自设置VF Enable以来，至少已经过去了VF Enable Time。VF Enable Time是
- 与 VF 相关联的Readiness Time Reporting功能中的Reset Time值或
- 由系统软件/固件确定的值。
在向 VF 发出 FLR 或在相关联的 PF 的 SR-IOV 功能中设置了VF Enable后，VF 被允许静默丢弃Memory Requests，直到 VF 成功响应（不返回 CRS）任何请求。
Clear VF Enable 可有效破坏 VF。Set VF Enable 可有效创建 VF。在先前被清除过后设置 VF Enable 将产生一组新的 VF。如果 PF 处于 D0 power state，则新的 VF 处于D0uninitialized。如果 PF 处于lower power state，则行为未定义（参见第 9.6.1 和 9.6.2 节）。
当清除 VF Enable 时，支持 FRS 的 PF 应发送带有 FRS Reason VF Disabled 的 FRS Message以指示此操作何时完成。如果存在由 PF 或与 PF 关联的任何 VF 发出的未完成的Non-Posted Requests，则不允许 PF 发送此Message。FRS Message只能在这些Requests完成（或超时）后发送。
在 VF Enable被清除后，SR-IOV Extended Capability或VF Migration State Array（ 9.3.3.15.1 节）中的任何字段都不能被访问，直到：
- 在VF Enable被清除后至少过去了 1.0 秒。
- PF 支持FRS，并且在VF Enable 被清除后，收到来自PF 的FRS Message，Reason Code为VF Disabled。
9.3.3.3.2 VF Migration Enable
必须设置 VF Migration Enable 以允许此 PF 上的 VF 迁移。有关详细信息，请参阅[MR-IOV]。
如果设置了 VF Migration Capable，则该位为 RW，默认值为 0b。否则，该位为 RO 0。
当 VF Enable 被设置时，这个字段是 RO。
9.3.3.3.3 VF Migration Interrupt Enable
每当以下条件的逻辑与从 FALSE 转换为 TRUE 时，必须发送 MSI 或 MSI-X 中断消息：
- VF 的Bus Master Enable位被设置。
- 关联的向量未屏蔽。
- VF Migration Interrupt Enable位被设置。
- VF Migration Status位被设置。
使用的 MSI 或 MSI-X 向量由VF Migration Interrupt Message Number字段指示。
如果 VF Migration Capable 为 Clear，则该字段未定义。
注意：9.2.4 节描述了 VF Migration事件。
9.3.3.3.4 VF MSE (Memory Space Enable)
VF MSE控制与此PF关联的所有active VF的内存空间启用，就像Function的PCI Command寄存器中的Memory Space Enable位一样。 该位的默认值为 0b。
当VF Enable为 Set 时，VF存储空间只有在VF MSE为Set时才会响应。 如果在设置VF Enable且清除 VF MSE 时尝试访问VF的内存空间，则 VF 应遵循与 PCIe基本规范中定义的相同的错误报告规则。
当 VF Enable 为 Clear 时，VF 内存空间将响应 Unsupported Request。 因此，当 VF Enable 为 Clear 时，VF MSE 是“无关紧要的”； 但是，在设置VF Enable之前，软件可以选择在对VF BARn 寄存器进行编程之后设置VF MSE。
9.3.3.3.5 ARI Capable Hierarchy
对于与Upstream Port关联的设备，ARI Capable Hierarchy是对设备的提示，即 ARI 已在设备正上方的Root Port或Switch Downstream Port中启用。 软件应设置此位以匹配设备正上方的Root Port或Switch Downstream Port中的 ARI Forwarding Enable位。
ARI Capable Hierarchy 仅出现在设备的最低编号 PF 中（例如 PF0），并影响设备的所有 PF。 ARI Capable Hierarchy在设备的其他 PF 中只读为零。
设备可以设置ARI Capable Hierarchy 来确定First VF Offset（第 9.3.3.9 节）和VF Stride （第 9.3.3.10 节）的值。 如果在任何 PF 中设置了VF Enable，则更改ARI Capable Hierarchy的效果是不确定的。 该位必须在Conventional Reset时设置为其默认值。 该位不受任何 PF 或VF的 FLR影响。 如果ARI Capable Hierarchy Preserved被设置（见第 9.3.3.2.2 节）或No_Soft_Reset 被设置（见第 9.6.2 节），则该 PF从D3Hot到D0的功耗状态转换不会影响该位的值（第 9.6.2 节）。
ARI Capable Hierarchy不适用于RCiEPs.
ARI Capable Hierarchy
对于与Upstream Port关联的设备，该设备无法知道ARI是否已启用。 如果启用了ARI，设备可以通过将VF分配给捕获的Bus Number上大于 7 的Function Numbers来保存Bus
Number。 ARI 在第 6.13 节中定义。 由于RCiEP不与Upstream Port相关联，因此 ARI 不适用，并且 VF
可以分配给 First VF Offset 和 VF Stride 允许的 Root Complex 内的任何Function
Number（参见第 9.3.3.8 节和第 9.3.3.9 节）。
9.3.3.4 SR-IOV Status Register (Offset 0Ah)
表 9-6：定义了 SR-IOV Status字段布局。
| Bit | 寄存器 | 属性 |
|---|---|---|
| 0 | VF Migration Status - 表示 MR-PCIM 已发出 VF Migration或Migration Out Request。为了确定事件的原因，软件可以扫描VF State Array。 默认值为 0b。 | RW1C |
9.3.3.4.1 VF Migration Status
当VF Enable、VF Migration Capable和VF Migration Enable为Set且VF Migration State Array条目中发生某些状态更改时，VF Migration Status为Set（详见第 9.2.4 节和第 9.3.3.15.1 节）。
VF Migration Status的设置不受VF Migration Interrupt Enable的值或MSI或MSI-X的任何控件的影响。
9.3.3.5 InitialVFs (Offset 0Ch)
InitialVFs 向 SR-PCIM 指示最初与 PF 相关联的 VF 的数量。
InitialVFs 的最小值为 0。
对于在Single-Root模式下运行的设备，该字段是 HwInit 并且必须包含与 TotalVFs 相同的值。
对于在Multi-Root模式下运行的设备，当 VF Enable 为 Clear 时，MR-PCIM 可能会更改该字段的值。
注：MR-PCIM影响该字段的机制在[MR-IOV] 中描述。
如果 VF Migration Enable 被设置，VF Enable 被清除然后设置，InitialVFs 的值可能会改变。 这是必要的，因为某些 VF 可能已迁移到其他 PF，并且可能不再可供该 PF 使用。
9.3.3.6 TotalVFs (Offset 0Eh)
TotalVFs 表示可以与 PF 关联的最大 VF 数。
TotalVFs 的最小值为 0。
对于在Single-Root模式下运行的设备，该字段是 HwInit 并且必须包含与 InitialVFs 相同的值。
对于在Multi-Root模式下运行的设备，该字段的值可能会被 MR-PCIM 更改。
注：MR-PCIM影响该字段的机制在[MR-IOV] 中描述。
9.3.3.7 NumVFs (Offset 10h)
NumVFs 控制可见 VF 的数量。 SR-PCIM 将 NumVFs 设置为创建 VFs 过程的一部分。 在将两个 NumVFs 设置为有效值并且设置 VF Enable 后，此 VFs 数量应在 PCIe结构中可见。 可见的 VF 为其保留了一个Function编号，但可能不存在。 如果 VF 存在，它应响应针对它们的 PCIe事务，并应遵循本规范定义的所有规则。 如果满足以下任一条件，则存在 VF：
- VF Migration Capable 为 Clear 且 VF 数小于或等于 TotalVFs。
- VF Migration Capable 已设置且关联的 VF 处于 Active.Available 或 Dormant.MigrateIn 状态（请参阅第 9.2.4 节）
如果 NumVFs 设置为大于 TotalVFs 的值，则结果未定义。
NumVFs 只能在 VF Enable 为 Clear 时写入。 如果在设置VF Enable时写入 NumVFs，则结果未定义。
NumVFs 的初始值未定义。
9.3.3.8 Function Dependency Link (Offset 12h)
设备的编程模型可能在Functions集之间具有特定依赖关系。 Function Dependency Link字段用于描述这些依赖项。
该字段描述了 PF 之间的依赖关系。 VF 依赖项与其关联 PF 的依赖项相同。
如果 PF 独立于设备的其他 PF，则该字段应包含其自己的Function Number。
如果 PF 依赖于设备的其他 PF，则该字段应包含同一功能依赖列表中下一个 PF 的Function Number。 Function Dependency List中的最后一个 PF 应包含Function Dependency List中第一个 PF 的Function Number。
如果 PFp 和 PFq 在同一个Function Dependency List中，那么任何分配给 VFp,n 的 SI 也应该分配给 VFq,n。
Function Dependency Link范例
考虑以下场景：
| SR-IOV字段 | PF0 | PF1 | PF2 |
|---|---|---|---|
| Function Dependency Link | 1 | 0 | 2 |
| NumVFs | 4 | 4 | 6 |
| First VF Offset | 4 | 4 | 4 |
| VF Stride | 3 | 3 | 3 |
| Function Number | Description | Independent |
|---|---|---|
| 0 | PF 0 | No |
| 1 | PF 1 | No |
| 2 | PF2 | Yes |
| 3 | Function不存在 | |
| 4 | VF 0,1 | No |
| 5 | VF 1,1 | No |
| 6 | VF 2,1 | Yes |
| 7 | VF 2,2 | No |
| 8 | VF 1,2 | No |
| 9 | VF 2,2 | Yes |
| 10 | VF 0,3 | No |
| 11 | VF 1,3 | No |
| 12 | VF 2,3 | Yes |
| 13 | VF 0,4 | No |
| 14 | VF 1,4 | No |
| 15 | VF 2,4 | Yes |
| 16 to 17 | Function不存在 | |
| 18 | VF 2,5 | Yes |
| 19 to 20 | Function不存在 | |
| 21 | VF 2,6 | Yes |
| 22 to 255 | Function不存在 |
在此示例中，Functions 4 和 5 必须分配给相同的 SI。 同样，Functions 7 和 8、10 和 11 以及 13 和 14 必须一起分配。 如果 PF 分配给 SI，则Functions 0 和 1 也必须一起分配。 Functions 2、6、9、12、15、18 和 21 是独立的，可以以任何方式分配给 SI。
Function Dependency List的所有 PF 的 InitialVFs、TotalVFs 和 VF Migration Capable 字段应具有相同的值。
SR-PCIM 应确保在 Function Dependency List中的任何 VF 分配给 SI 之前， Function Dependency List中的所有 PF 的 NumVFs、VF Enable和VF Migration Enable字段具有相同的值。
VF Migration和VF Mapping操作对每个 VF 独立进行。 SR-PCIM 不应该将 VF 分配给 SI，直到它可以分配所有相关的 VF。 例如，使用上述场景，如果 VF 0,2（功能 7）和 VF 1,2（功能 8）都处于 Inactive.Unavailable 或 Dormant.MigrateIn 状态，则 SR-PCIM 不应将任一 VF 分配给 SI 直到两个 VF 都达到 Active.Available 状态。
类似地，SR-PCIM 不应从 SI 中删除 VF，直到它可以删除所有相关的 VF。 例如，使用上述场景，只有当 VF 0,2 和 VF 1,2 都达到 Active.MigrateOut 状态时，才应从 SI 中删除它们。 在 SI 停止使用所有相关Functions之前，SR-PCIM 不应将功能转换为 Inactive.Unavailable。
9.3.3.9 First VF Offset (Offset 14h)
First VF Offset 是一个常量，它定义了与包含此 Capability 结构的 PF 相关联的第一个 VF 的Routing ID 偏移量。 第一个 VF 的 16 位Routing ID 是通过将此字段的内容添加到包含此字段的 PF 的Routing ID 来计算的，忽略任何进位，使用无符号16 位算法。
VF 不应位于数字小于其关联 PF 的Bus Number上。
当编号最低的 PF 的 ARI Capable Hierarchy 值更改或此 PF 的 NumVFs 值更改时，此字段可能会更改值。
注意：如果 NumVFs 为 0，则不使用 First VF Offset。如果 NumVFs 大于 0，则 First VF Offset 不得为零。
9.3.3.10 VF Stride (Offset 16h)
VF Stride 定义了与包含此 Capability 结构的 PF 相关联的所有 VF 从一个 VF 到下一个 VF 的Routing ID 偏移。 下一个 VF 的 16 位Routing ID 是通过将此字段的内容添加到当前 VF 的Routing ID 来计算的，忽略任何进位，使用无符号16 位算法。
当编号最低的 PF 的 ARI Capable Hierarchy 值更改或此 PF 的 NumVFs 值更改时，此字段可能会更改值。
注意：如果 NumVFs 为 0 或 1，则不使用VF Stride。如果 NumVFs 大于 1，则VF Stride不得为零。
9.3.3.11 VF Device ID (Offset 1Ah)
该字段包含应该为每个 VF 呈现给 SI 的Device ID。
VF Device ID 可能与 PF Device ID 不同。 VF Device ID 必须由供应商管理。 供应商必须确保所选的 VF Device ID 不会导致使用不兼容的设备驱动程序。
9.3.3.12 Supported Page Sizes (Offset 1Ch)
该字段指示 PF 支持的page大小。 如果位 n 被设置，则该 PF 支持 2n+12 的page大小。 例如，如果位 0 被设置，PF 支持 4 KB page大小。 PF 需要支持 4-KB、8-KB、64-KB、256-KB、1-MB 和 4-MB 的page大小。 所有其他页面大小都是可选的。
page大小描述了 VF BAR 资源的最低align要求，如第 9.3.3.13 节所述。
Non-pre-fetch Address Space
非预取地址空间仅限于 4 GB 以下的地址。 32 位系统中的预取地址空间也是有限的。 强烈鼓励供应商利用System Page Size功能来节省地址空间，同时支持具有更大page size的系统。
9.3.3.13 System Page Size (Offset 20h)
该字段定义了系统将用于映射 VF 内存地址的page大小。 软件必须将 System Page Size 的值设置为 Supported Page Sizes 字段中设置的page大小之一（请参阅第 9.3.3.12 节）。 与支持的page大小一样，如果在系统page大小中设置了位 n，则与此 PF 关联的 VF 需要支持 2n+12 的page大小。 例如，如果位 1 被设置，则系统使用 8 KB 的page大小。 如果System Page Size为零，则结果未定义。 如果在 System Page Size 中设置了一位以上，则结果是不确定的。 如果在Supported Page Sizes中未设置,而在System Page Size中设置了该bit，则结果未定义。
设置System Page Size时，此 PF 关联的 VF需要与System Page Size边界上的所有 BAR 资源对齐。 每个 VF BARn 或 VF BARn 对（参见第 9.3.3.14 节）应在System Page Size边界上对齐。 定义非零地址空间的每个 VF BARn 或 VF BARn 对的大小应被调整为消耗System Page Size字节的整数倍。 在 VF 中需要page大小对齐的所有数据结构都应在System Page Size边界上对齐。
写入 System Page Size 时，VF Enable 必须为零。 如果在设置VF Enable时写入System Page Size，则结果未定义。
默认值为 0000 0001h（即 4 KB）。
9.3.3.14 VF BAR0 (Offset 24h), VF BAR1 (Offset 28h), VF BAR2 (Offset 2Ch), VF BAR3 (Offset 30h), VF BAR4 (Offset 34h), VF BAR5 (Offset 38h)
这些字段必须定义 VF 的Base Address Registers(BAR)。 这些字段的行为与正常的 PCI BAR 相同，如第 7.5.1 节所述。 它们可以通过写全 1 并读回 BAR 的内容来调整大小，如第 7.5.1.2.1 节所述，符合定义 BAR 类型字段的低位。
这些字段的属性可能会受到 VF Resizable BAR Extended Capability（见第 9.3.7.5 节）的影响。
每个 BAR 解码的地址空间量应为 System Page Size 的整数倍。
每个 VF BARn，当通过写 1 和读回内容来“调整大小”时，描述了每个 BAR 消耗的地址空间量和单个VF所需的对齐方式。 当使用实际地址值写入并且 VF Enable 和 VF MSE 被设置时，BAR 映射 NumVFs BAR。 换言之，base address是与该 PF 相关联的第一个 VF BARn 的地址，所有后续 VF BARn 地址范围如下所述。
VF BAR 应仅支持 32 位和 64 位内存空间。 VF 不支持 PCI I/O Space。 除了用于映射 64 位内存 VF BAR 对的高 32 位的 VF BARx 外，任何已实现的 VF BARx 的位 0 必须是 RO 0b。
对齐要求和读取大小是针对单个 VF，但是当 VF Enable 为 Set 且 VF MSE 为 Set 时，BAR 包含所有 (NumVFs) VF BARn 的base address。
确定 VF BARn 映射的地址空间量的算法与标准 BAR 算法的不同之处如下：
- 如果实现了该BAR,可以通过VF Resizable BAR Extended Capability来调整BAR的大小
- 在读取低位以确定 BAR 是 32 位 BAR 还是 64 位 BAR 对后，通过将全 1 写入 VF BARn （或 VF BARn 和 VF BARn+1 用于 64 位 BAR 对）并读回 BAR 或 BAR 对的内容来确定大小和对齐要求。 将读取返回的位掩码转换为大小和对齐值，如第 7.5.1.2.1 节所述。 该值是单个 VF 的大小和对齐方式。
- 将步骤 2 中的值乘以在 NumVFs 中设置的值，以确定在设置 VF Enable和 VF MSE 后 BAR 或 BAR 对将映射的总空间。
对于每个 VF BARn 字段，n 对应于 VFs BAR 空间之一。 表 9-7 显示了 n 和Function的 BAR 之间的关系。
| n | Type 0 Header的BAR Offset |
|---|---|
| 0 | 10h |
| 1 | 14h |
| 2 | 18h |
| 3 | 1Ch |
| 4 | 20h |
| 5 | 24h |
更改System Page Size后，所有 VF BARn 寄存器的内容都不确定。
9.3.3.15 VF Migration State Array Offset (Offset 3Ch)
如果 VF Migration Capable（第 9.3.3.2.1 节）设置并且 TotalVFs（第 9.3.3.6 节）不为零，则该寄存器应包含一个指向VF Migration State Array的 PF BAR 相关指针。 如果VF Migration Capable清除，则该寄存器为 RO 0。 VF Migration State Array在第 9.3.3.15.1 节中定义。 VF Migration State Array的布局在表 9-8 中定义。
| Bit | Register | 属性 |
|---|---|---|
| 2:0 | VF Migration State BIR - 指示Function的哪个Base Address寄存器（位置从Configuration Space中的 10h 开始）用于将Function的VF Migration State Array映射到Memory Space。 | RO |
| 31:3 | VF Migration State Offset- 一个Function的Base Address包含的地址的偏移量，以指向 VF Migration State Array的基址。 低三位 VF Migration State BIR被软件屏蔽（设置为零）以形成 32 位 QW 对齐偏移。 如果 TotalVFs 为 0，则此字段未定义。 | RO |
如果为VF Migration State Array映射地址空间的BAR还映射了与VF Migration无关的其他可用地址空间，则其他地址空间中使用的位置不得与VF Migration State Array驻留的位置共享任何自然对齐的8KB地址范围。
9.3.3.15.1 VF Migration State Array
VF Migration State Array使用SR-IOV Extended Capability块的VF Migration State Array Offset寄存器定位。
VF Migration State Array对于每个VF 都有一个VF Migration State Entry。 VF Migration State数组的总大小为NumVFs字节。 如果TotalVFs为0，则 VF Migration State Array不应存在。表9-9定义了VF Migration State Array的布局。
| Bit | 寄存器 | 属性 |
|---|---|---|
| 1:0 | VF Migration State - 相关 VF 的状态。 当VF Enable为Clear时，该字段未定义。 VF Migration State Array的初始值在9.2.4.1节中描述。 | RO |
表9-10列出了VF Migration State各种值的含义。
| VF State | VF Exists | Description |
|---|---|---|
| 00b | No | Inactive.Unavailable -VF 不存在于 SR 中，也不会移入或移出。 |
| 01b | No | Dormant.MigrateIn -VF 可供 SR 使用。 VF 存在但无法发起事务。 |
| 10b | Yes | Active.MigrateOut - 已要求 SR 放弃使用 VF。 |
| 11b | Yes | Active.Available - 功能齐全。 可以分配给 SI。 |
VF Migration State Array的初始值在9.2.4.1 节中描述。VF Migration State Array在VF Enable用被清除后的 1.0 秒内返回到 9.2.4.1节中描述的配置。
软件通过向entry写入新的状态值来启动状态转换。
有效的状态转换在表9-11和表9-12中列出，并在图9-12中显示。SR只能请求表9-11中的更改。表9-12中的更改由MR-PCIM使用[MR-IOV]机制发起，并具有此处描述的SR可见效果。任何由SR-PCIM发出且未在表9-11中列出的转换都将被忽略并且不会更改VF状态。
| Current State | New State | Change Initiated By | SR Visible Effects of Change |
|---|---|---|---|
| Dormant.MigrateIn | Active.Available | SR-PCIM | VF Activate VF now exists |
| Active.Available | Dormant.MigrateIn | SR-PCIM | VF Deactivate VF no longer exists |
| Active.MigrateOut | Inactive.Unavailable | SR-PCIM | VF Migrate Out Complete VF no longer exists |
| Current State | New State | Change Initiated By | SR Visible Effects of Change |
|---|---|---|---|
| Active.Available | Active.MigrateOut | MR-PCIM | VF Migrate Out Request VF continues to exist. Sets VF Migration Status |
| Inactive.Unavailable | Dormant.MigrateIn | MR-PCIM | VF Migrate In Request VF remains non-existent. Sets VF Migration Status |
| Dormant.MigrateIn | Inactive.Unavailable | MR-PCIM | VF Migrate In Retract VF remains non-existent. Sets VF Migration Status |
| Active.MigrateOut | Active.Available | MR-PCIM | VF Migrate Out Retract VF continues to exist. Sets VF Migration Status |
2040
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
