VFIO-平台设备直通：内核与QEMU集成指南及未来展望

KVM Forum

VFIO-平台历史与现状 [00:00:47]

VFIO-平台驱动程序和QEMU集成在2015年被引入，但自2017年以来，设备集成方面的上游贡献显著减少。

• 10周年纪念与初期努力 (2014-2015) [00:00:50]
  • 10年前，VFIO-平台是热门话题，在LPC和KVM论坛上有很多演讲。
  • 主要ARM厂商如AMD表现出浓厚兴趣。
  • 2015年，VFIO-平台驱动程序和QEMU VFIO平台设备被上游化。
  • 最早集成了两个10GB以太网设备。
• 发展停滞 (2017年之后) [00:01:45]
  • 最后一个集成的设备是2017年的Broadcom FlexRM邮箱。
  • 最后的内核功能贡献是2018年与Renesas R-Car Gen3平台相关的实验性工作。
  • VFIO-平台仍在被使用（有内部启用请求），但缺乏透明的上游贡献。
  • 由于旧系统报废，现已难以使用上游代码进行测试，导致维护问题。
  • 讲者被迫重新开始集成新设备以进行CVE相关测试。

目标 [00:03:44]

• 提醒VFIO-平台的存在。
• 解释其用途和不适用的场景。
• 阐明如何支持新设备。
• 帮助参会者理解设备集成的主要挑战，并判断一个设备是否适合VFIO-平台集成。
• 开启关于VFIO-平台未来的讨论。

VFIO-平台用途 [00:04:57]

• 核心功能 [00:05:00]
  • 为用户空间提供对物理平台设备的控制，原理与VFIO PCI类似。
  • 前提条件: 需要底层物理IOMMU，因为其重用IOMMU组、容器等概念。
  • 通常用于DMA兼容设备，否则收益不大。
  • 用户API提供对设备寄存器的直接访问、中断处理和DMA缓冲区到用户虚拟地址的映射能力。
• 用例 [00:06:15]
  • 编写用户空间驱动程序而非原生内核驱动，通常针对DPDK等用例。
  • 将VFIO平台设备分配给客户机（更高级的用例，QEMU框架支持）。
• 硬件平台 [00:06:46]
  • 主要支持ARM架构。
  • 目标是嵌入式、汽车和边缘平台，而非服务器（服务器更倾向于PCI设备分配）。
  • 特别针对没有PCI访问权限的SoC，但如Nvidia Jetson Orin系统，即使有PCI，也可暴露平台设备。

如何支持新设备？设备重置 [00:07:26]

目前，内核和QEMU层面仅官方支持3个设备，且都相对陈旧。与VFIO PCI不同，VFIO-平台需要针对新设备进行内核和VMM层面的适配。

• 设备重置的需求与问题 [00:08:28]
  • 需求: 当设备分配给客户机或用户空间驱动程序时，需要能够重置它。
    • 虚拟机崩溃可能导致IOMMU映射被破坏，若不重置设备，后续VM启动时DMA请求可能危及新VM的内存完整性。
    • 必须停止DMA传输，禁用中断，并在必要时获取/释放动态资源。
  • 问题: 平台设备重置没有标准规范，可以通过寄存器、重置引脚等多种方式实现。
  • VFIO-平台驱动程序本身是设备无关的。
  • 实现方案:
    • 对于ACPI引导，可使用RST方法（FlexRM邮箱已有示例）。
    • 对于DT引导，使用内核中的自定义重置模块。
• 内核重置模块 - 基础 [00:11:06]
  • 现有的内核重置模块基础设施。
  • 新的重置模块会根据设备的兼容性字符串在设备附加时自动加载。
  • 重置方法在设备打开/关闭和VFIO_DEVICE_RESET ioctl时由主VFIO-平台驱动调用。
  • 示例可在drivers/vfio/platform/reset/目录下找到。
  • 挑战 [00:12:00]
    • 需要设备驱动和/或设备知识来理解如何重置设备。
    • 现有示例通常只涉及寄存器读写来启用/禁用中断和DMA。
    • 更复杂的设备可能需要动态资源（如时钟、重置），这并非现有实现所能覆盖。
• 内核重置模块 - Tegra234 mgbe [00:12:51]
  • Tegra 234多千兆位以太网控制器是Nvidia Jetson Orin板上的设备，是一个更复杂的示例。
  • 它需要动态资源：时钟和重置。
  • 为此，需要增强现有的单一重置功能，添加两个新的回调函数：
    • init：在初始化时调用，用于获取和准备时钟及重置资源。
    • release：在释放时调用，用于释放资源。
  • 这有望允许集成需要动态资源的新型复杂设备。

