https://lwn.net/SubscriberLink/856685/10206d3c9d10daf2/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account Why RISC-V doesn't (yet) support KVM [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! By Jonathan Corbet May 20, 2021 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. 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. 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 architecture support. So staging maintainer Greg Kroah-Hartman was quick to ask why things were being done that way. The answer comes down to the patch-acceptance policy for RISC-V code, found in Documentation/riscv/patch-acceptance.rst, which reads: We'll only accept patches for new modules or extensions if the specifications for those modules or extensions are listed as being "Frozen" or "Ratified" by the RISC-V Foundation. (Developers may, of course, maintain their own Linux kernel trees that contain code for any draft extensions that they wish.) Virtualization for RISC-V is described by the hypervisor extension specification. As Patel explained, that extension has not yet been approved: The KVM RISC-V patches have been sitting on the lists for almost 2 years now. The requirements for freezing RISC-V H-extension (hypervisor extension) keeps changing and we are not clear when it will be frozen. In fact, quite a few people have already implemented RISC-V H-extension in hardware as well and KVM RISC-V works on real HW as well. Rationale of moving KVM RISC-V to drivers/staging is to continue KVM RISC-V development without breaking the Linux RISC-V patch acceptance policy until RISC-V H-extension is frozen. It is fair to say that Kroah-Hartman was not impressed; he stated that circumventing policies in other parts of the kernel tree is not the purpose of the staging directory, so the RISC-V KVM code would not be accepted there. Paolo Bonzini, the overall maintainer for KVM, added that "the RISC-V acceptance policy as is just doesn't work", as demonstrated by the fact that developers are having to work around it. This is especially unfortunate here, he said, because the RISC-V KVM implementation "is also a very good example of how to do things right". He went on to suggest that there may be some players out there who benefit from the slowing down of patches on their way into the kernel. Kroah-Hartman responded that slowing down the merging of useful code is "horrible" and that the job of the kernel community is to make hardware work; a policy that prevents the merging of good code that adds support for existing hardware does not make sense. He asked the RISC-V maintainers to explain this policy; they have yet to answer that question. Back in April, though, RISC-V maintainer Palmer Dabbelt acknowledged that the acceptance policy is not producing the desired results: My goal with the RISC-V stuff has always been getting us to a place where we have real shipping products running a software stack that is as close as possible to the upstream codebases. I see that as the only way to get the software stack to a point where it can be sustainably maintained. The "only frozen extensions" policy was meant to help this by steering vendors towards a common base we could support, but in practice it's just not working out. He added that the policy could change, but only when there is a new policy for patch acceptance in place that everybody agrees to. Co-maintainer Paul Walmsley, though, placed the blame with RISC-V International's specification process and said that any fixes should be applied there instead. It is not that hard to understand why the RISC-V maintainers might not want to attempt to support every nonstandard CPU that is out there. The open nature of RISC-V makes it relatively easy for anybody to create their own variant, and supporting them all could become unworkable. The counterpoint is, as Kroah-Hartman said, that the kernel's job is to run on the hardware that is out there. Blocking support for shipping systems can only have the effect of pushing those systems toward vendor-supplied kernels with a lot of out-of-tree code -- an unfortunate outcome for what is supposed to be an open architecture. When the subject is support for a feature as fundamental as virtualization, the question becomes even more urgent. Hopefully this episode will lead to a rethinking of the patch-acceptance policies for the RISC-V architecture. Failing that, Kroah-Hartman has signaled his willingness to allow that support into staging if there is truly no alternative. So Linux seems likely to gain KVM support for RISC-V in the relatively near future, even if it's necessary to circumvent the architecture's maintainers to do it. Index entries for this article Kernel Architectures/RISC-V Kernel KVM Kernel Virtualization/KVM [Send a free link] ----------------------------------------- (Log in to post comments) Why RISC-V doesn't (yet) support KVM Posted May 20, 2021 18:29 UTC (Thu) by iabervon (subscriber, #722) [ Link] It seems like a significant number of independent hardware implementations shipping that agree with each other and a proposed document should be a reasonable equivalent to the extension being frozen, with respect to supporting it in the kernel. It describes a practice with consensus behind it, even if the Foundation isn't yet willing to encourage that practice. [Reply to this comment] Why RISC-V doesn't (yet) support KVM Posted May 20, 2021 21:02 UTC (Thu) by pbonzini ( supporter , # 60935) [Link] https://lwn.net/ml/linux-kernel/a49a7142-104e-fdaa-4a6a-6... provides additional context as to how feature creep is delaying the freezing of the hypervisor specification. [Reply to this comment] Why RISC-V doesn't (yet) support KVM Posted May 20, 2021 21:36 UTC (Thu) by pdp7pdp7 (subscriber, #96517) [Link] pbonzini: I am confused about your comment [1] that some people may believe it could be beneficial to slow down merging of RISC-V support upstream. I am trying to understand who would benefit in that scenario. Is the theoretical benefit that it could reduce the RISC-V maintainer workload? [1] https://lore.kernel.org/linux-riscv/daa30135-8757-8d33-a9... [Reply to this comment] Why RISC-V doesn't (yet) support KVM Posted May 20, 2021 22:25 UTC (Thu) by pbonzini ( supporter , # 60935) [Link] The patch acceptance policy can become an incentive to game the system: 1. Company X don't have hardware ready that implements an extension 2. Company X slows down ratification of the extension 3. Competitors must ship out of tree code to support the extension in Linux The conflict of interest is outside Linux, which is what Paul Welmsley alluded to with respect to speeding up the process of ratification, but it affects Linux and the maintainers are caught in the crossfire. Looking at the history of the hypervisor extension specification[1], the last significant change was done about one year ago (May 15, 2020). There is no justification at all for the specification not to be frozen yet. [1] https://github.com/riscv/riscv-isa-manual/commits/master/... [Reply to this comment] Copyright (c) 2021, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds