IOMMU如何处理PCIe ATS/ATC/PRI Request

本文讨论 PCIe 设备通过 IOMMU 访问主机内存时页表映射不存在或访问权限不足所引发的异常。通过分析 Linux 代码对比 Intel VT-d、AMD IOMMU 和 ARM SMMUv3 在三种 ATS/PRI 场景下的处理方式重点回答以下问题异常发生在 IOMMU Translation、ATS Translation 阶段还是 PRI Page Request 阶段异常发生时DMA Request 是否已经发出DMA Request 最终会被阻止、终止、重新发起还是继续执行1.简介下面总结了三种场景无 ATS/ATC设备直接发送 Untranslated DMA Request由 IOMMU 完成 Address Translation。有 ATS/ATC无 PRIATC 未命中后设备先发送 ATS Translation Request取得可用 Translation 后再发送 Translated DMA Request。有 ATS/ATC有 PRIATC 未命中后设备先发送 ATS Translation Request若 ATS Translation Completion 失败则发送 Page Request 请求主机 OS 分配缺失的内存页。2.结论场景Address Translation 路径异常现场DMA Request 是否发出异常处理方法DMA Request 是否可恢复无 ATS/ATC设备发送 Untranslated DMA Request由 IOMMU 执行 Address TranslationIOMMU 执行 Address Translation 时找不到有效页表项或者访问权限出错已经发出PCIe/RCIOMMU 阻止或终止 DMA Request。Memory Read Request 可能收到带错误状态的 CompletionUR/CA也可能最终发生 Completion Timeout具体由平台决定Memory Write Request 属于 Posted Request不会返回 Completion数据可能被丢弃并通过平台错误处理或 AER 上报。Intel VT-d写入 Fault Recording Register 并触发异常中断。AMD IOMMU在 Event Log 中写入IO_PAGE_FAULT并触发中断这是普通 Fault Event不是 PPR Log 中请求内存页的 Page Request。ARM SMMUv3写入 EVTQPCIe 总线不能暂停等待软件处理必须按 NoStall/Terminate 方式处理。DMA Request 通常不可恢复。该 Request 已经在 Translation 阶段失败。有 ATS/ATC无 PRIATC 未命中后设备先发送 ATS Translation RequestIOMMU 执行 Address Translation 时找不到有效页表项或者访问权限出错此使会返回带错误状态的 ATS Translation Completion未发出PCIe/设备ATS Translation Completion 未提供可用 Translation设备不能填充有效 ATC也不能发送对应的 Translated DMA Request通常会将队列或描述符置为失败或者稍后重新发起任务。Intel VT-dRequest 不进入 PRQ。AMD IOMMURequest 不进入 PPR Log。ARM SMMUv3Request 不进入 PRIQ。硬件即使另行记录也只是与实现相关的普通 Fault/Error不会触发 OS 缺页处理。没有发出 DMA Request。ATS Translation 失败后DMA Request 也会失败如果驱动在错误处理路径中另行建立映射并重新提交任务那也是新的 DMA Request不是恢复原 DMA Request。有 ATS/ATC有 PRIATS 未取得可用 Translation 后设备发送 Page RequestPage Request 进入 IOMMU 的专用队列Intel、AMD 将其上报为缺页异常 I/O Page FaultIOPF未发出PCIe/设备设备发送 Page Request并接收 Success、Invalid 或 Failure ResponseSuccess 后重试 ATSInvalid/Failure 时停止该访问。Intel VT-dPRQ → Linux IOPF → Page Group Response Descriptor。AMD IOMMUPPR Log → Linux IOPF →COMPLETE_PPR_REQUEST。ARM SMMUv3架构路径为 PRIQ/CMD_PRI_RESP当前 Linux 版本将该 Request 视为 Unexpected PRI Request 并返回 DENY。不是恢复一笔已经失败的 DMA Request而是在 DMA Request 发出前发送 Page Request 请求主机 OS 分配缺失的内存页。OS 处理成功后设备重发 ATS Translation Request收到正确的 ATS Translation Completion 后再发出 DMA Request。3.总结第一种场景是在IOMMU Translation 阶段产生普通 IOMMU Fault硬件记录错误并阻止或终止已发出的 Request。第二种场景没有 PRI也不进入 PRQ/PPR Log/PRIQ失败可能只反馈给设备不一定产生 Linux 可见的普通 IOMMU Fault。因此前两种场景都不会因该次失败而自动进入 OS 缺页处理流程。第三种场景具备进入可恢复缺页处理的硬件入口PCIe 设备发送 Page RequestIOMMU 将其放入专用 Page Request QueueIntel、AMD 驱动再将其作为 IOPF 交给 OSOS 进入缺页处理异常补齐页表后返回 Success。本文所用 ARM SMMUv3 驱动虽然能从 PRIQ 识别 PRI但当前直接返回 DENY不进入通用 IOPF。这里的“可恢复”特指能否在实际 DMA Request 发出之前通过 PRI 补齐映射使设备随后重新取得 ATS Translation 并发送 DMA Request。它不表示 IOMMU 能重试一笔已经失败的原始 DMA Request。下图比较三种场景的处理流程。蓝色表示设备 Request黄色表示 Address Translation 或软件处理绿色表示恢复成功红色表示失败或终止。