From: Paul Walmsley <email@example.com> To: Palmer Dabbelt <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, Anup Patel <Anup.Patel@wdc.com>, email@example.com, firstname.lastname@example.org, Atish Patra <Atish.Patra@wdc.com>, Alistair Francis <Alistair.Francis@wdc.com>, Damien Le Moal <Damien.LeMoal@wdc.com>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH v16 00/17] KVM RISC-V Support Date: Mon, 26 Apr 2021 22:43:18 -0700 (PDT) [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <mhng-d64da1be-bacd-4885-aaf2-fea3c763418c@palmerdabbelt-glaptop> On Fri, 9 Apr 2021, Palmer Dabbelt wrote: > On Wed, 31 Mar 2021 02:21:58 PDT (-0700), firstname.lastname@example.org wrote: > > > Palmer, are you okay with merging RISC-V KVM? Or should we place it in > > drivers/staging/riscv/kvm? > > I'm certainly ready to drop my objections to merging the code based on > it targeting a draft extension, but at a bare minimum I want to get a > new policy in place that everyone can agree to for merging code. I've > tried to draft up a new policy a handful of times this week, but I'm not > really quite sure how to go about this: ultimately trying to build > stable interfaces around an unstable ISA is just a losing battle. I've > got a bunch of stuff going on right now, but I'll try to find some time > to actually sit down and finish one. > > I know it might seem odd to complain about how slowly things are going > and then throw up another roadblock, but I really do think this is a > very important thing to get right. I'm just not sure how we're going to > get anywhere with RISC-V without someone providing stability, so I want > to make sure that whatever we do here can be done reliably. If we don't > I'm worried the vendors are just going to go off and do their own > software stacks, which will make getting everyone back on the same page > very difficult. I sympathize with Paolo, Anup, and others also. Especially Anup, who has been updating and carrying the hypervisor patches for a long time now. And also Greentime, who has been carrying the V extension patches. The RISC-V hypervisor specification, like several other RISC-V draft specifications, is taking longer to transition to the officially "frozen" stage than almost anyone in the RISC-V community would like. Since we share this frustration, the next questions are: - What are the root causes of the problem? - What's the right forum to address the root causes? To me, the root causes of the problems described in this thread aren't with the arch/riscv kernel maintenance guidelines, but rather with the RISC-V specification process itself. And the right forum to address issues with the RISC-V specification process is with RISC-V International itself: the mailing lists, the participants, and the board of directors. Part of the challenge -- not simply with RISC-V, but with the Linux kernel or any other community -- is to ensure that incentives (and disincentives) are aligned with the appropriately responsible parts of the community. And when it comes to specification development, the right focus to align those incentives and disincentives is on RISC-V International. The arch/riscv patch acceptance guidelines are simply intended to ensure that the definition of what is and isn't RISC-V remains clear and unambiguous. Even though the guidelines can result in short-term pain, the intention is to promote long-term stability and sustainable maintainability - particularly since the specifications get baked into hardware. We've observed that attempting to chase draft specifications can cause significant churn: for example, the history of the RISC-V vector specification illustrates how a draft extension can undergo major, unexpected revisions throughout its journey towards ratification. One of our responsibilities as kernel developers is to minimize that churn - not simply for our own sanity, or for the usability of RISC-V, but to ensure that we remain members in good standing of the broader kernel community. Those of us who were around for the ARM32 and ARM SoC kernel accelerando absorbed strong lessons in maintainability, and I doubt anyone here is interested in re-learning those the hard way. RVI states that the association is open to community participation. The organizations that have joined RVI, I believe, have a strong stake in the health of the RISC-V ecosystem, just as the folks have here in this discussion. If the goal really is to get quality specifications out the door faster, then let's focus the energy towards building consensus towards improving the process at RISC-V International. If that's possible, the benefits won't only accrue to Linux developers, but to the entire RISC-V hardware and software development community at large. If nothing else, it will be an interesting test of whether RISC-V International can take action to address these concerns and balance them with those of other stakeholders in the process. - Paul
next prev parent reply other threads:[~2021-04-27 5:43 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-15 12:18 Anup Patel 2021-01-15 12:18 ` [PATCH v16 01/17] RISC-V: Add hypervisor extension related CSR defines Anup Patel 2021-01-15 12:18 ` [PATCH v16 02/17] RISC-V: Add initial skeletal KVM support Anup Patel 2021-01-15 12:18 ` [PATCH v16 03/17] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel 2021-01-15 12:18 ` [PATCH v16 04/17] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel 2021-01-15 12:18 ` [PATCH v16 05/17] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel 2021-01-15 12:18 ` [PATCH v16 06/17] RISC-V: KVM: Implement VCPU world-switch Anup Patel 2021-01-15 12:18 ` [PATCH v16 07/17] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel 2021-01-15 12:18 ` [PATCH v16 08/17] RISC-V: KVM: Handle WFI " Anup Patel 2021-01-15 12:18 ` [PATCH v16 09/17] RISC-V: KVM: Implement VMID allocator Anup Patel 2021-01-15 12:18 ` [PATCH v16 10/17] RISC-V: KVM: Implement stage2 page table programming Anup Patel 2021-01-15 12:18 ` [PATCH v16 11/17] RISC-V: KVM: Implement MMU notifiers Anup Patel 2021-01-15 12:18 ` [PATCH v16 12/17] RISC-V: KVM: Add timer functionality Anup Patel 2021-01-15 12:18 ` [PATCH v16 13/17] RISC-V: KVM: FP lazy save/restore Anup Patel 2021-01-15 12:18 ` [PATCH v16 14/17] RISC-V: KVM: Implement ONE REG interface for FP registers Anup Patel 2021-01-15 12:18 ` [PATCH v16 15/17] RISC-V: KVM: Add SBI v0.1 support Anup Patel 2021-01-15 12:18 ` [PATCH v16 16/17] RISC-V: KVM: Document RISC-V specific parts of KVM API Anup Patel 2021-01-15 12:18 ` [PATCH v16 17/17] RISC-V: KVM: Add MAINTAINERS entry Anup Patel 2021-01-23 3:40 ` [PATCH v16 00/17] KVM RISC-V Support Palmer Dabbelt 2021-03-30 5:48 ` Anup Patel 2021-03-31 9:21 ` Paolo Bonzini 2021-04-01 13:24 ` Anup Patel 2021-04-09 18:58 ` Palmer Dabbelt 2021-04-21 4:08 ` Anup Patel 2021-04-27 5:43 ` Paul Walmsley [this message] 2021-04-27 6:01 ` Anup Patel 2021-04-27 7:04 ` Paolo Bonzini 2021-04-28 7:07 ` Anup Patel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --cc=Alistair.Francis@wdc.com \ --cc=Anup.Patel@wdc.com \ --cc=Atish.Patra@wdc.com \ --cc=Damien.LeMoal@wdc.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v16 00/17] KVM RISC-V Support' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).