|
|
Log in / Subscribe / Register

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

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

Posted May 21, 2021 18:54 UTC (Fri) by pwsan (guest, #56604)
Parent article: Why RISC-V doesn't (yet) support KVM

Jonathan writes:

> 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.

One of the issues with the proposal to merge KVM support now for RISC-V is that no one has yet been able to identify any shipping systems that support the RISC-V hypervisor extension. What's being proposed, instead, is that we merge support for a hypervisor extension that isn't yet part of the RISC-V ISA. While we certainly understand Anup's and Paolo's desire to get their code merged upstream as soon as possible, I'm afraid these important points have been lost, both in the article and in most of the discussion.


to post comments

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

Posted May 22, 2021 8:19 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

As far as userspace is concerned, the API is only based on ratified specifications. The details of the hypervisor spec is completely hidden within Linux code. At the same time, until KVM is merged into upstream Linux the whole stack (QEMU, kvmtool) has to be developed in a fork, and new kernel features are harder to review. All this is simply *not how Linux is developed*.

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

Posted May 22, 2021 16:37 UTC (Sat) by mfuzzey (subscriber, #57966) [Link] (2 responses)

Is it shipping *systems* or *chips* that don't exist yet?
Presumably those developing this feature are testing it on something.

If the chips exist just no one is selling systems with them yet (presumably the developers having custom prototype boards) then I see no reason not to merge the feature as the chips aren't going to change.

OTOH if no chips exist yet (eg if prototyping is being done on a FPGA) I can see the rational for waiting if there is a real risk that the final hardware is different.
But even in this case does it really matter given that the user space won't be affected? Sure the kernel code may have to change for the final hardware but if the prototype hardware never shipped does this matter as there will be no need to support both in the kernel.

I may be missing something obvious here as I'm not well versed in RISC V

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

Posted May 23, 2021 7:44 UTC (Sun) by ssmith32 (subscriber, #72404) [Link]

I think this was the argument being made here:

"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. "

And which sounds like the main reason it may end up being merged into stg.

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

Posted May 26, 2021 0:29 UTC (Wed) by pwsan (guest, #56604) [Link]

> Presumably those developing this feature are testing it on something.

Probably most people are using QEMU to experiment with this, with the instructions and code here:

https://github.com/kvm-riscv


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds