+
IOMMU 深度实战：从 DMA 攻击防护到 VFIO 设备直通
当一张网卡可以直接读写主机的任意物理内存时，系统安全的根基就动摇了。IOMMU 正是为解决这一问题而生——它既是设备直通的基石，也是现代虚拟化安全的第一道防线。
一、问题的起点：DMA 的"裸奔"时代
在没有 IOMMU 的时代，外设发起的 DMA（Direct Memory Access）操作可以访问物理地址空间的任意位置。这意味着：
- 恶意或故障设备可以覆盖内核代码、窃取密钥数据、篡改页表。
- 驱动 Bug 可能让设备写入错误区域，导致静默数据损坏。
- 虚拟化场景中，Guest 物理地址与 Host 物理地址不对应，设备直接使用 Guest 物理地址会直接崩溃。
- DMAR_GSTS（Global Status）：IOMMU 使能状态
- DMAR_RTADDR（Root Table Address）：根表物理地址
- DMAR_FECTL（Fault Event Control）：错误中断配置
- DMAR_FEDATA / DMAR_FEADDR：错误信息寄存器
- Device Table：每个 PCI Function 一个 Entry
- Page Table：类似 CPU 页表的 I/O 页表
- Interrupt Remapping Table：独立的中断重映射表
- Event/Pinnet Buffer：环形缓冲区接收错误事件
- Stream Table：替代 PCI Bus/Device 概念，使用 StreamID 标识设备
- Context Descriptor：每个设备/进程的翻译配置
- 支持 PRI/PASID：进程级 I/O 虚拟化
- 零拷贝共享：设备直接使用进程地址空间，无需 DMA 缓冲区拷贝
- 简化编程模型：驱动无需管理 IOVA 映射，直接用指针
- Legacy Mode：Host IOMMU 翻译 GPA→HPA（KVM 负责）
- Scalable Mode：两级翻译，Guest IOVA → Guest 物理 → Host 物理
- 第一级由 Guest 管理 (类似 CPU 二级翻译)
- 第二级由 Host VT-d 硬件翻译
- Type2 设备 (CXL.accel)：像本地设备一样参与缓存一致性，SVA 变得至关重要。
- Type3 设备 (CXL.memory)：内存池化交换，IOVA 管理的粒度更细。
- 多层级翻译：Host Bridge 到 CXL Switch，每层独立的 STE 状态管理。
- 支持细粒度 (4KB) 的 CXL.memory 热插拔区域
- 与 CXL.cache 协议协同的一致性边界管理
- 全局 IOVA 空间寻址 (跨节点共享)
- 安全：阻止 DMA 攻击，保护内核和用户空间内存
- 虚拟化：为 VFIO、SVM、MDEV 提供硬件基础
- 性能：大页映射 + IOTLB + PASID 实现高效 I/O 虚拟化
传统的解决方案是 bounce buffer（弹跳缓冲区）：内核在设备可访问的低地址区域分配一块内存，数据先 DMA 到 bounce buffer，再由 CPU 拷贝到目标位置。这种方式在 32 位时代大行其道，但在 64 位时代和高速 NVMe 网卡场景下，额外的拷贝开销已不可接受。
IOMMU 的出现，让设备第一次拥有了受控的地址空间视图——就像 CPU 有 MMU 一样，设备有了"自己的 MMU"。
二、IOMMU 硬件架构：从 PCIe ATC 到二级页表
现代 IOMMU 的核心思想与 CPU MMU 类似：每个设备（或进程）看到的是 I/O 虚拟地址（IOVA），IOMMU 负责将其翻译为物理地址。
2.1 Intel VT-d 架构
Intel VT-d 是最广泛部署的 IOMMU 实现，其核心数据结构是 root table 和 context table 组成的二级查找结构：
``` ┌─────────────────────────────────────────┐ │ Root Table (256 项) │ │ 每个 PCI Bus 对应一个 Entry │ │ ┌───────────────────────────────────┐ │ │ │ Bus 0 → Context Table ptr │ │ │ │ Bus 1 → Context Table ptr │ │ │ │ ... │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Context Table (256 项) │ │ 每个 Function (Device.Function) 一个 │ │ ┌───────────────────────────────────┐ │ │ │ Dev:Fn → Second-level Page Table │ │ │ │ Dev:Fn → PASID Table (SVA/PRI) │ │ │ │ TTP (Translation Type) 控制 │ │ │ └───────────────────────────────────┘ │ └─────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ Second-level Page Table │ │ 类似 CPU 页表的多级结构 │ │ 支持 4KB / 2MB / 1GB 页映射 │ │ 最终翻译为 Host Physical Address │ └─────────────────────────────────────────┘ ```关键寄存器：
2.2 AMD-Vi (IOMMU) 架构
AMD 的实现称为 Device Table，概念类似但结构略有不同：
2.3 ARM SMMU
ARM 的 System MMU 为 SoC 中的非 CPU 主设备（GPU、NPU、DMA 控制器）提供地址翻译：
三、Linux 内核 IOMMU 子系统：DMA API 全解析
Linux 内核提供了一套统一的 DMA 映射 API，底层适配各种 IOMMU 实现：
3.1 DMA 映射的三种模式
```c /* ========== 模式1: 一致性映射 (Coherent) ========== */ /* 适用于长时间驻留的缓冲区（如描述符环、控制结构） */ void *dma_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flag); /* CPU 和设备同时读写，无 Cache 同步开销 */ /* 底层通常使用 uncacheable 或 write-through 映射 */ /* ========== 模式2: 流式映射 (Streaming) ========== */ /* 适用于一次性传输的缓冲区（如网络包、磁盘 I/O） */ dma_addr_t dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction dir); void dma_unmap_single(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction dir); /* dir: DMA_TO_DEVICE / DMA_FROM_DEVICE / DMA_BIDIRECTIONAL */ /* 映射/解映射时需要执行 Cache 刷回操作 (dma_sync_*) */ /* ========== 模式3: SG (Scatter-Gather) 映射 ========== */ /* 适用于非连续物理页面的批量传输 */ int dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction dir); struct scatterlist *sg = ...) // 构建 sg list int nents = pci_map_sg(pdev, sglist, nents, direction); // sg[i].dma_address → 设备使用的 IOVA // sg[i].dma_length → 实际传输长度（可能被 IOMMU 合并） ```3.2 IOMMU Domain 与 Group
```c /* IOMMU Domain = 一组设备的地址空间上下文 */ struct iommu_domain { struct iommu_ops *ops; void *priv; // IOMMU 驱动私有数据 // 页表根指针、地址空间大小等 }; /* IOMMU Group = 必须共享地址空间的设备集合 */ // 判断依据：下游 PCIe Port 是否支持 ACS (Access Control Services) // 无 ACS 的 Group 内设备不能隔离 /* 查看系统 IOMMU Group 结构 */ # find /sys/kernel/iommu_groups/ -type l /sys/kernel/iommu_groups/0/devices/0000:00:01.0 /sys/kernel/iommu_groups/1/devices/0000:00:1d.0 ```3.3 IOMMU Page Table 管理
当 IOMMU 启用时，IO 子系统的页表操作通过 IO_PGTABLE 框架实现：
```c /* IO Virtual Address (IOVA) 分配策略 */ struct iommu_domain { struct iova_domain iovad; // IOVA 空间管理器 // 使用 Fls/伙伴系统分配 IOVA 范围 }; /* Intel VT-d 页表操作 (drivers/iommu/intel/iommu.c) */ static struct io_pgtable_ops intel_pgtable_ops = { .map = intel_iommu_map, .unmap = intel_iommu_unmap, .iova_to_phys = intel_iommu_iova_to_phys, // 支持 lazy TLB 批量失效 ( iotlb_sync ) }; /* 大页支持 (2MB/1GB) - TLB 性能关键 */ # cat /sys/module/vtd/options/enable_1gb_pages # iommu.passthrough=0/1 // 内核参数控制 ```四、VFIO：用户态设备驱动的艺术
VFIO (Virtual Function I/O) 是 Linux 中实现 PCI 直通和设备隔离的标准框架。没有 IOMMU，VFIO 无从谈起。
4.1 VFIO 架构流程
``` ┌─────────────────────────────────────────────────────┐ │ QEMU / DPDK / SPDK │ │ (用户态进程) │ │ VFIO Device API: │ │ ├── VFIO_DEVICE_GET_INFO (获取设备信息) │ │ ├── VFIO_DEVICE_GET_REGION_INFO (映射 BAR) │ │ ├── VFIO_DEVICE_GET_IRQ_INFO (配置中断) │ │ ├── VFIO_DEVICE_SET_IRQS (使能中断) │ │ ├── VFIO_IOMMU_MAP_DMA (注册内存) │ │ └── VFIO_DEVICE_RESET (设备复位) │ └─────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────┐ │ VFIO Kernel Module │ │ /dev/vfio/vfio → IOMMU Framework │ │ /dev/vfio/4.2 VFIO 实战：将 NVMe 直通给虚拟机
```bash # ====== 步骤1: 加载 VFIO 驱动 ====== # 卸载原驱动，绑定到 vfio-pci echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo "8086 f1a5" > /sys/bus/pci/drivers/vfio-pci/new_id # ====== 步骤2: 通过 QEMU 使用直通设备 ====== qemu-system-x86_64 \ -machine q35,kernel_irqchip=split \ -device vfio-pci,host=01:00.0,multifunction=on \ ... # ====== 步骤3: DPDK 直接使用 VFIO 设备 ====== # DPDK 自动通过 VFIO 初始化 IOMMU 设备 ./dpdk-test --vdev=vfio-pci,ixgbe ```4.3 IOMMU DMA 映射编程接口
```c /* VFIO 映射进程虚拟地址 → IOVA → 物理内存 */ struct vfio_iommu_type1_dma_map dma_map = { .argsz = sizeof(dma_map), .flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE, .vaddr = (uint64_t)user_vaddr, // 进程虚拟地址 .iova = target_iova, // 需要分配的 IOVA .size = buffer_size, // 映射大小 }; ioctl(vfio_fd, VFIO_IOMMU_MAP_DMA, &dma_map); /* * 结果: IOMMU 页表建立了 IOVA → 物理页的映射 * * 当设备发起 DMA 到 target_iova 时: * 1. IOMMU 查表确认该 IOVA 是否已映射 * 2. 未映射 → DMAR 错误 (DMA Remapping Fault) * 3. 已映射 → 翻译为物理地址，执行访问 */ ```五、高级特性：PASID、SVA 与 PRI
5.1 PASID (Process Address Space Identifier)
PCIe 3.1 引入的 PASID 扩展，让单个物理设备可以被多个进程独立共享：
``` ┌─────────────────────────────────────────┐ │ PASID TLP 前缀 │ │ ┌────────┬────────┬─────────────────┐ │ │ │ PASID │ 其他 │ DMA Request │ │ │ │ (20bit)│ │ │ │ │ └────────┴────────┴─────────────────┘ │ └─────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────┐ │ PASID Table (per device) │ │ PASID 0 → Process A Page Table │ │ PASID 1 → Process B Page Table │ │ PASID 2 → Process C Page Table │ └─────────────────────────────────────────┘ ```PASID 让设备分区（如 ML 加速卡）真正共享——不同进程的 DMA 操作天然隔离，无需 QEMU 级别的 MDEV 虚拟化。
5.2 SVA (Shared Virtual Addressing)
SVA 的核心思想：设备直接使用进程的 CPU 页表，IOVA == Virtual Address。
```c /* 内核 SVA API (drivers/iommu/iommu-sva.c) */ int iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, struct iommu_sva_handle *handle); /* 工作流程: * 1. 进程分配虚拟地址 (malloc / mmap) * 2. 进程调用 bind 将设备与自己的 IOMMU 翻译关联 * 3. CPU 和设备看到同一份页表 → 同一套虚拟地址 * 4. 设备的缺页由内核驱动处理 (iommu_report_device_fault) */ ```SVA 的好处：
5.3 PRI (Page Request Interface)
当设备访问未映射的 IOVA 时，触发缺页中断，内核动态填充页表：
```c /* PRI 缺页处理流程: * 1. 设备发起 DMA → IOMMU 缺页 → 产生 Page Request Event * 2. 设备发送 Page Request（包含 PASID + Fault Address） * 3. 内核处理请求: * a) 合法缺页: 分配物理页，映射到 IOMMU 页表，返回 PRG Response * b) 非法访问: 发送 PRG Response (last+failure) → 设备 DMA 失败 * 4. 设备重试 DMA */ /* 性能关键：批处理 + On-Demand */ # cat /sys/module/vtd/options/pq_latency_priority ```六、IOMMU 在虚拟化中的应用
6.1 vIOMMU（虚拟 IOMMU）
Guest OS 需要自己的 IOMMU 来管理 Guest 设备的 DMA。QEMU/KVM 支持模拟两种：
| 类型 | 实现方式 | 性能 | 适用场景 |
|---|---|---|---|
| Virtio-IOMMIO (virtio-iommu) | 软件模拟翻译 | 中等 | 通用设备直通行为 |
| intel-iommu (q35) | 直接包 passthrough | 高 | 需要 Guest 内 IOMMU 的工作负载 |
支持更灵活的翻译模式：
6.3 MDEV (Mediated Device)
对于无法独立分配的物理 GPU（如 Intel GVT-g、NVIDIA vGPU），通过 MDEV 控制设备复用：
```bash # 查询支持的 MDEV 类型 ls /sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/ # 创建虚拟 GPU 实例 echo "$uuid" > /sys/bus/pci/devices/0000:00:02.0/mdev_supported_types/i915-GVTg_V5_4/create ```七、性能优化：IOMMU 的开销与调优
7.1 关键性能开销
IOMMU 引入的主要延迟来源：
| 环节 | 典型延迟 | 说明 | |
|---|---|---|---|
| 页表 Walk | 100-200ns | 等效 CPU MMU，可 TLB 加速 | |
| IOTLB Miss | 300-500ns | 跨级翻译额外延迟 | |
| IOTLB Shootdown | 1-10μs | 映射无效广播给所有设备 | |
| PASID 切换 | 50-100ns | TLB 标签切换 | |
| 场景 | 禁用 IOMMU | 启用 IOMMU (4KB) | 启用 IOMMU (大页) |
| NVMe 顺序读 | 8.5 GB/s | 8.1 GB/s (-5%) | 8.4 GB/s (-1%) |
| 100G NIC 包转发 | 120Mpps | 98Mpps (-18%) | 115Mpps (-4%) |
| GPU P2P DMA | 50 GB/s | 45 GB/s (-10%) | 48 GB/s (-4%) |
CXL (Compute Express Link) 带来了缓存一致性内存池化，对 IOMMU 提出新挑战：
未来 IOMMU 可能需要：
十、总结
IOMMU 是现代系统不可或缺的子系统，承担着设备隔离、安全防护和地址翻译三重职责：
对于系统工程师而言，理解 IOMMU 意味着理解设备与内存交互的"最后一公里"。无论是调试直通设备的性能异常，还是排查 DMA 错误导致的系统崩溃，IOMMU 知识都是必备的核心技能。
掌握 IOMMU 的硬件架构、内核 API 调优与调试方法，让你在设备驱动、虚拟化基础设施和高性能网络开发中游刃有余。
发表评论 取消回复