第1章：IOMMU硬件架构全景
大家好，我是你们的讲师。今天咱们聊聊IOMMU的硬件架构。说实话，这玩意儿我第一次接触时也是一头雾水——三个厂商，三套方案，名字还都不一样。但等你真正搞懂了，会发现它们解决的是同一个问题：让设备能安全地访问内存。
核心观点：IOMMU的本质，就是给设备加了个"内存管理单元"。就像CPU用MMU管理进程地址空间一样，IOMMU管理的是设备地址空间。
1.1 为什么需要IOMMU？
先问个问题：没有IOMMU会怎样？
我早年做嵌入式开发时，遇到过这么个坑：一个DMA控制器写错了地址，直接把内核数据区给覆盖了。系统瞬间崩溃，连个日志都没留下。嗯，这就是典型的"设备乱写内存"问题。
IOMMU要解决三个核心痛点：
- 设备隔离：防止恶意或故障设备访问不该访问的内存
- 地址翻译：让设备能使用虚拟地址，而不是物理地址
- 大页支持：减少TLB miss，提升性能
说白了，IOMMU就是给设备戴上了"紧箍咒"。设备想读写内存？先过IOMMU这关。
2. Intel VT-d详解
Intel的方案叫VT-d（Virtualization Technology for Directed I/O）。我个人习惯叫它"VT-d"，因为念起来顺口。
2.1 核心架构
VT-d的核心组件包括：
- DMA Remapping：重映射DMA请求，把设备地址翻译成物理地址
- Interrupt Remapping：重映射中断，确保中断能正确路由到虚拟机
- ATS（Address Translation Services）：让设备自己缓存地址翻译结果
我记得第一次看VT-d的spec时，被那个"Root Entry Table"给绕晕了。后来画了个图才明白：
你看，VT-d用了四级页表，和CPU的页表结构一模一样。这设计很聪明——复用已有的MMU逻辑，硬件实现起来也简单。
2.2 关键寄存器
VT-d有几个寄存器你必须记住：
| 寄存器名 | 偏移 | 作用 |
|---|---|---|
| DMAR_CAP | 0x00 | Capability寄存器，告诉你硬件支持什么特性 |
| DMAR_ECAP | 0x08 | Extended Capability，扩展特性 |
| DMAR_GCMD | 0x10 | 全局命令寄存器，用来开启/关闭IOMMU |
| DMAR_GSTS | 0x18 | 全局状态寄存器，查看当前状态 |
| DMAR_RTADDR | 0x20 | Root Entry Table基地址 |
避坑指南：我曾经在配置VT-d时，忘了检查DMAR_CAP中的SAGAW字段（Supported Address Width）。结果页表层级配错了，设备一DMA就报错。后来养成了习惯：先读CAP，再配寄存器。
3. AMD-Vi详解
AMD的方案叫AMD-Vi（以前叫IOMMU）。说实话，AMD的文档写得比Intel清晰，但生态没Intel大。
3.1 核心差异
AMD-Vi和VT-d最大的区别在于：
- 设备表结构不同：AMD用Device Table，Intel用Root+Context两级
- 页表格式不同：AMD支持自己的页表格式，也兼容x86-64页表
- 中断重映射方式不同：AMD用INTx和MSI重映射表
你想想看，为什么AMD要另搞一套？我个人觉得，AMD是想绕开Intel的专利。毕竟VT-d的专利都在Intel手里。
3.2 关键数据结构
AMD-Vi的核心数据结构就两个：
// Device Table Entry (DTE) 结构
struct amd_iommu_dte {
uint64_t val[2]; // 128位条目
// 关键字段
uint64_t tv : 1; // Translation Valid
uint64_t ir : 1; // Interrupt Remap
uint64_t iw : 1; // Interrupt Window
uint64_t pte_root : 52; // 页表根指针
};
嗯，这里要注意：AMD的DTE是128位的，而Intel的Context Entry是256位的。这意味着AMD的条目能承载的信息更少，但硬件实现更简单。
4. ARM SMMU详解
ARM的SMMU（System Memory Management Unit）是移动设备和嵌入式领域的霸主。我最近几年做ARM服务器项目，天天跟SMMU打交道。
4.1 SMMU版本演进
| 版本 | 特点 | 典型应用 |
|---|---|---|
| SMMUv1 | 基础地址翻译，支持32位地址 | 早期ARM SoC |
| SMMUv2 | 支持64位地址，增加安全扩展 | 移动设备、IoT |
| SMMUv3 | 完全重写，支持PCIe ATS、PASID | ARM服务器、数据中心 |
我个人强烈建议：新项目直接上SMMUv3。v2的兼容性问题太多了，我在一个项目中就被v2的"安全状态切换"坑过——设备在Secure和Non-Secure之间切换时，TLB没刷干净，数据泄露了。
4.2 SMMUv3核心概念
SMMUv3引入了几个新概念：
- STE（Stream Table Entry）：类似Intel的Context Entry，描述一个设备流
- CD（Context Descriptor）：描述一个进程地址空间
- PASID（Process Address Space ID）：让设备能区分不同进程
说白了，SMMUv3把IOMMU从"设备级"细化到了"进程级"。一个物理设备可以同时服务多个虚拟机进程，每个进程有自己的地址空间。
注意：SMMUv3的STE和CD是分开存储的。我曾经见过有人把STE和CD放在同一个内存区域，结果配置时互相覆盖，系统直接挂掉。记住：STE在内存中连续存放，CD可以分散存放。
5. IOMMU硬件寄存器
不管哪个厂商，IOMMU的寄存器都遵循类似的模式。我总结了一个"三件套"：
- 控制寄存器：开启/关闭IOMMU，设置模式
- 状态寄存器：查询错误、中断状态
- 配置寄存器：设置页表基地址、设备表基地址
以SMMUv3为例，关键寄存器如下：
// SMMUv3 关键寄存器偏移
#define SMMU_CR0 0x0000 // 控制寄存器0
#define SMMU_CR0_SMMUEN (1 << 0) // SMMU使能位
#define SMMU_CR0_ATSCHK (1 << 4) // ATS检查使能
#define SMMU_GBPA 0x0044 // 全局错误处理
#define SMMU_GBPA_ABORT (1 << 20) // 中止所有事务
#define SMMU_STRTAB_BASE 0x0080 // STE表基地址
#define SMMU_CMD_BASE 0x0090 // 命令队列基地址
#define SMMU_EVTQ_BASE 0x00A0 // 事件队列基地址
你看，这些寄存器的命名都很直观。CR0是控制寄存器，GBPA是全局错误处理。我建议你拿到一个新平台的spec时，先找到这三个基地址寄存器——它们决定了IOMMU怎么找到配置表。
调试技巧：我曾经调试一个IOMMU问题，设备DMA总是超时。后来用devmem2直接读SMMU_GBPA寄存器，发现错误位被置位了。原来设备访问了未映射的地址，IOMMU直接abort了事务。嗯，这个经验告诉我：IOMMU的错误寄存器是第一排查对象。
6. 三种架构对比
最后，我用一个表格总结三种架构的异同：
| 特性 | Intel VT-d | AMD-Vi | ARM SMMUv3 |
|---|---|---|---|
| 设备表结构 | Root Entry + Context Entry | Device Table | Stream Table |
| 页表层级 | 4级 (PML4/PDP/PD/PT) | 3级或4级 | 可配置 (1-5级) |
| 中断重映射 | Interrupt Remapping Table | INTx/MSI Table | Event Queue + PRI |
| 进程级隔离 | 通过PASID (Scalable Mode) | 通过PASID (v2+) | 原生支持PASID |
| 典型应用 | x86服务器、桌面 | AMD服务器 | ARM服务器、移动设备 |
你发现没有？虽然三家实现不同，但核心思想一模一样：设备请求 → 查表 → 翻译地址 → 访问内存。说白了，就是给设备加了个"地址翻译器"。
好了，这一章的内容就到这里。记住：IOMMU不是魔法，它就是个硬件页表管理器。下一章我们会深入VT-d的页表结构，到时候我会带大家手写一个DMA重映射的示例。
可可精品资料库