From: Anup Patel <anup@brainfault.org>
To: Nick Kossifidis <mick@ics.forth.gr>
Cc: "Atish Patra" <atishp@atishpatra.org>,
"Guo Ren" <guoren@kernel.org>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Anup Patel" <anup.patel@wdc.com>,
"Atish Patra" <atish.patra@wdc.com>,
"Palmer Dabbelt" <palmerdabbelt@google.com>,
"Christoph Müllner" <christoph.muellner@vrull.eu>,
"Philipp Tomsich" <philipp.tomsich@vrull.eu>,
"Christoph Hellwig" <hch@lst.de>, liush <liush@allwinnertech.com>,
wefu@redhat.com, "Wei Wu (吴伟)" <lazyparser@gmail.com>,
"Drew Fustini" <drew@beagleboard.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
"linux-kernel@vger.kernel.org List"
<linux-kernel@vger.kernel.org>,
taiten.peng@canonical.com,
"Aniket Ponkshe" <aniket.ponkshe@canonical.com>,
"Heinrich Schuchardt" <heinrich.schuchardt@canonical.com>,
"Gordan Markus" <gordan.markus@canonical.com>,
"Guo Ren" <guoren@linux.alibaba.com>,
"Arnd Bergmann" <arnd@arndb.de>, "Chen-Yu Tsai" <wens@csie.org>,
"Maxime Ripard" <maxime@cerno.tech>,
"Daniel Lustig" <dlustig@nvidia.com>,
"Greg Favor" <gfavor@ventanamicro.com>,
"Andrea Mondelli" <andrea.mondelli@huawei.com>,
"Jonathan Behrens" <behrensj@mit.edu>,
Xinhaoqu <xinhaoqu@huawei.com>,
"Bill Huffman" <huffman@cadence.com>,
"Allen Baum" <allen.baum@esperantotech.com>,
"Josh Scheid" <jscheid@ventanamicro.com>,
"Richard Trauben" <rtrauben@gmail.com>
Subject: Re: [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension
Date: Tue, 28 Sep 2021 09:20:18 +0530 [thread overview]
Message-ID: <CAAhSdy2-y4xpM9PCrS0vgCN9ngFiBygeDOWcbgsX6Myb4XjDQg@mail.gmail.com> (raw)
In-Reply-To: <0790abcfa1174e0e9b5e7b185f87ced9@mailhost.ics.forth.gr>
On Tue, Sep 28, 2021 at 6:32 AM Nick Kossifidis <mick@ics.forth.gr> wrote:
>
> Στις 2021-09-27 23:13, Atish Patra έγραψε:
> >> We need to decide whether we should support the upstream kernel for
> >> D1. Few things to consider.
> >> – Can it be considered as an errata ?
>
> It's one thing to follow the spec and have an error in the
> implementation, and another to not follow the spec.
>
> >> – Does it set a bad precedent and open can of worms in future ?
>
> IMHO yes, I'm thinking of Kendryte 210 devs for example coming up and
> asking for MMU support, they 've also shipped many chips already. I can
> also imagine other vendors in the future coming up with implementations
> that violate the spec in which case handling the standard stuff will
> become messy and complex, and hurt performance/security. We'll end up
> filling the code with exceptions and tweaks all over the place. We need
> to be strict about what is "riscv" and what's "draft riscv" or "riscv
> inspired", and what we are willing to support upstream. I can understand
> supporting vendor extensions upstream but they need to fit within the
> standard spec, we can't have for example extensions that use encoding
> space/csrs/fields etc reserved for standard use, they may only use
> what's reserved for custom/vendor use. At least let's agree on that.
Totally agree with Nick here. It's a slippery slope.
Including D1 PTE bits (or Kendryte K210 MMU) part of the Linux RISC-V
means future hardware which intentionally violates specs will also have to
be merged and the RISC-V patch acceptance policy will have no significance.
>
> >> – Can we just ignore D1 given the mass volume ?
> >>
>
> IMHO no, we need to find a way to support it upstream but I believe
> there is another question to answer:
>
> Do we also guarantee "one image to rule them all" approach, required by
> binary distros, for implementations that violate the spec ? Are we ok
> for example to support Allwinner D1 upstream but require a custom
> configuration/build instead of supporting it with the "generic" image ?
> In one case we need to handle the violation at runtime and introduce
> overhead for everyone (like looking up __riscv_svpbmt every time we set
> a PTE in this case), in the other it's an #ifdef.
At least, we should not have hardware violating specs as part of the
unified kernel image instead have these intentional deviations/violations
under separate kconfig which will not be enabled by default. This means
vendors (of such hardware) and distros will have to explicitly enable
support for such violations/deviations.
Regards,
Anup
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-09-28 3:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-23 17:21 [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension guoren
2021-09-23 17:21 ` [PATCH V2 2/2] dt-bindings: riscv: Add svpbmt in cpu mmu-type property guoren
[not found] ` <CAOnJCU+6hUSdviwCM6uwCQr=OV3xQP=RF-BmdJFY8Tzgd_L51Q@mail.gmail.com>
2021-09-28 0:42 ` Guo Ren
[not found] ` <CAOnJCUJWnDB+uRxDh=YSbGW4bf5RQvke03iCTYMYHPsw3cwnHQ@mail.gmail.com>
2021-09-27 20:13 ` [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension Atish Patra
[not found] ` <CA+Qh7T=kud8AM-6JjuWNwJY0r_gkmnP6SmzVXqeE2VYxViLUoQ@mail.gmail.com>
2021-09-27 23:05 ` Atish Patra
2021-09-28 9:45 ` Philipp Tomsich
2021-09-28 0:23 ` Nick Kossifidis
2021-09-28 1:02 ` Nick Kossifidis
2021-09-28 3:50 ` Anup Patel [this message]
2021-09-28 4:26 ` Atish Patra
2021-09-28 6:03 ` Guo Ren
[not found] ` <CA+Qh7T=p4+p0c8XF4YiVaCmc--HtjTLdn6=YNa4SBb8yZk2maA@mail.gmail.com>
2021-09-28 6:14 ` Atish Patra
2021-09-28 13:19 ` Nick Kossifidis
2021-09-28 13:46 ` Philipp Tomsich
2021-09-28 14:58 ` Alexandre Ghiti
2021-10-05 0:44 ` Palmer Dabbelt
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=CAAhSdy2-y4xpM9PCrS0vgCN9ngFiBygeDOWcbgsX6Myb4XjDQg@mail.gmail.com \
--to=anup@brainfault.org \
--cc=allen.baum@esperantotech.com \
--cc=andrea.mondelli@huawei.com \
--cc=aniket.ponkshe@canonical.com \
--cc=anup.patel@wdc.com \
--cc=arnd@arndb.de \
--cc=atish.patra@wdc.com \
--cc=atishp@atishpatra.org \
--cc=behrensj@mit.edu \
--cc=christoph.muellner@vrull.eu \
--cc=dlustig@nvidia.com \
--cc=drew@beagleboard.org \
--cc=gfavor@ventanamicro.com \
--cc=gordan.markus@canonical.com \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=hch@lst.de \
--cc=heinrich.schuchardt@canonical.com \
--cc=huffman@cadence.com \
--cc=jscheid@ventanamicro.com \
--cc=lazyparser@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=liush@allwinnertech.com \
--cc=maxime@cerno.tech \
--cc=mick@ics.forth.gr \
--cc=palmer@dabbelt.com \
--cc=palmerdabbelt@google.com \
--cc=philipp.tomsich@vrull.eu \
--cc=rtrauben@gmail.com \
--cc=taiten.peng@canonical.com \
--cc=wefu@redhat.com \
--cc=wens@csie.org \
--cc=xinhaoqu@huawei.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 NNTP newsgroup(s).