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

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 RequestTranslated 并不总是可直接放行是否仍需 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 walkPD8/PD17/PD20 决定有效位宽。- TTYPfault record 中的事务类型编码区分未翻译读、未翻译写、已翻译读写、ATS 请求和消息请求。- Priv/Exec/No-write权限检查输入不能在进入 page walker 前丢弃。可以把这些字段理解为硬件状态机的输入条件而不是软件文档里的静态表格。比如 EN_ATS 不只是一个功能开关它决定 Translated Request、ATS Translation Request 和 ATS invalidation completion 是否属于合法入站事务T2GPA 不只是返回值格式它会改变后续 Translated Request 是否还必须通过 G-stagePSCID/GSCID 不只是标识符它们决定 IOATC 项能否被复用以及失效命令能否做到精确。硬件行为主流程1. 解析 IO bridge 请求形成内部 request context。2. 根据 address type 选择 Untranslated、Translated 或 ATS Translation Request 路径。3. 读取 ddtp.iommu_modeOff 立即拒绝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 不能简单旁路 IOMMUT2GPA1 时它的地址是 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 T2GPA1。分别写出它们进入 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 类 faultPTE 权限不满足是 page faultG-stage 不满足是 guest page faultMSI 表项错误是 MSI PTE fault。把这些错误混成一个“translation failed”会让操作系统无法判断是驱动配置、guest 页表、hypervisor 映射还是硬件集成问题。