必须先确认硬件和固件支持，否则写sriov_numvfs会静默失败或触发“Cannot enable SR-IOV: insufficient MMIO space”内核报错；需用lspci -vv -s BDF | grep -A 10 "SR-IOV"验证PCIe寄存器级支持，查/sys/class/net/iface/device/sriov_totalvfs确认驱动层允许创建VF，且BIOS须开启SR-IOV、VT-d/AMD-Vi及Above 4G Decoding，内核参数必含intel_iommu=on iommu=pt（或amd_iommu=on），VF创建后需手动绑定驱动或直通虚拟机，不可依赖ip link自动显示。
必须先确认硬件和固件支持，否则直接写 sriov_numvfs 会静默失败或触发内核报错 Cannot enable SR-IOV: insufficient MMIO space。
检查网卡是否原生支持SR-IOV
不靠文档、不靠型号查表，直接看内核暴露的能力：
- 用
lspci -vv -s 0000:xx:xx.x | grep -A 10 "SR-IOV"（把xx:xx.x换成你的网卡BDF）——有输出即说明PCIe配置空间里存在SR-IOV扩展能力寄存器 - 查
/sys/class/net/enpXsY/device/sriov_totalvfs：值大于 0 才代表该PF允许创建VF；若报“no such file”，说明驱动未加载或设备不支持 -
lspci -k看当前绑定的驱动是否为厂商原生驱动（如ixgbe、i40e、ice），通用igb或e1000e驱动通常不支持SR-IOV
BIOS/UEFI 和内核参数是前置硬门槛
这两步跳过，后面所有操作都白忙：
- 进BIOS开启三项：SR-IOV、Intel VT-d（或AMD-Vi）、Above 4G Decoding（部分平台必须）
- 内核启动参数必须含
intel_iommu=on iommu=pt（Intel）或amd_iommu=on iommu=pt（AMD），否则VF无法被虚拟机直通 - 验证IOMMU是否启用：
dmesg | grep -i iommu应看到IOMMU enabled；cat /proc/cmdline确认参数已生效
通过sysfs动态启用VF，注意路径和权限
这是最常用也最容易出错的操作环节：
- 路径不是
/sys/class/net/eth0/device/...，而是/sys/class/net/enp125s0f3/device/—— 接口名要用内核命名（ip -br a或ls /sys/class/net/查），不能用旧式eth0 - 写入前先确认数值合法：
echo 2 > /sys/class/net/enp125s0f3/device/sriov_numvfs中的2不能超过sriov_totalvfs的值 - 必须用 root 权限执行，且不能在驱动已绑定VF后重复写入（会返回
Device or resource busy） - 成功后
lspci | grep -i "virtual function"或lspci -d ::a22f（以华为为例）能看到新VF设备，BDF号自动递增
VF创建后看不到网络接口？别急着 reload 驱动
VF本身是独立PCI设备，不自动注册为 ethX 类型网络接口——这是正常行为：
-
ip link show不会列出VF，因为VF尚未被任何驱动接管；需手动绑定VF驱动（如vfio-pci用于直通，或ixgbevf用于宿主机使用） - 若想在宿主机上直接用VF做网口，需先解绑PF驱动：
echo 0000:7d:01.0 > /sys/bus/pci/devices/0000:7d:01.0/driver/unbind，再绑定ixgbevf - 更常见的是将VF透传给KVM虚拟机：
virsh attach-device vm-name vf.xml，其中vf.xml描述的是VF的BDF，不是网口名
真正容易被忽略的是MMIO资源分配时机——BIOS必须在系统加电初期就为VF预留地址空间，这个窗口期不可逆；一旦启动完成，即使内核支持、驱动就绪、sysfs路径正确，sriov_numvfs 写入成功也只是“假装启用”，VF实际无法完成BAR映射，lspci -vv 里会显示 BAR 为全 0。
