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>,
Atish Patra <Atish.Patra@wdc.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
Damien Le Moal <Damien.LeMoal@wdc.com>,
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)
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.
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 [PATCH v16 00/17] KVM RISC-V Support 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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).