arch/riscv/staging

[Anup Patel]

+GregKH

On Fri, May 21, 2021 at 10:53 PM Paul Walmsley <paul.walmsley at sifive.com> wrote:
>
> Hi Damien,
>
> Thanks for the thoughtful and considered E-mail.  I know you addressed
> this to Palmer, but maybe you'd be willing to discuss this a little bit
> with me?
>
> On Fri, 21 May 2021, Damien Le Moal wrote:
>
> > For the hypervisor extension and KVM support, the specifications are now very
> > stable and while changes due to the advanced interrupt controller specs work,
> > among other, are still possible, the changes will likely be small and should not
> > cause much headache in the kernel.
>
> This is the part that I don't quite understand.  If everyone -- including
> the architecture folks working on the ISA extension at riscv.org -- agrees
> that the H extension isn't going to change significantly, why don't they
> freeze the extension?  Could it be that the RVI folks are worried that
> they may need to make significant changes, and that's why they haven't
> frozen it yet?

I have been involved in the H-extension spec development for the past
few years working with RISC-V ISA architects (Andrew and John.) I am also
involved in the RISC-V AIA specification as chair. I confirm that all required
provisions are already there in the RISC-V H-extension to support an
external interrupt controller with virtualization acceleration (such as
RISC-V AIA).

In fact, Paolo (with his years of experience in KVM virtualization) also
confirmed that current H-extension have all required features.

Clearly, significant changes are very very unlikely.

>
> > Given that there is already HW (and QEMU) supporting H extension, we
> > really need to move forward with merging riscv KVM support.
>
> This is maybe a side question, but: has someone actually put the H
> extension into silicon?  My understanding so far is that it's only been
> implemented into an experimental FPGA soft-core so far.
>
> > That will reduce the risk of seeing forks pop out here and there and
> > greatly facilitate Paolo and Anup work.
>
> When you write about forks, are you worried about architecture forks,
> forks of Anup's patchset, or some other kind of fork here?
>
> I ask because in the past, it sounds like there's been some concern from
> WDC that someone else will come along and submit an alternative RISC-V KVM
> patch set that we'd somehow prefer over Anup's.  That's pretty
> unlikely; I think everyone involved -- certainly including Palmer and I --
> know that you guys have done the foundational work here, and you guys
> would certainly have clear precedence here, unless there turned out to be
> something wrong with the WDC patchset that you all wouldn't be willing to
> fix.  But maybe I'm misunderstanding your concern?

This is certainly your misunderstanding. Like Paolo mentioned in other
thread, the current KVM RISC-V is in good shape and as-per expectations
of the KVM core maintainer.

>
> > For this, I propose that we create arch/riscv/staging as a temporary location
> > for on-going work for supporting ISA extensions that are being drafted but not
> > yet frozen. That will allow the community to share a common code base for the
> > support code, and also allow more eyes to look at the extension themselves.
> > This way we can both facilitate and accelerate riscv ecosystem development while
> > also speeding up the specification work by providing constant feedback.
>
> If the goal is to create a common code base for testing and discussing
> draft extensions, we'd be happy to maintain another branch or another
> k.org tree to hold these.

Having a staging branch or separate tree does not work for KVM RISC-V
because we have lot's of user-space tools (QEMU, KVMTOOL, etc) which
expect the KVM UAPI header to be available in the upstream kernel. These
user-space tools will not accept patches until the KVM UAPI header is available
in the upstream kernel. Same thing was mentioned by Paolo in other thread.

>
> But in terms of the suggestion to create arch/riscv/staging, I think
> that's just going to create the same problems that the RISC-V patch
> acceptance guidelines were intended to solve.  To put it differently, from
> my point of view, it's a feature, not a bug, that we don't send code for
> discussion drafts of ISA changes upstream to Linus.   But maybe I'm
> misunderstanding what you're looking for ?

For KVM RISC-V, the arch/riscv/staging directory is a perfect solution
because:
1) The KVM RISC-V UAPI is header is indeed based on the latest
ratified RISC-V privilege spec v1.11 hence the KVM RISC-V UAPI
header complies with current RISC-V patch acceptance policy.
2) All usage of RISC-V H-extension is contained within the KVM RISC-V
sources only. Rest of the Linux RISC-V kernel does not use H-extension
at all.

The current RISC-V patch acceptance policy should make an exception
for draft extensions where the UAPI headers are based on ratified
RISC-V specs and sources for such draft extension should be placed
in arch/riscv/staging directory.

Regards,
Anup