The RISC-V CPU architecture has been gaining prominence for some years; its relatively open nature makes it an attractive platform on which a number of companies have built products. Linux supports RISC-V well, but there is one gaping hole: there is no support for virtualization with KVM, despite the fact that a high-quality implementation exists. A recent attempt to add that support is shining some light on a part of the ecosystem that, it seems, does not work quite as well as one would like.
RISC-V 处理器架构近年来逐渐崭露头角;其相对开放的特性使得它成为众多公司开发产品的理想平台。Linux 对 RISC-V 提供了良好的支持,但仍存在一个明显的缺口:尽管已经有高质量的实现,但尚未支持基于 KVM 的虚拟化。最近一次尝试为其添加该支持,揭示了该生态系统中一个并不尽如人意的环节。
Linux supports a number of virtualization mechanisms, but KVM is generally seen as the native solution. It provides a standard interface across systems, but much of KVM is necessarily architecture-specific, since the mechanisms for supporting virtualization vary from one processor to the next. Thus, architectures that support KVM generally have a kvm directory nestled in with the rest of the architecture-specific code.
Linux 支持多种虚拟化机制,但 KVM 通常被视为原生解决方案。它在各系统之间提供统一的接口,但由于支持虚拟化的机制因处理器架构而异,因此 KVM 的实现很大程度上是与架构相关的。因此,支持 KVM 的架构通常在其架构专属代码目录中包含一个 kvm 子目录。
Given that, some eyebrows were raised when Anup Patel's patch series adding RISC-V KVM support deposited the architecture-specific code into the staging directory instead. Staging is normally used for device drivers that do not meet the kernel's standards for code quality; if all goes well they are improved and eventually "graduate" out of the staging directory. It is not usually a place for a