4. 第4章
04 BIOS与固件配置：开启SR-IOV与IOMMU
掌握固件配置在BIOS与固件配置中的定位、故障信号与验证顺序。
BIOS 固件配置：开启 SR-IOV 与 IOMMU 的工程路径
现场定位记录
- 对象/模块：典型技术应用现场里的固件配置
- 问题现象：典型技术应用现场里固件配置一开始改动很快，输入需求增加后日志记录显示状态外泄、循环依赖和接口膨胀。
- 验证动作：先把职责边界、私有状态、依赖方向、阈值标准和验证入口画清，再执行拆分动作。
- 工程判断：前后变化点能被隔离、被验证、被替换，才说明架构重构达到标准。
BIOS与固件配置落地前要同时核对固件配置的开启SR-IOV、失败路径和在服务器BIOS中启用SR-IOV。
概念块：BIOS与固件配置
BIOS与固件配置用固件配置、开启SR-IOV、在服务器BIOS中启用SR-IOV连接到固件配置的调试、验证和交付动作。
- 固件配置
- 开启SR-IOV
- 在服务器BIOS中启用SR-IOV
- 模块
在 Kubernetes（K8s）集群中使用 SR-IOV 高速网卡，其底层依赖服务器固件（BIOS/UEFI）对硬件虚拟化特性的正确暴露。如果 BIOS 层未开启 SR-IOV（Single Root I/O Virtualization）和 IOMMU（Input-Output Memory Management Unit），上层操作系统和容器编排平台将无法感知到虚拟功能（VF），导致 SR-IOV Device Plugin 无法分配网卡资源。本节的核心意图是提供一套可复现的固件配置流程，重点解决“BIOS 选项名称不统一”和“VT-d 与 ACS 遗漏开启”这两个最容易出错的环节
在进入操作系统安装前，必须完成以下三项固件检查：
1. 确认 CPU 支持 VT-d 并已在 BIOS 中启用。
2. 确认 PCIe 设备（网卡）的 SR-IOV 功能已开启。
3. 确认 ACS（Access Control Services）已启用，避免 PCIe 设备间非授权访问
关键机制：VT-d、SR-IOV 与 ACS 的协同关系
IOMMU（Intel 平台称为 VT-d，AMD 平台称为 AMD-Vi）是 SR-IOV 能够安全工作的基石。它负责将物理设备的 DMA 访问映射到虚拟机或容器的地址空间，防止设备越权访问宿主机内存。SR-IOV 则通过物理功能（PF）生成多个独立的虚拟功能（VF），每个 VF 可被直接分配给一个 Pod。ACS 是 PCIe 总线上的访问控制服务，它确保不同 VF 之间的 DMA 事务不会互相干扰，是生产环境中必须开启的安全特性
这三者的依赖关系是：VT-d → IOMMU 启用 → SR-IOV 功能可见 → ACS 提供隔离。任何一环缺失，都会导致 SR-IOV 在 Kubernetes 集群中无法正常工作
不要认为“BIOS 里找到了 SR-IOV 选项就完成了配置”。VT-d 和 ACS 的缺失是导致 SR-IOV 设备无法直通给 Pod 的最常见原因，且错误日志往往指向“IOMMU 未启用”或“PCIe ACS 错误”
BIOS与固件配置的技术资产与验证方式
由于不同服务器厂商（Dell、HPE、Supermicro、Inspur 等）的 BIOS 菜单布局差异较大，以下提供一份通用的检查清单，以及进入操作系统后的验证命令，用于确认配置是否生效
BIOS 配置检查清单
| 检查项 | 标准 | 是否通过 | 常见遗漏 |
|---|---|---|---|
| Intel VT-d / AMD-Vi | Enabled | ☐ | 仅开启 CPU 虚拟化（VT-x），未开启 VT-d |
| SR-IOV Support | Enabled | ☐ | 未在 PCIe 设备（网卡）对应的子菜单中单独开启 |
| ACS (Access Control Service… | Enabled | ☐ | 部分 BIOS 默认关闭，需在 PCIe 配置或高级芯… |
| Above 4G Decoding | Enabled | ☐ | 未开启会导致 64-bit PCIe BAR 地址分配… |
操作系统级验证命令
完成 BIOS 配置并重启进入 Linux 系统后，使用以下命令验证 IOMMU 和 SR-IOV 是否已正确暴露
# 检查 IOMMU 是否启用
dmesg | grep -i iommu
# 预期输出: DMAR: IOMMU enabled 或类似信息
# 检查 SR-IOV 虚拟功能（VF）总数
cat /sys/class/net/<PF_NAME>/device/sriov_totalvfs
# 预期输出: 一个大于 0 的数字，例如 64
# 检查当前已启用的 VF 数量
cat /sys/class/net/<PF_NAME>/device/sriov_numvfs
# 预期输出: 0（表示尚未创建 VF，属于正常状态）阅读这段代码时，重点看固件配置的伪代码，以及它如何用稳定性与可观测性证明结果可复测。
命令解释：dmesg | grep -i iommu 用于确认内核启动时是否成功初始化了 IOMMU 硬件单元。sriov_totalvfs 文件显示该物理网卡硬件支持的最大 VF 数量，如果该值为 0，说明 BIOS 中 SR-IOV 功能未开启或网卡固件不支持。sriov_numvfs 文件用于动态创建或销毁 VF，初始值为 0 是正常的
真实项目场景
某金融科技公司在部署 Kubernetes 集群时，SR-IOV Device Plugin 始终无法发现 VF。排查过程如下：
现象：kubectl 查看节点资源，intel.com/sriov_vf 数量为 0。
排查动作：登录节点执行 dmesg | grep -i iommu，输出为空；执行 cat /sys/class/net/eth0/device/sriov_totalvfs，返回 0。
工程判断：BIOS 中 VT-d 和 SR-IOV 均未开启。进入 BIOS 后，在“Advanced → CPU Configuration”中开启 VT-d，在“Advanced → PCI Subsystem Settings”中开启 SR-IOV Support。重启后，sriov_totalvfs 返回 64，问题解决
问题对照与修正
- 常见偏差：把固件配置直接写进主流程，只验证能跑通，留下固件配置边界、状态和验证口径不清。
- 修正做法：把固件配置收敛成稳定接口，明确伪代码和失败返回。
- 复核方式：构造一个异常输入或超时场景，用日志、断言和稳定性与可观测性证明修复有效。
配置未生效的典型表现的异常信号与处理步骤
固件配置错误不会导致服务器无法启动，但会表现为 SR-IOV 功能在操作系统层面“不可见”。以下是判断配置是否生效的边界标准：
部分运维人员认为“只要 BIOS 里开启了 SR-IOV，操作系统就能自动识别”。实际上，VT-d 和 ACS 的缺失会导致 VF 创建失败，且错误信息不直观。务必在配置完成后，通过 dmesg 和 sriov_totalvfs 进行双重验证
BIOS与固件配置先对齐现场任务、输入材料和输出结果，再回到固件配置的细节逐项核对。
BIOS与固件配置的主要风险来自固件配置边界、状态和验证口径不清；落地前必须核对伪代码，并确认例外场景和结果记录。
本节资料使用说明
BIOS与固件配置里最先使用的工具、样例或资料是哪一个？
替换固件配置时，哪些位置可以改，哪些位置要保留？
输出物检查时，最不能漏掉哪一项？
如果换一套素材，使用顺序要不要调整？