arch/riscv/staging

[Anup Patel]

Hi Greg,

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
> here,

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.
Refer:
https://github.com/avpatel/linux/blob/riscv_kvm_v17/arch/riscv/include/uapi/asm/kvm.h
https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMFDQC-and-Priv-v1.11/riscv-privileged-20190608.pdf

The unratified hypervisor extension part of RISC-V privilege spec is
only used by the arch/riscv/kvm sources.
Refer:
https://github.com/avpatel/linux/tree/riscv_kvm_v17/arch/riscv/kvm

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

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.

Regards,
Anup