启用具有内核变体驱动程序的 VFIO 设备¶
https://blueprints.launchpad.net/nova/+spec/enable-vfio-devices-with-kernel-variant-drivers
本文档概述了使用新的内核 VFIO SR-IOV 变体驱动程序接口启用对 SR-IOV 设备的支持所需的步骤。
问题描述¶
从内核 5.16 开始，并在后续内核中（包括 Ubuntu 24.04 (Noble Numbat) 和未来的 RHEL 10 版本中），共享虚拟功能 (VFs) 的 SR-IOV 机制已经发展。
虽然仍然支持旧接口，但已经引入了一个使用 变体驱动程序 的新接口。 几个设备已经利用了这种更新的变体驱动程序接口。
因此，Nova 应该更新其 VFIO 设备支持，以适应这一进步。
用例¶
作为操作员，我希望能够在需要变体驱动程序的 Linux 发行版上使用 SR-IOV 设备。
作为操作员，我希望“遗留”SR-IOV 设备支持保持兼容。
提议的变更¶
描述:¶
使用变体驱动程序接口的 SR-IOV 设备可以通过构建现有的 PCI 直通和 SR-IOV 支持，结合本文档中提出的几项修改，与 Nova 集成。
根据设备文档，用户应将设备配置为可通过其 PCI 地址识别的 PCI 虚拟功能 (VFs) 访问。
随后，通过遵循 Nova 关于将物理 PCI 设备附加到客户机的文档，用户应该到达一个指定设备属性和别名的主要配置 PCI 部分。
配置托管模式:¶
用户必须指定 PCI 设备是否由 libvirt 管理，以允许从主机分离并分配给客户机，反之亦然。 设备的托管模式取决于特定设备及其驱动程序提供的支持。
建议的解决方案是在设备规范中添加一个 managed 标签。
managed='yes'表示 nova 将让 libvirt 在将其附加到客户机之前从主机分离设备，并在删除客户机后将其重新附加到主机。managed='no'表示 nova 不会请求 libvirt 从主机分离/附加设备。 在这种情况下，nova 假设操作员以这样一种方式配置了主机，即这些 VFs 未附加到主机。
注意
如果未设置，默认值为 managed='yes'，以保留现有行为，主要用于升级目的。
行为，特别是对于 Nova，假设设备已经绑定到 vfio-pci 或相关的变体驱动程序，并且可以直接使用，无需任何额外的操作即可将其直通到 QEMU。
警告
错误配置此参数可能会导致主机操作系统崩溃。
当 PCI 资源跟踪器 遇到此标签时，相应的信息将存储在相应的 PciDevice 对象中的 extra_info 字段下。 这允许负责生成 XML 定义的代码使用适当的值配置 libvirt 托管模式。
注意
PciDevice 对象版本保持不变。
清理设备规范:¶
作为初始化过程的一部分，会执行检查以验证设备规范的正确性。 当前，如果规范中存在重复项，则仅保留第一个条目。 虽然这种行为是可以接受的，但我们可能会考虑扩展它以记录警告并通知用户。
显示管理:¶
来自 libvirt 文档
可以使用可选的 display 属性来启用将 vgpu 设备用作客户机的显示设备。 支持的值可以是 on 或 off（默认值）。 还有一个可选的 ramfb 属性，其值为 on 或 off（默认值）。 启用后，ramfb 属性为客户机提供内存帧缓冲区设备。 此帧缓冲区允许在客户机中加载 GPU 驱动程序之前将 vgpu 用作启动显示器。
即使将多个 VGU 附加到 VM，也存在仅激活这些设置的单个 VGPU 的限制。
注意
在本初始实现中，显示管理超出范围，与现有的 mdev 实现一致。
示例
注意
以下示例演示了设备规范和别名配置。
[pci]
device_spec = { "vendor_id": "10de", "product_id": "25b6", "address": "0000:25:00.4", managed: "no" }
alias = { "vendor_id": "10de", "product_id": "25b6", "device_type": "type-VF", "name": "MYVF" }
基于上述配置创建 VM 将在 XML 定义中包含以下片段
<hostdev mode='subsystem' type='pci' managed='no'>
<driver name='vfio'/>
<source>
<address domain='0x0000' bus='0x25' slot='0x00' function='0x4'/>
</source>
<alias name='hostdev0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</hostdev>
如果用户需要支持多种类型的 VFs，则上述示例不适用。
支持多种类型的 VFs:¶
SR-IOV 设备，例如 GPU，可以配置为在相同的供应商 ID 和产品 ID 下提供具有各种特征的 VFs。
为了使 Nova 能够模拟这一点，如果您使用不同的资源分配配置 VFs，则需要为每个 VFs 使用单独的 resource_classes。
可以通过执行以下步骤来实现
启用 Placement 中的 PCI：这对于跟踪 Placement 服务中的具有自定义资源类的 PCI 设备是必要的。
定义设备规范：使用自定义资源类来表示特定的 VF 类型，并确保超visor 上的 VFs 通过其 PCI 地址进行匹配。
指定特定类型的风味：定义具有与供应商、产品和资源类匹配的别名的风味，以确保适当的分配。
设备规范资源类:¶
这对于希望支持多种类型的 VFs 的用户是必要的，需要启用“Placement 中的 PCI”功能。
资源类可以是用户定义的，只要它符合 Placement 的验证要求即可。 虽然 nova 会将资源类字符串规范化以生成有效的资源类，但依赖于此被认为是不良做法。
规范化是通过将字符串转换为大写、将任何连续的非 [A-Z0-9_] 字符替换为单个“_”，以及如果尚未添加前缀，则在名称前添加 CUSTOM_ 来完成的。
例如，CUSTOM_<TYPE_OF_VF> 即 CUSTOM_GOLD_GPU 将是一个有效的资源类。
示例
注意
以下示例演示了设备规范和别名配置，利用“Placement 中的 PCI”功能中的资源类。
[pci]
device_spec = { "vendor_id": "10de", "product_id": "25b6", "address": "0000:25:00.4", "resource_class": "CUSTOM_A16_16A", "managed": "no" }
alias = { "device_type": "type-VF", resource_class: "CUSTOM_A16_16A", "name": "A16_16A" }
备选方案¶
不适用
REST API 影响¶
不适用
数据模型影响¶
仅现有的 extra_info 自由字典将被扩展。
安全影响¶
不适用
通知影响¶
不适用
其他最终用户影响¶
不适用
性能影响¶
如果启用了 Placement 中的 PCI，则应考虑此 错误，因为它可能会影响性能。
目前正在开发 缓解措施 以尽量减少这种影响。
其他部署者影响¶
用户对配置以下内容负全部责任
主机设备：定义所需的虚拟 VFs 类型。
计算节点：配置设备规范，包括设备/驱动程序是否支持 managed=true，以及必要的别名。
风味：如果需要多种类型的 VFs，用户必须为每种 VF 类型创建和使用不同的风味。
开发人员影响¶
无
升级影响¶
具有 Nvidia 虚拟 GPU 的用户必须查看其配置。
实现¶
负责人¶
- 主要负责人
Uggla (René Ribaud)
- 主要贡献者
Bauzas (Sylvain Bauza)
功能联络人¶
- 功能联络人
N/A
工作项¶
解析 PCI 设备规范中的 managed 参数。
清理设备规范。
更改 XML 生成以处理 managed 参数。
文档更新。
单元测试 + 功能测试。
依赖项¶
性能影响错误。
Placement 中的 PCI 功能，用于多种类型的 VFs。
测试¶
单元测试和功能测试。
由于硬件限制，无法在 CI 中执行 Tempest 和/或白盒测试。 但是，可以并行进行此实现，并将它们推迟到以后包含在 CI 中。
文档影响¶
将提供详细的管理员和用户文档。
参考资料¶
历史¶
发布名称 |
描述 |
|---|---|
Epoxy |
引入 |
