From: Greg KH <gregkh@linuxfoundation.org>
To: Damien Le Moal <Damien.LeMoal@wdc.com>
Cc: Palmer Dabbelt <palmerdabbelt@google.com>,
"guoren@kernel.org" <guoren@kernel.org>,
Anup Patel <Anup.Patel@wdc.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"graf@amazon.com" <graf@amazon.com>,
Atish Patra <Atish.Patra@wdc.com>,
Alistair Francis <Alistair.Francis@wdc.com>,
"anup@brainfault.org" <anup@brainfault.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"kvm-riscv@lists.infradead.org" <kvm-riscv@lists.infradead.org>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>
Subject: Re: [PATCH v18 00/18] KVM RISC-V Support
Date: Tue, 25 May 2021 09:37:11 +0200 [thread overview]
Message-ID: <YKypJ5SJg2sDtn7/@kroah.com> (raw)
In-Reply-To: <DM6PR04MB708173B754E145BC843C4123E7269@DM6PR04MB7081.namprd04.prod.outlook.com>
On Mon, May 24, 2021 at 11:08:30PM +0000, Damien Le Moal wrote:
> On 2021/05/25 7:57, Palmer Dabbelt wrote:
> > On Mon, 24 May 2021 00:09:45 PDT (-0700), guoren@kernel.org wrote:
> >> Thx Anup,
> >>
> >> Tested-by: Guo Ren <guoren@kernel.org> (Just on qemu-rv64)
> >>
> >> I'm following your KVM patchset and it's a great job for riscv
> >> H-extension. I think hardware companies hope Linux KVM ready first
> >> before the real chip. That means we can ensure the hardware could run
> >> mainline linux.
> >
> > I understand that it would be wonderful for hardware vendors to have a
> > guarantee that their hardware will be supported by the software
> > ecosystem, but that's not what we're talking about here. Specifically,
> > the proposal for this code is to track the latest draft extension which
> > would specifically leave vendors who implement the current draft out in
> > the cold was something to change. In practice that is the only way to
> > move forward with any draft extension that doesn't have hardware
> > available, as the software RISC-V implementations rapidly deprecate
> > draft extensions and without a way to test our code it is destined to
> > bit rot.
>
> To facilitate the process of implementing, and updating, against draft
> specifications, I proposed to have arch/riscv/staging added. This would be the
> place to put code based on drafts. Some simple rules can be put in place:
> 1) The code and eventual ABI may change any time, no guarantees of backward
> compatibility
> 2) Once the specifications are frozen, the code is moved out of staging
> somewhere else.
> 3) The code may be removed any time if the specification proposal is dropped, or
> any other valid reason (can't think of any other right now)
> 4) ...
>
> This way, the implementation process would be greatly facilitated and
> interactions between different extensions can be explored much more easily.
>
> Thoughts ?
It will not work, unless you are mean and ruthless and people will get
mad at you. I do not recommend it at all.
Once code shows up in the kernel tree, and people rely on it, you now
_have_ to support it. Users don't know the difference between "staging
or not staging" at all. We have reported problems of staging media
drivers breaking userspace apps and people having problems with that,
despite the media developers trying to tell the world, "DO NOT RELY ON
THESE!".
And if this can't be done with tiny simple single drivers, you are going
to have a world-of-hurt if you put arch/platform support into
arch/riscv/. Once it's there, you will never be able to delete it,
trust me.
If you REALLY wanted to do this, you could create drivers/staging/riscv/
and try to make the following rules:
- stand-alone code only, can not depend on ANYTHING outside of
the directory that is not also used by other in-kernel code
- does not expose any userspace apis
- interacts only with existing in-kernel code.
- can be deleted at any time, UNLESS someone is using it for
functionality on a system
But what use would that be? What could you put into there that anyone
would be able to actually use?
Remember the rule we made to our user community over 15 years ago:
We will not break userspace functionality*
With the caveat of "* - in a way that you notice".
That means we can remove and change things that no one relies on
anymore, as long as if someone pops up that does rely on it, we put it
back.
We do this because we never want anyone to be afraid to drop in a new
kernel, because they know we did not break their existing hardware and
userspace workloads. And if we did, we will work quickly to fix it.
So back to the original issue here, what is the problem that you are
trying to solve? Why do you want to have in-kernel code for hardware
that no one else can have access to, and that isn't part of a "finalized
spec" that ends up touching other subsystems and is not self-contained?
Why not take the energy here and go get that spec ratified so we aren't
having this argument anymore? What needs to be done to make that happen
and why hasn't anyone done that? There's nothing keeping kernel
developers from working on spec groups, right?
thanks,
greg k-h
next prev parent reply other threads:[~2021-05-25 7:37 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 3:35 [PATCH v18 00/18] KVM RISC-V Support Anup Patel
2021-05-19 3:35 ` [PATCH v18 01/18] RISC-V: Add hypervisor extension related CSR defines Anup Patel
2021-05-19 3:35 ` [PATCH v18 02/18] RISC-V: Add initial skeletal KVM support Anup Patel
2021-05-19 9:24 ` Dan Carpenter
2021-05-19 10:17 ` Dan Carpenter
2021-05-19 3:35 ` [PATCH v18 03/18] RISC-V: KVM: Implement VCPU create, init and destroy functions Anup Patel
2021-05-19 3:35 ` [PATCH v18 04/18] RISC-V: KVM: Implement VCPU interrupts and requests handling Anup Patel
2021-05-19 3:35 ` [PATCH v18 05/18] RISC-V: KVM: Implement KVM_GET_ONE_REG/KVM_SET_ONE_REG ioctls Anup Patel
2021-05-19 3:35 ` [PATCH v18 06/18] RISC-V: KVM: Implement VCPU world-switch Anup Patel
2021-05-19 3:35 ` [PATCH v18 07/18] RISC-V: KVM: Handle MMIO exits for VCPU Anup Patel
2021-05-19 3:35 ` [PATCH v18 08/18] RISC-V: KVM: Handle WFI " Anup Patel
2021-05-19 3:35 ` [PATCH v18 09/18] RISC-V: KVM: Implement VMID allocator Anup Patel
2021-05-19 3:35 ` [PATCH v18 10/18] RISC-V: KVM: Implement stage2 page table programming Anup Patel
2021-05-19 3:35 ` [PATCH v18 11/18] RISC-V: KVM: Implement MMU notifiers Anup Patel
2021-05-19 10:09 ` Dan Carpenter
2021-05-19 3:35 ` [PATCH v18 12/18] RISC-V: KVM: Add timer functionality Anup Patel
2021-05-19 3:35 ` [PATCH v18 13/18] RISC-V: KVM: FP lazy save/restore Anup Patel
2021-05-19 3:35 ` [PATCH v18 14/18] RISC-V: KVM: Implement ONE REG interface for FP registers Anup Patel
2021-05-19 10:11 ` Dan Carpenter
2021-05-20 6:09 ` Dan Carpenter
2021-05-19 3:35 ` [PATCH v18 15/18] RISC-V: KVM: Add SBI v0.1 support Anup Patel
2021-05-19 3:35 ` [PATCH v18 16/18] RISC-V: KVM: Document RISC-V specific parts of KVM API Anup Patel
2021-05-19 3:35 ` [PATCH v18 17/18] RISC-V: KVM: Move sources to drivers/staging directory Anup Patel
2021-05-19 3:35 ` [PATCH v18 18/18] RISC-V: KVM: Add MAINTAINERS entry Anup Patel
2021-05-19 4:58 ` [PATCH v18 00/18] KVM RISC-V Support Greg Kroah-Hartman
2021-05-19 5:10 ` Anup Patel
2021-05-19 5:21 ` Greg Kroah-Hartman
2021-05-19 10:47 ` Greg Kroah-Hartman
2021-05-19 11:18 ` Paolo Bonzini
2021-05-19 12:23 ` Greg Kroah-Hartman
2021-05-19 13:29 ` Paolo Bonzini
2021-05-19 13:58 ` Greg Kroah-Hartman
2021-05-19 15:08 ` Dan Carpenter
2021-05-19 15:26 ` Paolo Bonzini
2021-05-21 17:13 ` Palmer Dabbelt
2021-05-21 17:21 ` Paolo Bonzini
2021-05-21 17:47 ` Greg KH
2021-05-21 18:08 ` Palmer Dabbelt
2021-05-21 18:25 ` Greg KH
2021-05-21 20:25 ` Paolo Bonzini
2021-05-24 7:09 ` Guo Ren
2021-05-24 22:57 ` Palmer Dabbelt
2021-05-24 23:08 ` Damien Le Moal
2021-05-25 7:37 ` Greg KH [this message]
2021-05-25 8:01 ` Damien Le Moal
2021-05-25 8:11 ` Greg KH
2021-05-25 8:24 ` Paolo Bonzini
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 \
--in-reply-to=YKypJ5SJg2sDtn7/@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Alistair.Francis@wdc.com \
--cc=Anup.Patel@wdc.com \
--cc=Atish.Patra@wdc.com \
--cc=Damien.LeMoal@wdc.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=corbet@lwn.net \
--cc=graf@amazon.com \
--cc=guoren@kernel.org \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-staging@lists.linux.dev \
--cc=palmerdabbelt@google.com \
--cc=paul.walmsley@sifive.com \
--cc=pbonzini@redhat.com \
/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
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 read-only IMAP folder(s) and NNTP newsgroup(s).