| RFC-0249：平台支持 crosvm | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 此 RFC 倡导将 crosvm 打造成 fuchsia 平台支持的一级模拟器以及 qemu 和 femu。 |
| 问题 | |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2024-04-24 |
| 审核日期（年-月-日） | 2024-05-31 |
摘要
本文档提议将 crosvm 添加为 Fuchsia 项目支持的系统配置。这样，我们就可以在 crosvm 上持续测试 Fuchsia，并将我们继续致力于让 crosvm 在 ToT 上正常运行的承诺。
设计初衷
根据其官方文档，crosvm 是一个托管式（也称为 type-2）虚拟机监控器，类似于 QEMU-KVM 或 VirtualBox。它支持多种架构（包括 x86_64 和 arm64），以及多个用于硬件加速的后端（包括 Linux KVM）。
有一些 Fuchsia 用户已经在基于 crosvm 的模拟器中采用了 Fuchsia，我们预计今后会有更多用户采用 crosvm。借助 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 上的 64 位 Linux 启动协议以及 aarch64。
- 我们必须支持 crosvm 的 Linux KVM 后端。建议使用其他后端。
- 驱动程序开发者应该可以轻松地针对编写驱动程序所针对的硬件的基于 crosvm 的实现来测试驱动程序。
设计
我们将向平台添加对 crosvm 的支持，具体方法是：以 CIPD 预构建的形式将其集成到 Fuchsia 结账中，添加对将 crosvm 启动到 ffx 的支持，最后设置要在提交前和/或提交后运行的相关聊天机器人。
实现
Bringup 和 64 位 Linux 启动 shim
为了引导对 crosvm 的引导，我们需要先让 Fuchsia 能够在 crosvm 上启动。crosvm 目前仅支持提供自定义引导加载程序或 64 位 Linux 启动协议。目前，Fuchsia 支持提供基于 EFI 的引导加载程序、多重启动和 32 位 Linux 启动协议。这组非交叉的启动选项可防止 Fuchsia 当前在 crosvm 上启动。因此，要支持 crosvm，第一步是为 crosvm 执行启动 activity，然后为 64 位启动协议实现另一个启动 shim。
值得注意的是，此问题仅存在于 x86 上。在 aarch64 下，Fuchsia 会在 crosvm 上启动。但是，由于 crosvm 默认仅支持硬件加速虚拟化，因此普通的 Fuchsia 开发者很难在 aarch64 下实际在 crosvm 上运行 Fuchsia。虽然我们已经证明 crosvm 在过去能够使用 arm64 Linux 启动 shim 启动 Fuchsia，但可能还需要执行额外的工作才能确保它继续启动。
除了启动填充码工作之外，您可能还需要为相关存储和网络驱动程序做一些工作，以确保设备支持 ffx 和基础架构。这项工作将在我们完成 bootshim 工作后揭示，并且将立即用于 x86_64。我们可能需要 crosvm 团队的支持，将其余所有必要的修复程序都植入到他们的代码中。
crosvm 预构建 Roller
将设置一个新的构建器，以从上游 crosvm 仓库中提取最新的源代码，在构建时启用相关功能，然后将最终工件上传到 CIPD。
滚轮将负责更新集成代码库，以确保未来的 jiri update 命令会导致传递更新后的 crosvm 二进制文件。
支持将 crosvm 作为替代引擎的 ffx EMU
ffx emu start --engine 标志将添加一个额外的选项，以使其能够选择 crosvm，而不是 qemu 或 femu。ffx emu 默认呈现给用户的一组特定设备将对齐，以便尽可能接近 crosvm 的树外用例。由于有多个用户使用 crosvm，这可能意味着我们需要支持多种设备配置。
虽然我们已经在 fx run-boot-test --crosvm 中提供了一些支持，但可以添加可选的 fx crosvm 命令封装容器以进一步简化此工作流。
CI/CQ 构建器
一旦平台能够在 crosvm 上启动 Fuchsia，我们将推出构建器，以确保 crosvm 支持继续按预期工作。
出于我们的目的，由于 minimum.x64 产品/开发板组合将适用于 crosvm，因此我们不需要另一个构建器，因为我们可以将构建器改作用于 qemu 的相同构建器。
最初，这些构建器将是供参考的构建器，但随着它们证明自己稳定，我们可以将其更新为阻塞构建器，正如创建新的阻塞构建器的典型流程一样。
这些构建器是在 CI 还是 CQ 中运行，以及总共创建的构建器数量超出此方案的范围。
此外，我们还应尝试让 renderup.x64 构建器在 crosvm 上运行启动测试，这样能够最大限度地减少潜在启动 bug 的表面积。
测试
我们必须在 CI 和/或 CQ 中运行的测试仅限于以下用例：
- 重新启动和关闭测试
- Zircon 核心测试
- 用于确保所有外设硬件正确枚举的设备枚举测试。
- 用于确保外设驱动程序按预期运行的系统测试。
值得注意的是，目前在 QEMU 上运行的封闭测试不需要在 crosvm 上重复运行。
在大多数情况下，我们可以通过依赖在测试显示的 Testing_specs 中指定新环境来完成此测试细分。
重新启动和关停测试目前作为主机测试运行，并且对 qemu 有硬性依赖，我们需要解决这一问题。此外，这些测试无法在 arm64 聊天机器人上运行，因此我们也需要修正此问题，以确保测试覆盖范围适当。
其他外围设备启动
除了启用 CI/CQ 机器人所需的一组设备之外，我们还需要投资购买其他外围设备，以支持我们的客户用例。这些外围设备的完整套件不在本方案的讨论范围内。可以实现的外围设备包括：
- virtio-gpu
- Virtio 气球
- 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 深度收费）方面的经验告诉我们，实现和维护特定于 Fuchsia 的启动支持可能并非易事。
这样做的另一个缺点是，它无法为我们提供 crosvm 的 Linux 启动支持，作为另一种根深蒂固的启动场景，我们现在可以测试这些场景并确保我们的兼容性。只要我们能够支持的 Linux/x86 和 Linux/arm64 启动协议的每个额外变体，未来在具有现成固件的其他开发板集上启动后将更加顺畅且更接近开箱即用状态，对于长期的“常规 x86 PC”机箱而言，这对于长期的“通用 x86 PC”机箱来说也是如此，这种机型历来都很有可能成为广泛公众采用新开源的操作系统。
未知
启动新的模拟器有很多未知因素，包括为了调试和解决当前不了解的问题而需要花费的工程时间。我们发现的 bug 可能需要内核、驱动程序或其他团队来完成之前未预算的额外工作，或者我们需要重新确定这项工作的优先级。如果发现 bug，我们将优先处理相关群组。
现有艺术和参考资料
不适用。