LWN：为什么RISC-V尚未支持KVM？

关注了就能看到更多这么棒的文章哦～

Why RISC-V doesn't (yet) support KVM

By Jonathan Corbet
May 20, 2021
DeepL assisted translation
https://lwn.net/Articles/856685/

近年来 RISC-V CPU 架构的地位日益突出。其相对开放的性质使其成为一个有吸引力的平台，许多公司都在此基础上开发了产品。Linux 很好地支持了 RISC-V，但有一个缺陷：一直没能支持 KVM 虚拟化，尽管其实有了质量很不错的实现代码了。最近一次人们尝试增加这个功能支持的时候，人们从中看到了 RISC-V 生态系统有些地方似乎并不像人们希望的那样能良好运作。

Linux 支持许多虚拟化机制，但 KVM 通常被视为缺省解决方案（native solution）。它提供了跨系统的一套标准接口，但 KVM 中大部分内容一定是跟特定架构相关的，因为具体的虚拟化支持机制在不同类型的处理器上都各不相同。因此，支持 KVM 的架构里一般都有一个 kvm 目录，跟此架构中的其他那些架构相关代码放在一起。

鉴于此，当 Anup Patel 的 patch set 在增加对 RISC-V KVM 的支持并将这些特定架构相关代码存放在 staging 目录中时，有些开发者的眉头就皱了起来。staging 目录通常用于存放那些不符合内核代码质量标准的设备驱动。如果一切顺利得到改进的话，就会最终 "毕业" 离开 staging 目录。它通常不用来放置架构相关的代码。所以 staging 目录的维护者 Greg Kroah-Hartman 很快就回复邮件，询问为什么要这样做。

原因其实是来自 RISC-V 代码的 patch 接受政策，可在 Documentation/riscv/patch-acceptance.rst 中找到，内容如下：

我们只接受跟新的 module 或 extension 有关的 patch，并且前提是这些 module 或 extension 的规范（specification）被 RISC-V 基金会列为 "Frozen（冻结）" 或 "Ratified（批准）"。当然，开发者可以维护他们自己的 Linux 内核代码库，其中可以存放包含了想要使用的任何 draft extension 相关的代码）。

RISC-V 的虚拟化是由 hypervisor extension 这个规范进行定义的。Patel 解释说，这个 extension 还没有得到批准：

KVM RISC-V 的 patch 已经在等待了将近 2 年了。人们不断调整 RISC-V H-extension（hypervisor extension）的冻结时间，我们无法确定它何时会被冻结。事实上，很多人已经在硬件里面实现了 RISC-V H-extension，KVM RISC-V 在这些真正存在的硬件上也可以正常使用。

将 KVM RISC-V 转移到 drivers/staging 的话，在 RISC-V H-extension 被冻结之前，就可以继续进行 KVM RISC-V 的开发，同时也不会破坏 Linux RISC-V patch 接受政策。

Kroah-Hartman 对此不以为然。他表示，staging 目录不是用来规避内核代码库中其他模块的一些自己政策的，所以 RISC-V KVM 代码不能合入 staging。KVM 的总体维护者 Paolo Bonzini 补充说，从开发者不得不绕过这个政策的事实中就可以看出，"RISC-V 的 patch 接受政策是行不通的"。他说，尤其来说对于 RISC-V 的 KVM 实现是一个更加不幸的事情，因为这组 KVM 代码 "质量很高，展示了如何正确地实现代码"。他还说道，可能有一些参与者会喜欢拖慢 patch 合入内核的速度，从中获益。

Kroah-Hartman 回应说，拖慢合入有用代码，这是 "可怕的" 做法，内核社区的工作目标是能让硬件工作起来，而阻止合并那些能很好支持现有硬件的代码的政策是没有意义的。他要求 RISC-V 的维护者解释这个政策，目前他们还没有回答。不过，早在 4 月份的时候 RISC-V 的维护者 Palmer Dabbelt 就承认，这个 patch 接受政策并没有达到预期的效果：

我在 RISC-V 方面的目标一直是致力于推动真正的产品出货，并且是运行一套尽可能接近上游代码库的 software stack。我认为这是让 software stack 实现可持续的维护的唯一途径。这种 “只接受达到冻结状态的 extension" 的政策是为了帮助实现这一目标，引导供应商共同建立一套我们可以支持的共同代码，但实践下来，这并没有奏效。

他补充说，这个政策可能会改变，但需要先确认出能让大家达成一致都同意的新的 patch 接受政策时才能改。不过，联合维护者（co-maintainer） Paul Walmsley 把责任归咎于 RISC-V 组织的 specification 规范决定流程，认为真正需要改变的是这个规范流程。

其实不难理解为什么 RISC-V 的维护者不愿意去支持所有各种非标准的 CPU。RISC-V 的开放性使得任何人都可以比较容易地创建他们自己的变体，而支持这些全部变种最终是不可行的。反过来说，正如 Kroah-Hartman 所说，内核的目标是要在现有的硬件上正常运行。所以阻止支持那些已经在售卖的系统的话，只会把这些系统的用户推向由供应商专门提供的内核版本，其中会包含很多非 Linux kernel 官方的代码，这对于一个本应是开放的架构来说是非常不幸的结果。

尤其是这里在讨论的是像虚拟化这样的基本功能都无法得到支持，因此这个问题变得更加紧迫。希望这个插曲能使得 RISC-V 架构的 patch 接受政策进行调整。否则的话，Kroah-Hartman 已经表明如果没有其他选择的话，他愿意接受这些代码合入 staging。因此，Linux 应该还是会较短时间内就能让 KVM 支持 RISC-V，尽管这可能需要绕过该架构的维护者。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～