简介Intel IOMMU输入/输出内存管理单元技术详解资源适合内核驱动开发者、虚拟化平台运维人员及底层系统学习者。压缩包以 v1.0 公共规范下的两个核心源码文件为主线完整呈现 IOMMU 驱动的实现框架包括设备注册、内存区域映射、DMA 请求处理、寄存器配置和故障隔离等关键环节。通过阅读代码可以弄清多虚拟机共享物理 I/O 设备时的地址翻译与保护原理理解 DMA 隔离如何防止设备越权访问内存并掌握 IOMMU 错误日志的初步解读思路。资源为 RAR 压缩包内含 2 个文件分别是 C 源文件和头文件压缩后整体仅 32KB结构紧凑、针对性极强适合直接对照硬件手册开展代码级分析。目前已有 226 人学习下载是快速掌握 Intel IOMMU 内部机制的轻量资料。学习过程中读者既能梳理关键数据结构和接口功能也能获得排查 DMA 错误、优化虚拟化 I/O 性能的实践思路结合具体代码路径可快速定位 IOMMU 初始化和地址映射的关键入口。1. Intel IOMMU 到底是什么一个压缩包名背后的虚拟化地基拿到一个叫 intel-iommu.rar_intel 的压缩包第一反应是什么解压出来可能是某个内核模块源码也可能是一份主板 BIOS 配置说明更可能是虚拟机直通 PCIe 设备时从网上扒下来的一堆日志。不管里面装了什么这个文件名指向的都是同一个东西Intel 平台上的 IOMMU也就是 VT-dVirtualization Technology for Directed I/O。它管的是 DMA——设备直接访问内存的那条通道。虚拟化、设备直通、安全隔离、高性能 I/O全都要先过它这一关。这篇笔记我会把 Intel IOMMU 的原理讲清楚把 BIOS 和内核参数怎么配写明白再把手套直通和排错的坑一个个踩平。适合正在配 PVE 或 KVM 的人也适合想给服务器做 DMA 隔离的运维和做高性能网络的开发者。2. 先把原理立住IOMMU 和 VT-d 在 Intel 平台上的分工与选型2.1 从 DMA 乱窜讲到 IOMMU为什么虚拟化离不开这张页表没有 IOMMU 的时候PCIe 设备做 DMA 是“裸奔”的。驱动程序告诉设备一个内存地址设备就直接往这个地址写数据不需要经过 CPU也不经过操作系统。单机单系统这没什么问题驱动自己保证地址合法就行。但虚拟化一进来就出大事了虚拟机里的驱动是客户机操作系统管理的它根本不知道宿主机物理内存的真实分布。如果允许客户机里的设备直接 DMA它可以读写宿主机任意物理内存等于随身带了一把万能钥匙。这不是理论风险是实际发生过的攻击路径。IOMMU 做的事情就是在设备和物理内存中间插一层地址翻译。设备发出的 DMA 地址叫设备地址Device AddressIOMMU 把这套地址翻译成宿主机物理地址并且检查权限。翻译工作由硬件完成CPU 不参与所以性能损耗被压得很低。它和 CPU 里的 MMU 是并列关系MMU 管 CPU 视角的虚拟内存IOMMU 管设备视角的 DMA 内存。两者各管各的所以虚拟化环境里缺了任何一边系统都能跑但都跑得不安全。我把 IOMMU 理解为“给 DMA 修的围墙”。没有这堵墙设备可以到处乱窜有了这堵墙设备只能在自己被分配的地址空间里活动。内核里开启 Intel IOMMU 后的日志里能看到 DMARDMA Remapping相关的行DMAR 就是 Intel 做这个翻译的具体硬件单元。2.2 Intel VT-d 和 AMD-Vi同是 IOMMU差异在哪几条Intel 平台上的 IOMMU 叫 VT-dAMD 平台上的叫 AMD-ViLinux 内核里对应的开关分别是 intel_iommuon 和 amd_iommuon。虽然叫法不同但它们解决的是同一个问题设备 DMA 重映射和中断重映射。真正写配置的时候差异不大选型上的差别主要在固件接口和功能完整性上。Intel VT-d 通过 ACPI 的 DMAR 表把硬件能力暴露给内核。DMAR 表里还包含 RMRRReserved Memory Region Reporting条目用于告诉内核哪些内存区域是设备在 BIOS 阶段就要用的不能随便分配给虚拟机。AMD-Vi 对应的 ACPI 表叫 IVRS。RMRR 这个机制是 Intel 特有的直通某些 Intel 网卡或显卡时如果 RMRR 没处理好虚拟机启动后设备会异常。Intel 还提供了中断重映射Interrupt Remapping可以把设备中断安全地路由到正确的虚拟机 vCPU 上没有它直通设备一产生中断整个宿主机可能直接重启。性能取向也有区别。Intel 的 VT-d 支持两种工作模式翻译模式和 passthrough 模式。翻译模式每一笔 DMA 都要查页表安全但有一点开销passthrough 模式让设备直接访问物理内存相当于把 IOMMU 的翻译能力让位给直接映射开销更小。AMD-Vi 也有类似的模式。我实际用下来的感受是同一块网卡在两种平台上都开 IOMMU吞吐差距在个位数百分比不需要为这点差异纠结平台倒是固件质量更值得关心。2.3 哪些场景值得开 IOMMU虚拟化之外的安全隔离与高性能 I/O开 IOMMU 最常见的理由是设备直通。把一块网卡、一张 GPU 或者一块 NVMe 直通给虚拟机没有 IOMMU 是做不到的因为 VFIO 机制依赖 IOMMU 去安全地管理设备 DMA。如果你跑 PVE 或者 KVM 虚拟化这条路是必选项。热词里搜“pve intel gvt-g”的开发者很多就是想把核显分给虚拟机最后都会卡在 IOMMU 分组上。第二个场景是安全隔离。即便是单机不跑虚拟化开 IOMMU 也能挡住恶意设备或者被攻破的驱动做 DMA 攻击。比如插入一个恶意 PCIe 设备它本来可以扫描物理内存抓密码有了 IOMMU 就只能碰自己被映射的地址空间。服务器安全基线里常有一条“开启 IOMMU”就是干这个用的。第三个场景是高性能用户态驱动。DPDK 这类应用让用户态程序直接操作网卡没有内核驱动保护可控的内存区域全靠 IOMMU 兜底。Ollama 这类推理工具如果要跑在虚拟化环境里并直通 Intel GPU同样依赖干净完整的 IOMMU 组。所以说 IOMMU 不是虚拟化专属它是现代高性能 I/O 的地基。我一般建议只要是 x86 服务器不管跑不跑虚拟机先把 IOMMU 打开利大于弊。3. 开启 Intel IOMMUBIOS、内核参数与引导配置实操3.1 BIOS 菜单上找 VT-d别只知道开 VT-x很多人进 BIOS 只找 “Intel Virtualization Technology”VT-x以为虚拟化开关就这一个。VT-x 是 CPU 虚拟化VT-d 是设备虚拟化两回事。直通设备必须同时开 VT-x 和 VT-d。不同主板厂商的菜单路径不一样华硕通常在 Advanced → CPU Configuration 里技嘉在 Advanced → Virtualization 或 IOMMU 条目里微星在 Overclocking 或 Settings 里超微服务器在 Advanced → System Serial Port 附近。笔记本 OEM 主板则经常把 VT-d 藏在隐藏菜单里搜“intel vt-x”“vt-d bios”是最快的办法。有个热词值得单独说自动化控制器跑实时内核比如 TwinCAT 在 Windows 下实现实时时要求“关闭 Hyper-Threading 并打开 VT-x”。这条要求和 IOMMU 不是一回事但容易混在一起。做实时内核时关超线程是为了减少调度不确定性开 VT-x 是为了让实时虚拟化能用上硬件加速VT-d 反而未必需要。所以拿到一台工控机先分清楚你到底是做设备直通还是做实时补丁别一通乱开。3.2 内核参数怎么写intel_iommuon 与 iommupt 的区别Linux 内核开启 Intel IOMMU 的标准姿势是改 GRUB 参数。我一般把参数写成一行同时带上intel_iommuon和iommupt。# 编辑 /etc/default/grub GRUB_CMDLINE_LINUXintel_iommuon iommupt # 重新生成引导配置 sudo update-grub # 或 CentOS/RHEL 系使用 # sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo rebootintel_iommuon是打开 Intel VT-d 的 DMA 重映射功能。iommupt是让 IOMMU 工作在 passthrough 模式翻译页表被简化为直接映射DMA 开销更小。这两个参数不冲突intel_iommuon负责让 IOMMU 生效iommupt负责选性能模式。如果只开intel_iommuon不写iommuptIOMMU 会进入全功能翻译模式部分驱动在开启 DMA 翻译后可能因为地址协商问题报错。所以我的默认组合就是上面这行。如果你用的是 NVMe 系统盘建议再加一个pcirealloc作用是让内核重新分配 PCIe 总线资源避免某些主板上 NVMe 和显卡争抢 bus number 导致直通后设备消失。加完参数后重启用下面的命令验证。3.3 用 dmesg 验证 IOMMU 已经接管设备重启后第一件事不是急着直通而是确认 IOMMU 真的生效了。命令很简单# 查看 DMAR 相关日志 dmesg | grep -i -e DMAR -e IOMMU # 确认 IOMMU 已启用 dmesg | grep -i DMAR: IOMMU enabled如果一切正常日志里会看到 “DMAR: IOMMU enabled” 以及 DMAR: Setting RMRR 之类的行。接下来看 IOMMU 分组是否合理这是直通可行性的判断依据。# 列出 IOMMU 分组 ls /sys/kernel/iommu_groups/ # 查看某个分组里的设备 ls -l /sys/kernel/iommu_groups/0/devices/每个分组代表硬件上同一套 DMA 域的设备集合。分组里只有目标设备是最理想的情况如果目标设备和声卡、USB 控制器挤在一组直通就会非常麻烦。分组情况由主板 PCIe 拓扑和 ACSAccess Control Services决定后面避坑章节会细说。4. 从 IOMMU 到设备直通把 PCIe 设备安全地交给虚拟机4.1 VFIO 与 vfio-pci把设备从内核手里摘出来IOMMU 开了之后设备直通走 VFIO 框架。VFIO 是一种用户态驱动框架它依赖 IOMMU 把设备和虚拟机内存安全地隔离开。直通流程分两步先让设备的原生驱动卸载再用 vfio-pci 接管设备。被 vfio-pci 接管后宿主机内核不再直接操作这个设备设备的访问权交给用户态QEMU/KVM虚拟机里看到的是一块“干净”的硬件。拿一块 Intel 网卡为例设备地址是 0000:01:00.0厂商 ID 是 8086设备 ID 是 15f2。先查设备当前驱动lspci -nnk -s 01:00.0输出的 Kernel driver in use 字段会告诉你当前驱动是谁。然后卸载原生驱动并绑定 vfio-pcisudo modprobe vfio-pci # 方法一用 new_id 动态绑定 echo 8086 15f2 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id # 方法二先解绑原驱动再绑定 vfio-pci echo 0000:01:00.0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/bindnew_id的作用是让 vfio-pci 承认这个设备 ID 并接管它但它不保证设备已经被摘干净。稳妥做法是先unbind原驱动再做bind。我实际踩过的坑是直接写new_id之后设备显示被 vfio-pci 接管但虚拟机启动后 DMA 报错原因就是原驱动没有完全解绑中断处理函数还挂在老驱动上。所以完整做法是两条命令都执行然后检查確認。4.2 从 Intel GPU 直通到 GVT-g图形方案怎么选CPU 里的核显直通是 IOMMU 的经典应用也是翻车重灾区。Intel 核显直通有几条路线选错一条就白折腾半天。整卡直通是把整个核显交给虚拟机宿主机的显示输出会消失一般配给无头服务器没问题。Intel 官方还提供过 GVT-gGraphics Virtualization Technology把一个核显分给多个虚拟机用性能接近物理显卡。搜索“pve intel gvt-g”能找到大量教程但要注意平台限制GVT-g 在 Broadwell 到 Coffee Lake 时代比较成熟之后的平台 Intel 逐步放弃了 GVT-g转向了 SR-IOV 虚拟化。如果你拿新平台照旧教程配 GVT-g大概率会卡在模块加载失败上。我的经验是先查 Intel ARK 上你的 CPU 是否支持 SR-IOV支持的话直接用新版内核和 QEMU 的 SR-IOV 直通方案比老 GVT-g 省心。独显直通相对简单NVIDIA 和 AMD 显卡直通都有成熟路线。Intel 独显配合最近“ollama 支持 intel gpu”的进展也有人搭虚拟机直通 GPU 跑推理。前提还是那一条IOMMU 分组必须干净否则直通后虚拟机会反复报 “Failed to set DMA mask”。4.3 一组最小直通命令从绑定到虚拟机启动把直通流程封装成一个脚本可以避免每次重复敲命令。下面是我常用的一套最小绑定脚本#!/bin/bash # 直通设备 BDF 地址 DEV0000:01:00.0 # Intel 网卡 Vendor:Device ID按实际替换 VID_DID8086 15f2 # 1. 解绑原生驱动 if [ -e /sys/bus/pci/devices/$DEV/driver ]; then echo $DEV | sudo tee /sys/bus/pci/devices/$DEV/driver/unbind fi # 2. 写入 vfio-pci 的 new_id echo $VID_DID | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id # 3. 强制绑定 echo $DEV | sudo tee /sys/bus/pci/drivers/vfio-pci/bind # 4. 确认状态 lspci -nnk -s ${DEV##*.}脚本里第 1 步先判断有没有原驱动有才解绑避免重复执行时报错。第 2 步用new_id注册设备 ID让 vfio-pci 认识这块卡第 3 步再显式绑定。有个细节第 3 步如果设备已经被自动绑定可能会报 “Device or resource busy”所以第 1 步的解绑必须成功执行。实际生产中更推荐用 driver_override 方式把设备 ID 写入/sys/bus/pci/devices/$DEV/driver_override再触发 bind这样可以避免内核在启动时抢先绑定原生驱动。绑定成功后在宿主机上用lspci -nnk -s 01:00.0会看到 “Kernel driver in use: vfio-pci”。此时启动虚拟机时加上 QEMU 参数即可-device vfio-pci,host0000:01:00.0,multifunctionon这里的multifunctionon只在该设备是多功能设备时需要。设备进虚拟机后在客户机里装上对应驱动就能像物理机一样使用了。5. Intel IOMMU 避坑指南5 个常见的翻车现场与排查路径5.1 开机 dmesg 里根本没有 DMAR先别怪内核现象按教程加了intel_iommuon重启后dmesg | grep DMAR一行输出都没有。 原因这一步 90% 是 BIOS 没开 VT-d而不是内核参数问题。部分主板默认关闭 VT-d尤其中低端桌面板菜单路径还很隐蔽。还有少数情况是内核没编 CONFIG_INTEL_IOMMU。 解决先重启进 BIOS找 VT-d 或 Intel Virtualization Technology for Directed I/O 打开。再验证内核配置grep CONFIG_INTEL_IOMMU /boot/config-$(uname -r)如果输出CONFIG_INTEL_IOMMUy但 dmesg 仍无日志恢复 BIOS 默认设置再重新配置一遍 VT-d 开关。我遇到过某品牌主板需要同时开启 “VT-x” 和 “VT-d” 两个选项后才在 ACPI 表里生成 DMAR。5.2 直通设备在虚拟机里报 DMA 或中断错误现象虚拟机启动后设备无法工作日志里出现 “Failed to set DMA mask” 或宿主机直接重启。 原因最常见的是中断重映射没开。没有 Interrupt Remapping 时虚拟机里的设备中断无法安全路由一旦设备产生中断宿主机 CPU 会收到无法识别的消息严重时直接 panic。 解决确认内核参数里没有noapic或irqremappingoff之类的禁用项。查看中断重映射状态dmesg | grep -i DMAR-IR dmesg | grep -i IRQ remapping正常情况是 “IRQ remapping enabled”。如果你是在老内核或特殊平台上直通不要一上来就加 KVM 的allow_unsafe_assigned_interrupts1这个是绕过安全检查的开关可能导致宿主机不稳定我只在实验环境用过。5.3 开了 IOMMU 后网卡性能反而下降现象做 DPDK 或大流量转发时开启intel_iommuon后吞吐下降 5%10%延迟变高。 原因IOMMU 默认走全功能翻译模式每笔 DMA 都要查页表并做 TLB 缓存刷新高频小包场景下开销被放大。 解决确认内核参数里是否写了iommupt。passthrough 模式下 IOMMU 不做事无巨细的页表翻译性能更接近不开 IOMMU 的状态。我一般建议要直通的机器用intel_iommuon iommupt组合既能用 VFIO 又保住吞吐。如果还是不够检查是不是 NUMA 拓扑问题把虚拟机 pinned 到和网卡同一个 NUMA node 上比调 IOMMU 参数更有效。5.4 vfio-pci 抢不到设备现象执行绑定后lspci -nnk显示 “Kernel driver in use: e1000e” 而不是 vfio-pci或者new_id写入时报 “Device or resource busy”。 原因设备的原生驱动比如 e1000e在系统启动时就绑定好了vfio-pci 没有机会接管。单纯写new_id不能解绑已经绑定的设备。 解决先解绑原驱动再绑定 vfio-pci顺序不能反。更彻底的办法是在/etc/modprobe.d/下写黑名单或软依赖让系统启动时直接让 vfio-pci 抢先接管目标设备# /etc/modprobe.d/vfio.conf options vfio-pci ids8086:15f2 softdep e1000e pre: vfio-pcisoftdep的意思是加载 e1000e 之前先加载 vfio-pci配合ids参数让 vfio-pci 在启动阶段就绑定指定设备。注意 e1000e 换成实际原生驱动名否则会无限循环加载失败。这也是直通 Intel 网卡时最常用的持久化做法。5.5 IOMMU 分组里有一堆“兄弟设备”现象想直通一块 PCIe 网卡发现ls /sys/kernel/iommu_groups/里它和一个 USB 控制器或声卡在同一个分组直通时虚拟机启动失败。 原因PCIe 设备没有实现 ACSAccess Control Services或者主板固件没有把 ACS 能力暴露给内核。没有 ACS 的交换机端口会让所有下游设备共享同一个 DMA 域IOMMU 只能把它们绑成一个组。 解决先看 BIOS 里有没有 “ACS” 或 “PCIe ACS Enable” 选项部分工作站主板有打开后分组会被拆细。如果没有可以尝试给内核打 ACS override 补丁强制拆分分组。这个操作属于“血泪经验”里的高风险招数它能绕过硬件的安全限制但可能会影响稳定性我不建议在生产环境乱来。实战里更稳妥的做法是换插槽把目标设备换到独立 root port 上。6. 验证与进阶从能用到用好再谈性能与安全验证IOMMU 配好、直通跑通之后还要留一步验证防止“能开机但性能是玄学”。先量化 DMA 开销用perf stat -e iommu_*这类事件看翻译开销或者在直通前后对同一块网卡跑iperf3对比吞吐差异。我自己习惯在直通前记录一条基线数据直通后同参数再跑一遍如果吞吐掉了超过 5%优先检查 NUMA 和iommupt。安全验证则可以刻意做一次“坏 DMA”实验在虚拟机里运行一个往宿主机内存地址写的测试程序正常情况下会被 IOMMU 拒绝并返回权限错误。内核日志里会留下 IOMMU fault 相关记录dmesg | grep -i IOMMU.*fault看到 DMAR: DRHD: handling fault status reg 就说明 IOMMU 真的在干活了。进阶方向上Intel 平台正在把 IOMMU 和 Shared Virtual MemorySVM结合让设备和 CPU 共享同一套页表这对 AI 推理和向量数据库这一类频繁搬运小数据的负载很有价值。如果你用的内核比较新可以在直通设备后查一下设备是否支持 PASIDlspci -vv -s 01:00.0 | grep -i pasid有 PASID 支持的话后续做用户态驱动和共享虚拟内存会有更多玩法。我对 IOMMU 的习惯是改完参数先保留一份/etc/default/grub备份再重刷引导升级内核之后第一时间确认 dmesg 里还有没有 DMAR 日志防止新内核默认行为变化导致直通直接失效。这套流程救过我很多次希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 15:31:40 · 阅读 1.2k Intel IOMMU与VT-d详解：从DMA隔离到PCIe设备直通避坑指南
简介Intel IOMMU输入/输出内存管理单元技术详解资源适合内核驱动开发者、虚拟化平台运维人员及底层系统学习者。压缩包以 v1.0 公共规范下的两个核心源码文件为主线完整呈现 IOMMU 驱动的实现框架包括设备注册、内存区域映射、DMA 请求处理、寄存器配置和故障隔离等关键环节。通过阅读代码可以弄清多虚拟机共享物理 I/O 设备时的地址翻译与保护原理理解 DMA 隔离如何防止设备越权访问内存并掌握 IOMMU 错误日志的初步解读思路。资源为 RAR 压缩包内含 2 个文件分别是 C 源文件和头文件压缩后整体仅 32KB结构紧凑、针对性极强适合直接对照硬件手册开展代码级分析。目前已有 226 人学习下载是快速掌握 Intel IOMMU 内部机制的轻量资料。学习过程中读者既能梳理关键数据结构和接口功能也能获得排查 DMA 错误、优化虚拟化 I/O 性能的实践思路结合具体代码路径可快速定位 IOMMU 初始化和地址映射的关键入口。1. Intel IOMMU 到底是什么一个压缩包名背后的虚拟化地基拿到一个叫 intel-iommu.rar_intel 的压缩包第一反应是什么解压出来可能是某个内核模块源码也可能是一份主板 BIOS 配置说明更可能是虚拟机直通 PCIe 设备时从网上扒下来的一堆日志。不管里面装了什么这个文件名指向的都是同一个东西Intel 平台上的 IOMMU也就是 VT-dVirtualization Technology for Directed I/O。它管的是 DMA——设备直接访问内存的那条通道。虚拟化、设备直通、安全隔离、高性能 I/O全都要先过它这一关。这篇笔记我会把 Intel IOMMU 的原理讲清楚把 BIOS 和内核参数怎么配写明白再把手套直通和排错的坑一个个踩平。适合正在配 PVE 或 KVM 的人也适合想给服务器做 DMA 隔离的运维和做高性能网络的开发者。2. 先把原理立住IOMMU 和 VT-d 在 Intel 平台上的分工与选型2.1 从 DMA 乱窜讲到 IOMMU为什么虚拟化离不开这张页表没有 IOMMU 的时候PCIe 设备做 DMA 是“裸奔”的。驱动程序告诉设备一个内存地址设备就直接往这个地址写数据不需要经过 CPU也不经过操作系统。单机单系统这没什么问题驱动自己保证地址合法就行。但虚拟化一进来就出大事了虚拟机里的驱动是客户机操作系统管理的它根本不知道宿主机物理内存的真实分布。如果允许客户机里的设备直接 DMA它可以读写宿主机任意物理内存等于随身带了一把万能钥匙。这不是理论风险是实际发生过的攻击路径。IOMMU 做的事情就是在设备和物理内存中间插一层地址翻译。设备发出的 DMA 地址叫设备地址Device AddressIOMMU 把这套地址翻译成宿主机物理地址并且检查权限。翻译工作由硬件完成CPU 不参与所以性能损耗被压得很低。它和 CPU 里的 MMU 是并列关系MMU 管 CPU 视角的虚拟内存IOMMU 管设备视角的 DMA 内存。两者各管各的所以虚拟化环境里缺了任何一边系统都能跑但都跑得不安全。我把 IOMMU 理解为“给 DMA 修的围墙”。没有这堵墙设备可以到处乱窜有了这堵墙设备只能在自己被分配的地址空间里活动。内核里开启 Intel IOMMU 后的日志里能看到 DMARDMA Remapping相关的行DMAR 就是 Intel 做这个翻译的具体硬件单元。2.2 Intel VT-d 和 AMD-Vi同是 IOMMU差异在哪几条Intel 平台上的 IOMMU 叫 VT-dAMD 平台上的叫 AMD-ViLinux 内核里对应的开关分别是 intel_iommuon 和 amd_iommuon。虽然叫法不同但它们解决的是同一个问题设备 DMA 重映射和中断重映射。真正写配置的时候差异不大选型上的差别主要在固件接口和功能完整性上。Intel VT-d 通过 ACPI 的 DMAR 表把硬件能力暴露给内核。DMAR 表里还包含 RMRRReserved Memory Region Reporting条目用于告诉内核哪些内存区域是设备在 BIOS 阶段就要用的不能随便分配给虚拟机。AMD-Vi 对应的 ACPI 表叫 IVRS。RMRR 这个机制是 Intel 特有的直通某些 Intel 网卡或显卡时如果 RMRR 没处理好虚拟机启动后设备会异常。Intel 还提供了中断重映射Interrupt Remapping可以把设备中断安全地路由到正确的虚拟机 vCPU 上没有它直通设备一产生中断整个宿主机可能直接重启。性能取向也有区别。Intel 的 VT-d 支持两种工作模式翻译模式和 passthrough 模式。翻译模式每一笔 DMA 都要查页表安全但有一点开销passthrough 模式让设备直接访问物理内存相当于把 IOMMU 的翻译能力让位给直接映射开销更小。AMD-Vi 也有类似的模式。我实际用下来的感受是同一块网卡在两种平台上都开 IOMMU吞吐差距在个位数百分比不需要为这点差异纠结平台倒是固件质量更值得关心。2.3 哪些场景值得开 IOMMU虚拟化之外的安全隔离与高性能 I/O开 IOMMU 最常见的理由是设备直通。把一块网卡、一张 GPU 或者一块 NVMe 直通给虚拟机没有 IOMMU 是做不到的因为 VFIO 机制依赖 IOMMU 去安全地管理设备 DMA。如果你跑 PVE 或者 KVM 虚拟化这条路是必选项。热词里搜“pve intel gvt-g”的开发者很多就是想把核显分给虚拟机最后都会卡在 IOMMU 分组上。第二个场景是安全隔离。即便是单机不跑虚拟化开 IOMMU 也能挡住恶意设备或者被攻破的驱动做 DMA 攻击。比如插入一个恶意 PCIe 设备它本来可以扫描物理内存抓密码有了 IOMMU 就只能碰自己被映射的地址空间。服务器安全基线里常有一条“开启 IOMMU”就是干这个用的。第三个场景是高性能用户态驱动。DPDK 这类应用让用户态程序直接操作网卡没有内核驱动保护可控的内存区域全靠 IOMMU 兜底。Ollama 这类推理工具如果要跑在虚拟化环境里并直通 Intel GPU同样依赖干净完整的 IOMMU 组。所以说 IOMMU 不是虚拟化专属它是现代高性能 I/O 的地基。我一般建议只要是 x86 服务器不管跑不跑虚拟机先把 IOMMU 打开利大于弊。3. 开启 Intel IOMMUBIOS、内核参数与引导配置实操3.1 BIOS 菜单上找 VT-d别只知道开 VT-x很多人进 BIOS 只找 “Intel Virtualization Technology”VT-x以为虚拟化开关就这一个。VT-x 是 CPU 虚拟化VT-d 是设备虚拟化两回事。直通设备必须同时开 VT-x 和 VT-d。不同主板厂商的菜单路径不一样华硕通常在 Advanced → CPU Configuration 里技嘉在 Advanced → Virtualization 或 IOMMU 条目里微星在 Overclocking 或 Settings 里超微服务器在 Advanced → System Serial Port 附近。笔记本 OEM 主板则经常把 VT-d 藏在隐藏菜单里搜“intel vt-x”“vt-d bios”是最快的办法。有个热词值得单独说自动化控制器跑实时内核比如 TwinCAT 在 Windows 下实现实时时要求“关闭 Hyper-Threading 并打开 VT-x”。这条要求和 IOMMU 不是一回事但容易混在一起。做实时内核时关超线程是为了减少调度不确定性开 VT-x 是为了让实时虚拟化能用上硬件加速VT-d 反而未必需要。所以拿到一台工控机先分清楚你到底是做设备直通还是做实时补丁别一通乱开。3.2 内核参数怎么写intel_iommuon 与 iommupt 的区别Linux 内核开启 Intel IOMMU 的标准姿势是改 GRUB 参数。我一般把参数写成一行同时带上intel_iommuon和iommupt。# 编辑 /etc/default/grub GRUB_CMDLINE_LINUXintel_iommuon iommupt # 重新生成引导配置 sudo update-grub # 或 CentOS/RHEL 系使用 # sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo rebootintel_iommuon是打开 Intel VT-d 的 DMA 重映射功能。iommupt是让 IOMMU 工作在 passthrough 模式翻译页表被简化为直接映射DMA 开销更小。这两个参数不冲突intel_iommuon负责让 IOMMU 生效iommupt负责选性能模式。如果只开intel_iommuon不写iommuptIOMMU 会进入全功能翻译模式部分驱动在开启 DMA 翻译后可能因为地址协商问题报错。所以我的默认组合就是上面这行。如果你用的是 NVMe 系统盘建议再加一个pcirealloc作用是让内核重新分配 PCIe 总线资源避免某些主板上 NVMe 和显卡争抢 bus number 导致直通后设备消失。加完参数后重启用下面的命令验证。3.3 用 dmesg 验证 IOMMU 已经接管设备重启后第一件事不是急着直通而是确认 IOMMU 真的生效了。命令很简单# 查看 DMAR 相关日志 dmesg | grep -i -e DMAR -e IOMMU # 确认 IOMMU 已启用 dmesg | grep -i DMAR: IOMMU enabled如果一切正常日志里会看到 “DMAR: IOMMU enabled” 以及 DMAR: Setting RMRR 之类的行。接下来看 IOMMU 分组是否合理这是直通可行性的判断依据。# 列出 IOMMU 分组 ls /sys/kernel/iommu_groups/ # 查看某个分组里的设备 ls -l /sys/kernel/iommu_groups/0/devices/每个分组代表硬件上同一套 DMA 域的设备集合。分组里只有目标设备是最理想的情况如果目标设备和声卡、USB 控制器挤在一组直通就会非常麻烦。分组情况由主板 PCIe 拓扑和 ACSAccess Control Services决定后面避坑章节会细说。4. 从 IOMMU 到设备直通把 PCIe 设备安全地交给虚拟机4.1 VFIO 与 vfio-pci把设备从内核手里摘出来IOMMU 开了之后设备直通走 VFIO 框架。VFIO 是一种用户态驱动框架它依赖 IOMMU 把设备和虚拟机内存安全地隔离开。直通流程分两步先让设备的原生驱动卸载再用 vfio-pci 接管设备。被 vfio-pci 接管后宿主机内核不再直接操作这个设备设备的访问权交给用户态QEMU/KVM虚拟机里看到的是一块“干净”的硬件。拿一块 Intel 网卡为例设备地址是 0000:01:00.0厂商 ID 是 8086设备 ID 是 15f2。先查设备当前驱动lspci -nnk -s 01:00.0输出的 Kernel driver in use 字段会告诉你当前驱动是谁。然后卸载原生驱动并绑定 vfio-pcisudo modprobe vfio-pci # 方法一用 new_id 动态绑定 echo 8086 15f2 | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id # 方法二先解绑原驱动再绑定 vfio-pci echo 0000:01:00.0 | sudo tee /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo 0000:01:00.0 | sudo tee /sys/bus/pci/drivers/vfio-pci/bindnew_id的作用是让 vfio-pci 承认这个设备 ID 并接管它但它不保证设备已经被摘干净。稳妥做法是先unbind原驱动再做bind。我实际踩过的坑是直接写new_id之后设备显示被 vfio-pci 接管但虚拟机启动后 DMA 报错原因就是原驱动没有完全解绑中断处理函数还挂在老驱动上。所以完整做法是两条命令都执行然后检查確認。4.2 从 Intel GPU 直通到 GVT-g图形方案怎么选CPU 里的核显直通是 IOMMU 的经典应用也是翻车重灾区。Intel 核显直通有几条路线选错一条就白折腾半天。整卡直通是把整个核显交给虚拟机宿主机的显示输出会消失一般配给无头服务器没问题。Intel 官方还提供过 GVT-gGraphics Virtualization Technology把一个核显分给多个虚拟机用性能接近物理显卡。搜索“pve intel gvt-g”能找到大量教程但要注意平台限制GVT-g 在 Broadwell 到 Coffee Lake 时代比较成熟之后的平台 Intel 逐步放弃了 GVT-g转向了 SR-IOV 虚拟化。如果你拿新平台照旧教程配 GVT-g大概率会卡在模块加载失败上。我的经验是先查 Intel ARK 上你的 CPU 是否支持 SR-IOV支持的话直接用新版内核和 QEMU 的 SR-IOV 直通方案比老 GVT-g 省心。独显直通相对简单NVIDIA 和 AMD 显卡直通都有成熟路线。Intel 独显配合最近“ollama 支持 intel gpu”的进展也有人搭虚拟机直通 GPU 跑推理。前提还是那一条IOMMU 分组必须干净否则直通后虚拟机会反复报 “Failed to set DMA mask”。4.3 一组最小直通命令从绑定到虚拟机启动把直通流程封装成一个脚本可以避免每次重复敲命令。下面是我常用的一套最小绑定脚本#!/bin/bash # 直通设备 BDF 地址 DEV0000:01:00.0 # Intel 网卡 Vendor:Device ID按实际替换 VID_DID8086 15f2 # 1. 解绑原生驱动 if [ -e /sys/bus/pci/devices/$DEV/driver ]; then echo $DEV | sudo tee /sys/bus/pci/devices/$DEV/driver/unbind fi # 2. 写入 vfio-pci 的 new_id echo $VID_DID | sudo tee /sys/bus/pci/drivers/vfio-pci/new_id # 3. 强制绑定 echo $DEV | sudo tee /sys/bus/pci/drivers/vfio-pci/bind # 4. 确认状态 lspci -nnk -s ${DEV##*.}脚本里第 1 步先判断有没有原驱动有才解绑避免重复执行时报错。第 2 步用new_id注册设备 ID让 vfio-pci 认识这块卡第 3 步再显式绑定。有个细节第 3 步如果设备已经被自动绑定可能会报 “Device or resource busy”所以第 1 步的解绑必须成功执行。实际生产中更推荐用 driver_override 方式把设备 ID 写入/sys/bus/pci/devices/$DEV/driver_override再触发 bind这样可以避免内核在启动时抢先绑定原生驱动。绑定成功后在宿主机上用lspci -nnk -s 01:00.0会看到 “Kernel driver in use: vfio-pci”。此时启动虚拟机时加上 QEMU 参数即可-device vfio-pci,host0000:01:00.0,multifunctionon这里的multifunctionon只在该设备是多功能设备时需要。设备进虚拟机后在客户机里装上对应驱动就能像物理机一样使用了。5. Intel IOMMU 避坑指南5 个常见的翻车现场与排查路径5.1 开机 dmesg 里根本没有 DMAR先别怪内核现象按教程加了intel_iommuon重启后dmesg | grep DMAR一行输出都没有。 原因这一步 90% 是 BIOS 没开 VT-d而不是内核参数问题。部分主板默认关闭 VT-d尤其中低端桌面板菜单路径还很隐蔽。还有少数情况是内核没编 CONFIG_INTEL_IOMMU。 解决先重启进 BIOS找 VT-d 或 Intel Virtualization Technology for Directed I/O 打开。再验证内核配置grep CONFIG_INTEL_IOMMU /boot/config-$(uname -r)如果输出CONFIG_INTEL_IOMMUy但 dmesg 仍无日志恢复 BIOS 默认设置再重新配置一遍 VT-d 开关。我遇到过某品牌主板需要同时开启 “VT-x” 和 “VT-d” 两个选项后才在 ACPI 表里生成 DMAR。5.2 直通设备在虚拟机里报 DMA 或中断错误现象虚拟机启动后设备无法工作日志里出现 “Failed to set DMA mask” 或宿主机直接重启。 原因最常见的是中断重映射没开。没有 Interrupt Remapping 时虚拟机里的设备中断无法安全路由一旦设备产生中断宿主机 CPU 会收到无法识别的消息严重时直接 panic。 解决确认内核参数里没有noapic或irqremappingoff之类的禁用项。查看中断重映射状态dmesg | grep -i DMAR-IR dmesg | grep -i IRQ remapping正常情况是 “IRQ remapping enabled”。如果你是在老内核或特殊平台上直通不要一上来就加 KVM 的allow_unsafe_assigned_interrupts1这个是绕过安全检查的开关可能导致宿主机不稳定我只在实验环境用过。5.3 开了 IOMMU 后网卡性能反而下降现象做 DPDK 或大流量转发时开启intel_iommuon后吞吐下降 5%10%延迟变高。 原因IOMMU 默认走全功能翻译模式每笔 DMA 都要查页表并做 TLB 缓存刷新高频小包场景下开销被放大。 解决确认内核参数里是否写了iommupt。passthrough 模式下 IOMMU 不做事无巨细的页表翻译性能更接近不开 IOMMU 的状态。我一般建议要直通的机器用intel_iommuon iommupt组合既能用 VFIO 又保住吞吐。如果还是不够检查是不是 NUMA 拓扑问题把虚拟机 pinned 到和网卡同一个 NUMA node 上比调 IOMMU 参数更有效。5.4 vfio-pci 抢不到设备现象执行绑定后lspci -nnk显示 “Kernel driver in use: e1000e” 而不是 vfio-pci或者new_id写入时报 “Device or resource busy”。 原因设备的原生驱动比如 e1000e在系统启动时就绑定好了vfio-pci 没有机会接管。单纯写new_id不能解绑已经绑定的设备。 解决先解绑原驱动再绑定 vfio-pci顺序不能反。更彻底的办法是在/etc/modprobe.d/下写黑名单或软依赖让系统启动时直接让 vfio-pci 抢先接管目标设备# /etc/modprobe.d/vfio.conf options vfio-pci ids8086:15f2 softdep e1000e pre: vfio-pcisoftdep的意思是加载 e1000e 之前先加载 vfio-pci配合ids参数让 vfio-pci 在启动阶段就绑定指定设备。注意 e1000e 换成实际原生驱动名否则会无限循环加载失败。这也是直通 Intel 网卡时最常用的持久化做法。5.5 IOMMU 分组里有一堆“兄弟设备”现象想直通一块 PCIe 网卡发现ls /sys/kernel/iommu_groups/里它和一个 USB 控制器或声卡在同一个分组直通时虚拟机启动失败。 原因PCIe 设备没有实现 ACSAccess Control Services或者主板固件没有把 ACS 能力暴露给内核。没有 ACS 的交换机端口会让所有下游设备共享同一个 DMA 域IOMMU 只能把它们绑成一个组。 解决先看 BIOS 里有没有 “ACS” 或 “PCIe ACS Enable” 选项部分工作站主板有打开后分组会被拆细。如果没有可以尝试给内核打 ACS override 补丁强制拆分分组。这个操作属于“血泪经验”里的高风险招数它能绕过硬件的安全限制但可能会影响稳定性我不建议在生产环境乱来。实战里更稳妥的做法是换插槽把目标设备换到独立 root port 上。6. 验证与进阶从能用到用好再谈性能与安全验证IOMMU 配好、直通跑通之后还要留一步验证防止“能开机但性能是玄学”。先量化 DMA 开销用perf stat -e iommu_*这类事件看翻译开销或者在直通前后对同一块网卡跑iperf3对比吞吐差异。我自己习惯在直通前记录一条基线数据直通后同参数再跑一遍如果吞吐掉了超过 5%优先检查 NUMA 和iommupt。安全验证则可以刻意做一次“坏 DMA”实验在虚拟机里运行一个往宿主机内存地址写的测试程序正常情况下会被 IOMMU 拒绝并返回权限错误。内核日志里会留下 IOMMU fault 相关记录dmesg | grep -i IOMMU.*fault看到 DMAR: DRHD: handling fault status reg 就说明 IOMMU 真的在干活了。进阶方向上Intel 平台正在把 IOMMU 和 Shared Virtual MemorySVM结合让设备和 CPU 共享同一套页表这对 AI 推理和向量数据库这一类频繁搬运小数据的负载很有价值。如果你用的内核比较新可以在直通设备后查一下设备是否支持 PASIDlspci -vv -s 01:00.0 | grep -i pasid有 PASID 支持的话后续做用户态驱动和共享虚拟内存会有更多玩法。我对 IOMMU 的习惯是改完参数先保留一份/etc/default/grub备份再重刷引导升级内核之后第一时间确认 dmesg 里还有没有 DMAR 日志防止新内核默认行为变化导致直通直接失效。这套流程救过我很多次希望帮到你。本文还有配套的精品资源点击获取