arch/riscv/staging

[Paul Walmsley]

Hi Anup,

On Sat, 22 May 2021, Anup Patel wrote:

> On Fri, May 21, 2021 at 10:53 PM Paul Walmsley <paul.walmsley at sifive.com> wrote:
>
> > 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. 

Sounds like you've got great connections with the right people at RISC-V 
International as far as virtualization is concerned.

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

Earlier this year, there was a post where someone asked on the RISC-V 
International lists whether the ISA architects were ready to freeze the H 
extension:

    https://lists.riscv.org/g/tech-privileged/topic/80346318#465

Many of the same points were made that you and Damien and Paolo have 
brought up on the Linux kernel mailing lists.  Two engineers working on 
the RISC-V ISA responded, representing two different companies.  They 
wrote in the thread above that it's "far from certain" that no changes 
will need to be need to be made, and that "it's a good (and necessary 
compromise)" to "[wait] a little longer to see [the AIA specification] at 
least stabilize".  So it sounds like there's still a diversity of opinions 
here.

Since it sounds like you've got a lot of influence with the RVI folks 
working on virtualization, seems like you'd be an ideal person to try to 
convince them that you're right and that they should freeze the hypervisor 
ISA extension right now?  Then we could just merge your patch set and we 
could all skip the next round of Linux kernel E-mails about this topic.

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

OK, well, maybe you and Damien can get together and spell out what you all 
are concerned about regarding forks.  Then we can see if there's anything 
that should be done to address it.  

Right now the only fork risk that I can see is related to the architecture 
itself.

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

Others have already covered why arch/riscv/staging is a bad idea, so no 
point in rehashing that here.


- Paul