| RFC-0249：平台中的 crosvm 支持 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 除了 qemu 和 femu 之外，此 RFC 还提倡将 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 的测试基础架构中启用对 Fuchsia 与 crosvm 的自动化测试。
还有一些设备由 crosvm 提供支持，但我们尚不支持其他模拟环境。
此外，我们需要让驱动程序开发者更轻松地编写和维护在基于 crosvm 的环境中使用的驱动程序。目前，这需要在以产品为导向的非树环境中运行 Fuchsia。这种方法无法扩展。
最后，我们的任何现有硬件目标都不支持某些技术，例如适用于 x86 的 64 位 Linux 启动协议。因此，由于无法进行测试，我们尚未实现具有此类支持的 Linux 启动 shim。
利益相关方
教员：
neelsa@google.com
Reviewers:
- 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 预构建滚动条
系统将设置一个新的构建器，以从上游 crosvm 代码库中提取最新的源代码，启用相关功能进行构建，然后将最终工件上传到 CIPD。
滚动器将负责更新集成代码库，以确保未来的 jiri update 命令会导致传送更新后的 crosvm 二进制文件。
支持将 crosvm 用作备用引擎的 ffx emu
我们将向 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 的构建器重新用于此目的。
这些构建器最初将是 FYI 构建器，但如果它们被证明是稳定的，我们可以将其更新为屏蔽构建器，就像创建新的屏蔽构建器的典型流程一样。
这些构建器是在 CI 还是 CQ 中运行，以及总共创建了多少个构建器，都超出了此提案的范围。
此外，我们还应尝试让 bringup.x64 构建器在 crosvm 上运行其启动测试，因为这会最大限度地减少潜在启动时 bug 的暴露面。
测试
我们必须在 CI 和/或 CQ 中运行的测试将仅限于以下用例：
- 重新启动和关机测试
- Zircon 内核测试
- 设备枚举测试，用于确保所有外围硬件都能正确枚举。
- 系统测试，用于确保外围设备驱动程序按预期运行。
值得注意的是，目前在 QEMU 上运行的密封测试无需在 crosvm 上重复运行。
在大多数情况下，我们可以通过在测试中显示的 tests_specs 中指定新环境来实现此测试细分。
重新启动和关闭测试目前作为主机测试运行，并且对 qemu 有硬依赖项，我们需要解决此问题。此外，这些测试无法在 arm64 机器人上运行，因此我们还需要解决此问题，以确保适当的测试覆盖率。
其他外围设备启动
除了启用 CI/CQ 聊天机器人所需的一组设备之外，我们还需要投资其他外围设备，以支持客户的用例。此提案不涵盖这些外围设备的完整集合。可以实现的一些可能外围设备包括：
- 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，我们会与相关团队一起确定优先级。
在先技术和参考文档
不适用。