RISC-V IOMMU｜第02天：SoC 接口、请求类型与身份模型

今日目标

今天聚焦 IOMMU 的外部接口：设备请求如何进入、IOMMU 如何识别设备和进程、不同地址类型如何影响后续路径。后续所有 DDT/PDT/ATS/PRI/MSI 机制都建立在这个入口模型上。

读完这篇文章，你应该能把本主题放回完整 IOMMU 数据流里：设备请求从 IO bridge 进入，经过设备身份识别、上下文定位、地址翻译、权限检查、缓存命中或 page walk，最后返回可访问的系统物理地址，或者通过 fault queue 把错误精确报告给软件。本文不假设读者已经打开规范或代码仓库，所有必要术语会在正文里展开。

为什么它对硬件设计重要

IOMMU 不是单纯的地址加法器，也不是只负责页表 walk 的外设。它处在设备和内存系统之间，一边面对 PCIe/CXL/片上 DMA master 等并发请求，另一边自己还要作为 bus master 读取 DDT、PDT、页表、命令队列、故障队列、MSI 表和 MRIF。硬件设计如果只看“输入 IOVA、输出 SPA”的理想路径，会漏掉三个关键问题：第一，配置结构可能不存在、无效或被软件并发修改；第二，翻译本身会产生隐式内存访问，这些访问也可能 fault；第三，虚拟化和 ATS/PRI 会把设备、进程、虚拟机三个维度交织在同一条流水线里。

核心概念

- IOMMU 的设备侧入口接收 DMA read/write/AMO、ATS Translation Request、ATS Invalidation Completion、PRI Page Request 和 MSI write。

- 入站请求至少携带 device_id、地址、读写执行属性；可选携带 process_id、privilege、no-write、execute intent 等属性。

- 地址类型分为 Untranslated、Translated、ATS Translation Request；Translated 并不总是可直接放行，是否仍需 G-stage 取决于 T2GPA。

- device_id 是硬件观察到的设备身份，最多 24 位；PCIe 系统可由 RID 加 DSEG 映射得到。

- process_id 是可选的进程身份，最多 20 位；PCIe 语境下通常对应 PASID。

- PV/PSCV/GV 分别描述 process_id、第一阶段地址空间、第二阶段地址空间是否参与本次翻译。

这些概念之间不是并列关系，而是有严格的先后依赖。通常先由 `ddtp` 决定 IOMMU 是否开启以及 DDT 有几级；再由 `device_id` walk 到 Device Context；如果请求携带 `process_id` 且 DC 使用 PDT，则继续 walk 到 Process Context；之后才进入第一阶段和第二阶段地址翻译。任何一步失败，都不能靠后续阶段“补救”，必须在对应位置产生精确 fault 或拒绝事务。

关键字段和结构图示

- device_id：最多 24 位，用于 DDT walk；硬件应在 DDT 级数不足时检查高位是否为 0。

- process_id：最多 20 位，用于 PDT walk；PD8/PD17/PD20 决定有效位宽。

- TTYP：fault record 中的事务类型编码，区分未翻译读、未翻译写、已翻译读写、ATS 请求和消息请求。

- Priv/Exec/No-write：权限检查输入，不能在进入 page walker 前丢弃。

可以把这些字段理解为硬件状态机的输入条件，而不是软件文档里的静态表格。比如 `EN_ATS` 不只是一个功能开关，它决定 Translated Request、ATS Translation Request 和 ATS invalidation completion 是否属于合法入站事务；`T2GPA` 不只是返回值格式，它会改变后续 Translated Request 是否还必须通过 G-stage；`PSCID/GSCID` 不只是标识符，它们决定 IOATC 项能否被复用以及失效命令能否做到精确。

硬件行为主流程

1. 解析 IO bridge 请求，形成内部 request context。

2. 根据 address type 选择 Untranslated、Translated 或 ATS Translation Request 路径。

3. 读取 ddtp.iommu_mode；Off 立即拒绝，Bare 只允许有限事务，DDT 模式进入上下文查找。

4. 检查 DID/PID 位宽是否与当前 DDT/PDT 模式兼容。

5. 把 DID、PID、TTYP、privilege、IOVA 一直携带到响应或 fault writer。

实现时建议把流程拆成“快速命中路径”和“慢速 walk 路径”。快速路径处理已缓存的 DC、PC 和 IOTLB 项；慢速路径负责读内存结构、处理 access fault、更新 A/D 位、生成 fault record。两条路径必须共享同一套权限和 fault 判定规则，否则缓存命中与缓存未命中的行为会不一致。

设计取舍与微架构建议

- 入口流水线应尽早分类事务类型，以便非法事务不占用 page walker。

- DID/PID 宽度检查建议放在 DDT/PDT walk 前，减少无效内存访问。

- request context 中保留原始 IOVA 和事务类型，便于 fault record 的 iotval/TTYP 精确。

- Translated Request 不能简单旁路 IOMMU；T2GPA=1 时它的地址是 GPA，仍需 G-stage。

微架构上最容易被低估的是队列、walker 和缓存之间的反压关系。命令队列可能要求失效 IOATC；翻译流水线可能正持有旧缓存项；fault writer 又可能因为 fault queue 满而无法记录错误。一个稳妥的设计会把“接收设备请求”和“提交最终响应”分开，用内部 request context 保存 DID、PID、IOVA、请求类型、权限位和 fault 候选信息，这样即使中途经历多个内存访问，也能在失败时写出完整 fault record。

常见误区

- 把 Translated Request 等同于“安全物理地址”是错误的。

- 忽略 process_id valid 位会导致无 PASID 请求错误地使用随机 PID。

- 把 ATS Translation Request 当普通 DMA 读处理，会错误地产生内存访问而不是翻译完成。

自测与练习

给出三个请求：普通 DMA write、ATS Translation Request、Translated write with T2GPA=1。分别写出它们进入 IOMMU 后是否需要 DDT、PDT、第一阶段、第二阶段，并说明原因。

建议你在纸上画两张图。第一张画“成功路径”：Untranslated DMA write 从 device_id 到 DC，再到 PC、页表、IOATC fill，最后返回 SPA。第二张画“失败路径”：PDT 非叶项 reserved 位非零时，哪些字段进入 fault record，设备侧收到什么 completion 状态，软件如何从 fault queue 定位问题。能画出这两张图，就说明你已经不只是记住了字段名，而是在按硬件动作理解规范。

掌握要点

- 能解释 IOMMU 入口为什么必须保存 DID/PID/TTYP。

- 能区分 Untranslated、Translated、ATS Translation Request 的硬件含义。

- 能判断 T2GPA 对 Translated Request 路径的影响。

场景推演

假设一个支持 PASID 的设备发出一次写请求。若该请求没有携带 process_id，硬件首先要看 DC 是否允许默认 process_id；若请求携带 process_id，硬件要检查 PDT 模式是否覆盖该 PID 的位宽。随后，第一阶段页表会决定 IOVA 是否属于进程允许的虚拟页；第二阶段页表会决定对应 GPA 是否属于该 VM 被 hypervisor 分配的物理内存。只有两个阶段都成功，且权限、A/D 位、内存属性都满足要求时，IO bridge 才能接收最终 SPA。

如果中途失败，不同失败点必须给出不同软件可观测结果：设备上下文不存在是 DDT 类 fault，进程上下文不存在是 PDT 类 fault，PTE 权限不满足是 page fault，G-stage 不满足是 guest page fault，MSI 表项错误是 MSI PTE fault。把这些错误混成一个“translation failed”会让操作系统无法判断是驱动配置、guest 页表、hypervisor 映射还是硬件集成问题。