向客户机暴露设备：QEMU集成 [00:14:38]

如果目标是将设备暴露给客户机，除了内核层面的适配，还需要在VMM（QEMU）层面进行适配。

• QEMU魔术与DT节点生成 [00:14:55]
  • 平台设备没有PCI那样总线枚举机制。
  • 需要在QEMU中编写描述设备（通过ACPI或设备树）的代码。
  • 当通过device vfio-platform,host=<address>选项传递给QEMU时，QEMU会使用动态系统总线实例化。
    • 它创建平台总线并连接VFIO平台设备（MMIO和中断）。
    • QEMU对象拓扑的连接是透明的，无需用户关心。
  • 设备树(DT)节点生成：这是设备特定的，代码位于hw/core/system_fdt.c。
    • 绑定结构: 将兼容性字符串与设备节点创建函数关联起来。
    • QEMU根据要附加的设备获取兼容性字符串，然后调用相应的函数创建设备树表示。
• Calxeda,hb-xgmac 示例 [00:17:19]

  

  • 第一个集成的设备，其设备树节点非常简单，只有四个属性：reg（寄存器）、interrupts（中断）、compatible（兼容性字符串）和dma-coherent（DMA一致性）。
  • QEMU通过辅助函数获取主机端的地址、区域大小和SPI中断信息，从而在客户机端构建相似的设备树节点。
  • 这是VFIO-平台友好的设备，集成相对简单。
• AMD,xgbe-seattle-v1a 示例 [00:18:35]

  

  • 包含大量设备特定属性，需要从主机复制值到客户机设备树节点。
  • 需要理解这些属性的含义（通过绑定描述文档），这比PCI设备复杂。
  • 额外挑战：处理clocks属性。
    • 涉及到外部时钟节点引用，需要在客户机端生成这些节点。
    • 幸运的是，这些时钟是固定的，可以直接复制主机端的节点。
• NVIDIA,tegra234-mgbe 示例 [00:20:17]

  

  • 复杂程度显著增加，除了常规属性，还包括resets、interconnects、power-domains、firmware-handle和mdio子设备等。
  • 实验性地移除了一些非强制性的属性（如interconnects、power-domains、firmware-handle、mdio）。
  • 重置 (reset) 是非可选的。
    • 若不在客户机端暴露重置，设备将无法探测。
    • 这需要生成一个重置控制器DT节点在客户机端。
    • 该设备引用的bpmp（Board Power Management Processor）是一个专门管理资源（重置、时钟、电源等）的IP。
    • bpmp无法直接暴露给客户机，因为它会引入邮件盒等其他依赖，需要仿真。
    • 唯一的解决方案是使用i2c_hid_reset控制器，但它也有自己的系统依赖。
  • 这项技术暴露了局限性：如果客户机尝试使用这些由QEMU伪造的资源，可能会产生后果。
  • 客户机视角下的Tegra234 [00:23:04]

    

    • 展示了客户机端必须暴露的完整设备树表示，其复杂性令人担忧。

结论 [00:23:24]

• 当前障碍：
  • 不存在对DMA控制器使用情况的IOMMU，如GPIO控制器，将被拒绝。
  • 如果客户机DT节点存根不足，将无法工作，可能需要仿真。
  • 共享资源问题：如果设备与主机使用的其他设备共享重置资源，会引发问题。
• 麻烦之处：
  • 动态资源管理（重置、时钟、电源域等）可能带来麻烦，但新的重置模块扩展应能解决大部分问题。
  • 在客户机端生成DT节点存根是复杂且存在问题的。
• 建议：
  • 设备架构师和原生驱动维护者应将VFIO-平台用例纳入考虑。
  • 重置和DT生成需要深入的设备知识。
  • 虚拟函数（Virtual Functions）将大大简化事情，减少对外部资源提供者的依赖，物理功能将处理这些依赖，从而简化客户机端的设备描述。这是VFIO-平台未来的关键。

讨论 [00:25:49]

• 市场需求：VFIO-平台是否存在真正的市场需求？
  • 尽管存在客户，但他们的具体需求和使用方式尚不明确。
• 上游贡献的重要性：
  • 呼吁用户透明地公开其使用情况，并至少贡献重置驱动程序。
  • 如果没有新的集成设备，驱动程序有被弃用的高风险，因为当前维护者已无法使用上游代码进行测试。
  • 讲者表示愿意帮助新的设备集成，前提是有真正的市场需求。
• 讨论结果：与会者表示，如果缺乏实际需求，可以考虑删除VFIO-平台代码，鼓励有需求的用户作为新的维护者，并按照现代化接口重新提交。这似乎是未来计划的一部分。