| RFC-0249：平台中的 crosvm 支持 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 此 RFC 建议除了 qemu 和 femu 之外，还应将 crosvm 作为受 Fuchsia 平台支持的一流模拟器。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2024-04-24 |
| 审核日期（年-月-日） | 2024-05-31 |
摘要
本文档建议将 crosvm 添加为 Fuchsia 项目支持的系统配置。这样一来，我们就能在 crosvm 上持续测试 Fuchsia，并兑现我们对保持 crosvm 在 ToT 正常运行的承诺。
设计初衷
根据其官方文档，crosvm 是一种托管（也称为 2 类）虚拟机监控器，类似于 QEMU-KVM 或 VirtualBox。它支持多种架构，包括 x86_64 和 arm64，以及多种硬件加速后端，包括 Linux KVM。
目前已有 Fuchsia 用户在基于 crosvm 的模拟器中使用 Fuchsia，我们预计随着时间的推移，会有更多用户这样做。借助 crosvm 支持，我们可以针对这些硬件的 crosvm 实现测试大量驱动程序。虽然我们已经支持 QEMU、FEMU、machina 和 GCE，以实现各种虚拟化设备，但每种实现方式都存在一些怪异之处，并且在其中任何一个模拟器环境中运行的软件都无法保证在另一个环境中也能正常运行。为了确保我们不会破坏 crosvm 的用户，我们需要在 Fuchsia 的测试基础架构中启用针对 crosvm 的 Fuchsia 自动化测试。
此外，crosvm 还支持一些其他模拟环境尚不支持的设备。
此外，我们还需要让驱动程序开发者更轻松地编写和维护在基于 crosvm 的环境中使用的驱动程序。目前，这需要在树外产品导向的环境中运行 Fuchsia。这种方法无法扩展。
最后，某些技术（例如 x86 的 64 位 Linux 启动协议）不受任何现有硬件目标平台支持。因此，我们尚未实现支持此类功能的 Linux 启动 shim，因为无法对其进行测试。
利益相关方
辅导员：
neelsa@google.com
审核者：
- cja@google.com
- jamesr@google.com
- mcgrathr@google.com
- olivernewman@google.com
- wittrock@google.com
已咨询：
列出应审核 RFC 但无需批准的人员。
- cpu@google.com
- costan@google.com
- diserovich@google.com
- wilkinsonclay@google.com
共同化：
此 RFC 已通过 Engprod 团队的设计审核。此外，在调查过程中，我们还联系了所有主要利益相关方。
要求
- 我们必须确信，我们不会破坏使用基于 crosvm 的模拟器的 Fuchsia 客户。
- 我们必须在 crosvm 中同时支持 x86_64 和 aarch64 架构。
- 我们必须在 x86_64 和 aarch64 上支持 64 位 Linux 启动协议。
- 我们必须支持 crosvm 的 Linux KVM 后端。其他后端会锦上添花。
- 驱动程序开发者应该能够轻松地针对其驱动程序所面向的硬件的基于 crosvm 的实现来测试其驱动程序。
设计
我们将通过以下方式将对 crosvm 的支持添加到平台：将其作为 CIPD 预构建项集成到 Fuchsia 代码库中，添加对向 ffx 启动 crosvm 的支持，然后最终设置相关机器人以在提交前和/或提交后运行。
实现
启动和 64 位 Linux 启动 shim
为了引导对 crosvm 的支持，我们需要先让 Fuchsia 在 crosvm 上启动。crosvm 目前仅支持提供自定义引导加载程序或 64 位 Linux 启动协议。Fuchsia 目前支持提供基于 EFI 的引导加载程序以及多重引导和 32 位 Linux 引导协议。这组不相交的启动选项可防止 Fuchsia 目前在 crosvm 上启动。因此，为了支持 crosvm，第一步是为 crosvm 进行启动活动，并为 64 位启动协议实现另一个启动 shim。
值得一提的是，此问题仅存在于 x86 上。Fuchsia 可以在 aarch64 下的 crosvm 上启动。不过，由于 crosvm 默认仅支持硬件加速虚拟化，因此普通 Fuchsia 开发者很难在 aarch64 下的 crosvm 上实际运行 Fuchsia。虽然我们之前已证明 crosvm 能够使用 arm64 Linux 启动 shim 启动 Fuchsia，但可能还需要进行额外的工作，以确保它能够继续启动。
除了启动 shim 工作之外，可能还需要对相关的存储和网络驱动程序进行一些工作，以确保设备能够与 ffx 和基础架构配合使用。在完成 bootshim 工作后，此问题将得到解决，该工作即将登陆 x86_64。我们可能需要 crosvm 团队的支持，才能在他们的代码中实现所有剩余的必要修复。
crosvm 预构建的滚动器
将设置一个新的 build，以从上游 crosvm 代码库拉取最新源代码，启用相关功能来构建它，然后将最终制品上传到 CIPD。
滚动更新者将负责更新集成代码库，以确保未来的 jiri update 命令能够交付更新后的 crosvm 二进制文件。
ffx emu 支持 crosvm 作为替代引擎
将向 ffx emu start --engine 标志添加一个额外的选项，以使其能够选择 crosvm 而不是 qemu 或 femu。ffx emu 将默认向用户呈现的特定设备集将尽可能与 crosvm 的实际树外使用情形保持一致。由于 crosvm 有多个用户，这可能意味着我们需要支持多种设备配置。
可以添加可选的 fx crosvm 命令封装容器来进一步简化此工作流程，不过 fx run-boot-test --crosvm 中已提供一些支持。
CI/CQ 构建器
一旦平台能够在 crosvm 上启动 Fuchsia，我们将引入构建器，以确保 crosvm 支持继续按预期运行。
就我们的目的而言，由于 minimal.x64 产品/主板组合可与 crosvm 搭配使用，因此我们无需其他构建器，因为我们可以将用于 qemu 的构建器重新用于 crosvm。
最初，这些 build 将是 FYI build，但随着它们被证明稳定，我们可以将其更新为阻塞 build，这是创建新的阻塞 build 的典型流程。
这些构建器是在 CI 还是 CQ 中运行，以及总共创建了多少构建器，不在本提案的讨论范围内。
此外，我们还应尝试让 bringup.x64 构建器在 crosvm 上运行其启动测试，因为这样可以最大限度地减少潜在的启动时 bug 的影响范围。
测试
我们必须在 CI 和/或 CQ 中运行的测试将仅限于以下使用情形：
- 重新启动和关机测试
- Zircon 核心测试
- 设备枚举测试，可确保所有外围硬件正确枚举。
- 系统测试，确保外围设备驱动程序按预期运行。
值得注意的是，目前在 QEMU 上运行的封闭测试无需在 crosvm 上重复运行。
在大多数情况下，我们可以通过在测试中显示的 tests_specs 中指定新环境来完成此测试细分。
重新启动和关机测试目前作为主机测试运行，并且对 qemu 有硬依赖关系，我们需要解决此问题。此外，这些测试无法在 arm64 bot 上运行，因此我们还需要解决该问题，以确保适当的测试覆盖率。
其他外围设备启动
除了启用 CI/CQ bot 所需的设备之外，我们还需要投资购买其他外围设备，以支持客户的使用情形。这些外围设备的完整集不在本提案的范围内。可能实现的某些外围设备包括：
- virtio-gpu
- virtio-balloon
- cmos-rtc
性能
我们应确保 Fuchsia 不仅在 crosvm 上正常运行，而且性能出色。如果启动速度较慢，或者 virtio 驱动程序在负载下占用过多的 CPU，我们需要进行一些分析和优化工作，以确保满足使用 crosvm 的客户的性能需求。
工效学设计
此提案将使驱动程序开发者能够更轻松地针对驱动程序所针对的硬件的 crosvm 实现来测试其驱动程序。
向后兼容性
不适用。
安全注意事项
不适用。
隐私注意事项
不适用。
测试
此提案旨在向平台添加 crosvm 支持，并向 CI/CQ 添加相关的自动化测试覆盖率。
文档
应更新 ffx emu 的文档，以反映对 crosvm 引擎的新支持。此外，还应创建一个新的支持的模拟器页面，以介绍对 crosvm 的新支持。
缺点、替代方案和未知因素
替代方案：不执行任何操作，继续使用现有模拟器作为支持的代理
最简单的做法是不做任何事情，依靠 qemu 和/或 femu 来帮助确保我们的 virtio 驱动程序继续按预期工作，并在需要时在 crosvm 上进行手动测试。如果采用此选项，我们对 crosvm 支持不会中断 OOT 用户的信心会非常低，但由于现有模拟器应与 crosvm 共享大部分行为，因此中断情况可能很少见。
替代方案：尝试让 crosvm 正式支持 Fuchsia
其他操作系统不会特意支持 crosvm。相反，crosvm 会尝试直接支持这些操作系统，方法是使其行为与这些操作系统中的现有驱动程序相匹配。我们或许可以请求 crosvm 以相同的方式支持 Fuchsia。不过，从根本上讲，Fuchsia 的目标受众比其他主要操作系统小得多，因此很难真正说服 crosvm 自行承担此类支持。
我们使用供应商启动固件（甚至是开源固件，如 CrOS depthcharge）的经验表明，要实现和维护可靠的 Fuchsia 特定启动支持可能非常困难。
这种方法的另一个缺点是，它没有为我们提供 crosvm 的 Linux 启动支持，而这正是我们现在可以测试并确保兼容性的另一种根深蒂固的启动场景。我们支持的 Linux/x86 和 Linux/arm64 启动协议的每一种额外变体，都使得未来在具有出厂固件的其他组板上顺利启动的可能性更高，更接近开箱即用，对于长期“通用 x86 PC”情况也是如此，从历史上看，这是新开源操作系统被更广泛的公众采用的最可能载体。
未知
在启动新模拟器时，存在许多未知因素，包括我们需要花费多少工程时间来调试和解决我们目前尚不了解的问题。我们发现的 bug 可能需要内核、驱动程序或其他团队投入额外的、之前未纳入预算的工作，或者我们需要重新确定此工作的优先级。如果我们发现 bug，会与相关团队确定优先级。
在先技术和参考资料
不适用。