这里ATC存的是经过IOMMU翻译的GPA->HAP映射项，还是经过SMMU翻译的GPA->HAP映射项?
1. 核心概念与分工
- IOMMU（CPU端） ：在x86虚拟化环境中，IOMMU（如Intel VT-d）的核心作用是将虚拟机物理地址（GPA）转换为主机物理地址（HPA，即你提到的HAP）。这是虚拟机和主机之间地址隔离与转换的关键硬件单元。
- SMMU（显卡端） ：SMMU是显卡内部的内存管理单元，它负责的是GPU虚拟地址（GVA）到GPA的转换，或者设备IOVA到GPA的转换，属于显卡内部的地址翻译。
- ATC（Address Translation Cache）：这是PCIe设备（如显卡）内部的缓存，用于存储地址转换结果，以减少对IOMMU的重复查询，提升性能。
2. 地址转换流程
当显卡的VDMA发起DMA请求时，它使用的地址是GPA（虚拟机物理地址）。这个GPA需要通过PCIe接口发送到CPU端的IOMMU，由IOMMU完成GPA → HPA的转换。
根据PCIe的ATS（Address Translation Services）机制：
- 如果ATC中没有对应的映射项，显卡会向CPU端的IOMMU发送地址转换请求。
- IOMMU完成转换后，将GPA→HPA的映射结果返回给显卡。
- 显卡收到结果后，会将这个映射项缓存到ATC中，后续相同地址的DMA请求就可以直接从ATC获取HPA，无需再请求IOMMU。
3. 结论
因此，图中的ATC存储的是经过IOMMU翻译的**GPA→HAP（HPA）**映射项。
GPA到HPA的映射关系变了，如何更新ATC中内容?
- 是的，这种情况是完全存在的，而且是 PCIe ATS（Address Translation Services）机制中至关重要的一环。当 GPA 到 HPA 的映射关系发生变化时，系统会主动触发 ATC 的更新，以确保地址转换的正确性和安全性。
触发 ATC 更新的核心机制
- PCIe ATS 协议定义了 Invalidate Request（失效请求） 机制，专门用于处理映射关系变化时的 ATC 缓存一致性问题：
- 当 VMM（虚拟机监控器）或操作系统修改了 IOMMU 中的 GPA→HPA 映射表（例如虚拟机迁移、内存热插拔、页表更新等场景），会通过 IOMMU 向 PCIe 设备（如显卡）发送Invalidate Request。
- 设备收到该请求后，会立即更新 ATC：将旧的 GPA→HPA 映射项标记为无效或直接删除。
当设备后续再发起该 GPA 的 DMA 请求时，会发现 ATC 中没有有效映射，从而重新向 IOMMU 发起地址转换请求，获取新的映射关系并缓存到 ATC 中。
详细的更新ATC流程
这个过程是软件介入触发+硬件执行传输与响应的协同结果，并非单一硬件或软件能独立完成，具体分工如下：
- 软件必须介入：触发失效请求的发起
当 VMM / 操作系统修改了 IOMMU 中的 GPA→HPA 映射表后，软件需要主动触发失效流程，因为硬件无法自动感知页表的修改：- 配置 IOMMU 寄存器：VMM/OS 会通过写 IOMMU 的专用寄存器（如 Intel VT-d 的 PASID 表寄存器、AMD-Vi 的 IOMMU 命令寄存器），明确告知 IOMMU 哪些 GPA 对应的映射项发生了变化，需要向 PCIe 设备发送失效请求。
- 指定目标设备与地址范围：软件需要提供目标 PCIe 设备的标识（如 BDF 号）和需要失效的 GPA 范围，让 IOMMU 知道向谁发送、失效哪些映射。
- 场景关联：例如虚拟机迁移时，VMM 作为软件会主动协调 IOMMU 对所有关联设备发送失效请求；页表更新时，OS 内核驱动会触发 IOMMU 的失效指令。
- 硬件负责执行：发送与响应失效请求
在软件触发后，硬件会完成总线传输和设备端的缓存更新：- IOMMU 硬件生成 Invalidate Request：IOMMU 收到软件的配置后，会通过 PCIe 总线向目标设备发送 Invalid Request TLP（事务层数据包），这是纯硬件层面的总线操作，无需软件干预。
- PCIe 设备硬件更新 ATC：显卡等设备收到 Invalid Request 后，其硬件逻辑会直接更新 ATC（如标记旧映射项为无效、删除缓存条目），确保后续 DMA 请求不会使用过期的 GPA→HPA 映射。