Re: [PATCH V2 1/2] riscv: Add RISC-V svpbmt extension

From: Nick Kossifidis <mick@ics.forth.gr>
To: Atish Patra <atishp@atishpatra.org>
Cc: "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@canonical.com,
	"Heinrich Schuchardt" <heinrich.schuchardt@canonical.com>,
	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>,
	"Nick Kossifidis" <mick@ics.forth.gr>,
	"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 04:02:06 +0300	[thread overview]
Message-ID: <0790abcfa1174e0e9b5e7b185f87ced9@mailhost.ics.forth.gr> (raw)
In-Reply-To: <CAOnJCULrE595ex3gBTnu4GnPazO4mg8Tkrtbv6j8iLWe+sKJSA@mail.gmail.com>

Στις 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.

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

Regards,
Nick

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv