LWN:为什么RISC-V尚未支持KVM?

Linux News搬运工

共 2776字,需浏览 6分钟

 ·

2021-06-06 22:40

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

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 深度文章以及开源社区的各种新近言论~



浏览 63
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报