RISC-V架构下外设虚拟化解决方案

2024-05-15 18:43:14 来源: 进迭时空
2023年07月25日,RISC-V IOMMU 扩展 1.0 版本 ratified。IOMMU 为 RISC-V 虚拟化架构补充了最后一块硬件实现外设虚拟化的拼图。
 
DMA 外设虚拟化的困境
 
当开启虚拟化启动 guest OS 后,guest OS 的 CPU 使用的内存地址是 guest 虚拟地址 (GVA),由 guest OS 配置的页表转换为 guest 物理地址 (GPA)。GPA 再经由 hypervisor OS 维护的页表,转换为实际物理地址(supervisor PA, SPA)。通过两级地址转换,guest OS 能够正常访问物理内存地址。
 
对于需要使用物理地址进行传输的 DMA 外设而言,由于 guest OS 配置 DMA 外设使用的是 GPA,甚至开启 DMA 重映射的 DMA 外设使用的是 GVA,无论 GVA 还是 GPA 都无法直接进行数据搬运。虽然可以让单个 guest OS 独占外设,使得 GPA = SPA,但这无法满足云厂商所需要的网络存储虚拟化应用场景的需求。而让 guest OS 获取 GPA -> SPA 的映射则会破坏虚拟机间隔离,使得恶意虚拟机可以通过 DMA 窃取其他虚拟机的内容,影响虚拟化系统的安全性。并且 hypervisor OS 即便捕获 guest OS 的 DMA 外设配置过程,也无法在 DMA 请求发起时不再参与 DMA 地址 GPA -> SPA 的转换。hypervisor OS 需要捕获 guest OS 的每一次 DMA 数据搬运传输,这在例如网络存储等场景下,会极大的降低外设虚拟化的处理性能。
 
RISC-V 架构下的解决方案
 
通用 DMA 外设的地址翻译解决方案
 
RISC-V 架构下引入了 IOMMU 来解决虚拟机中 DMA 传输性能问题。
 
首先,IOMMU 可以为每个 DMA 外设配置设备表(DDT)来提供 GPA -> SPA 地址翻译能力。接入 IOMMU 后,对上述 DMA 虚拟化问题,只需要 hypervisor OS 在 guest OS 配置 DMA 外设的同时配置设备的 GPA -> SPA 地址翻译,那么 DMA 数据搬运过程中就可以由 IOMMU 硬件自动进行 GPA -> SPA 的地址翻译,而不需要 hypervisor OS 捕获每一次 DMA 传输,高效地完成数据搬运。
 
其次,接入 IOMMU 后,由于经过 IOMMU 转译的 DMA 与 guest OS 的 CPU 使用相同的内存视图,可以配置 IOMMU 的进程表 (PDT)来与 CPU 共享同一份进程页表,使得 VU 的用户进程可以使用 DMA 直接传输。而对于开启了 IOVA -> GPA (IOVA 可以理解为虚拟机的 GVA)重映射的 DMA 外设(如 GPU),也可以通过配置 IOMMU 的进程表(PDT)的 IOVA -> GPA -> SPA 的两级地址翻译,来自动完成 DMA 重映射的地址翻译。
 
 
(图1 - IOMMU下的两级地址翻译  图源:进迭时空)
 
PCIe 外设的地址翻译(ATS)与缺页请求(PRI)解决方案
 
PCIe 标准组织为提高 PCIe 外设的效率,提出了设备侧(PCIe EP)地址翻译服务(Address Translation Service,ATS)的 PCIe 外设能力。有该能力的 PCIe 外设,能够通过 ATS 接口向设备翻译代理 TA(例如 IOMMU)发起地址翻译请求,并且维护地址翻译缓存(ATC),减少了多次查找页表(Page Table Walk,PTW)的性能损失。此外 PCIe 规范还允许设备侧(PCIe EP)发起缺页请求(Page Request Interface,PRI),来实现按需分配 IO 地址空间。
 
RISC-V 的 IOMMU 规范支持 PCIe 的 ATS 和 PRI 接口,甚至支持对翻译后地址的 ATS 翻译请求来支持 PCIe 外设的虚拟化。如下图所示,右侧为 RISC-V 的 IOMMU 对 PCIe 的 ATS/PRI 接口支持。
 
(图2 - IOMMU支持PCIe ATS/PRI架构   图源:进迭时空)
 
MSI 的解决方案
 
外设可以通过写 MSI 地址发送基于消息的中断,替代了传统的连线中断。即便在虚拟机中,每个虚拟外设的 MSI 地址也是外设独占的(即 GPA = SPA),操作系统因此提供特殊的 IOMMU 驱动接口以允许不同的 IOMMU 架构进行 MSI 地址翻译的优化。RISC-V架构下,使用 AIA 架构,通过 IMSIC 接收由 PCIe 或者 APLIC 的 MSI 写请求,将 MSI 中断直接递送到虚拟机,来完成中断虚拟化。由于不同的虚拟机外设使用的 MSI 写地址为该虚拟外设独占,不需要使用两级地址翻译,RISC-V IOMMU 架构为 MSI 写地址提供了仅进行 GPA -> SPA 地址翻译的独立 MSI 页表进行优化。
 
(图3 - IOMMU下的MSI的地址翻译   图源:进迭时空)
 
进迭时空 IOMMU 研发成果
 
IOMMU 是一个高度复杂的 IP,IOMMU 功能的正确实现不仅需要理解 RISC-V 的编程模型,还需要与现有的 PCIe 等 IP 的实现进行兼容。为了 IOMMU 的稳定交付,进迭时空在开发阶段,就使用了多种手段对 IOMMU 进行验证和兼容性测试,包括模块级的随机测试、基于 DPI-C 的参考模型比对和 Linux 驱动验证。目前进迭时空的 IOMMU 研发已取得重大进展,完成了所有功能包括所有虚拟化场景测试。
 
进迭时空 IOMMU 功能框架如下:
 
(图4 - 进迭时空 IOMMU 架构   图源:进迭时空)
 
进迭时空的 IOMMU 架构支持如下特性:
 
•支持 RV IOMMU Spec 1.0 要求的基础功能
 
•支持 PCIe ATS/PRI 相关功能
 
•支持 MSI_FLAT 类型 MSI 页表
 
•支持对接 IOPMP,支持进行 PMA 检查
 
•支持页表 Svpbmt, Svnapot 扩展
 
•访问设备/进程表和页表,队列等接口支持一致性访问
 
进迭时空 IOMMU 研发过程中深度参与社区的讨论,帮助完善了社区的 IOMMU 规范制定,其中部分发现的问题经过与社区的讨论已经得到社区确认,修正了社区 Spec 以及参考模型中的部分实现问题。
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/173
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/282
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/291
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/294
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/302
 
•https://github.com/riscv-non-isa/riscv-iommu/issues/303
 
后续进迭时空将会把 IOMMU 与支持 RVH, AIA 的 X100 核,组成完整的虚拟化系统,实现并形成完整的RISC-V虚拟化解决方案,完全满足用户对虚拟化场景的需求。
 
进迭时空2024年度产品发布会
明天 10:00
扫码观看 不见不散
 

 (图源:进迭时空)
责任编辑:sophie

相关文章

半导体行业观察
摩尔芯闻

热门评论