anup at brainfault.org
Fri May 28 04:19:39 PDT 2021
On Fri, May 28, 2021 at 4:29 PM Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> On Fri, May 28, 2021 at 11:37:02AM +0200, Paolo Bonzini wrote:
> > On 28/05/21 11:24, Greg Kroah-Hartman wrote:
> > > Ok, as it sounds like this isn't going anywhere until the spec group
> > > gets their work done, you all should just wait as there's no real need
> > > for any kernel code here either, given that there can't be any hardware
> > > made until the spec is finished anyway.
> > There's need for kernel code so that userspace tooling can be built upon it.
> > Not having the header files in Linus's tree makes it harder to merge RISC-V
> > KVM support in userspace. KVM shields userspace from any future changes to
> > the hypervisor specification; the userspace API *is* based exclusively on
> > ratified specifications and there's no risk of breaking the ABI.
> The "risk" is the kernel/hardware api, that seems to not be solid yet
> given the spec is not released so I understand why the riscv maintainers
> do not want to accept it.
> Work to make that solid/released and then no one will be complaining
There is no "risk" in the kernel/hardware api exposed by the KVM RISC-V
because the KVM RISC-V UAPI header is based on the latest ratified
RISC-V privilege v1.11 specification.
The unratified hypervisor extension part of RISC-V privilege spec is
only used by the arch/riscv/kvm sources.
In other words, the KVM RISC-V UAPI header is solid and based
on released/ratified RISC-V specification but the KVM RISC-V
implementation internal to the kernel uses unratified hypervisor
If the hypervisor extension changes (which is very very unlikely) then
still the KVM RISC-V UAPI header will remain the same because it is
based on released specification.
More information about the linux-riscv