arch/riscv/staging

[Paul Walmsley]

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?

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

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

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 ?


regards,

- Paul