Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Subject: [PATCH] RISC-V: Add CONFIG_{NON,}PORTABLE
Date:   Thu, 10 Mar 2022 09:08:45 -0800
Message-Id: <20220310170845.17614-1-palmer@rivosinc.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Cc:     Paul Walmsley <paul.walmsley@sifive.com>,
        Palmer Dabbelt <palmer@dabbelt.com>, aou@eecs.berkeley.edu,
        linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
        Palmer Dabbelt <palmer@rivosinc.com>
From:   Palmer Dabbelt <palmer@rivosinc.com>
To:     Arnd Bergmann <arnd@arndb.de>
Precedence: bulk

From: Palmer Dabbelt <palmer@rivosinc.com>

The RISC-V port has collected a handful of options that are
fundamentally non-portable.  To prevent users from shooting themselves
in the foot, hide them all behind a config entry that explicitly calls
out that non-portable binaries may be produced.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

---
This came up in the context of the no-M patch:
https://lore.kernel.org/lkml/CAK8P3a3mzax-OiaxBcxM_RgKNsd6N8HW0odRmw38u2jKE5aYaQ@mail.gmail.com/

I'm not sure I strictly need both PORTABLE and NONPORTABLE, but it's the
only way I could come up with to force things like EFI.  I'll poke
around Kconfig a bit more, but I figured this is going to lead to a
discussion so it'd be better to just send this crusty version so we at
least have something concrete to talk about.

I've only given this a smoke test (ie, defconfig looks OK).  I'll go
through all the configs if folks think this is the right way to go -- I
figure it's better to have the discussion on a more focused patch than
on that M patch, as this is really an orthogonal issue.

I'm not really sure what the right option is here: I'm not selecting
things like errata and basic drivers, but I could buy the argument that
disabling those results in non-portable systems.  I am selecting EFI,
that might not be strictly required now but it's the direction we're
going so I figure we might as well start now.  I've also hidden 32BIT
behind this, I could see that going either way but my guess is that
users of 32-bit systems won't care about portable binaries.  I'm also
not sure if this should be tied to something like EMBEDDED or EXPERT.

My biggest worry with this is that users might get the feeling that
current kernels will be compatible with new hardware, that's just not
how RISC-V works.  I tried to write the help text indicating that, I'm
not sure I like how it reads so I'll almost certainly take another shot
at it (though suggestions are, of course, welcome).

I'm also a bit worried that vendors might get the feeling we're not
going to support systems that need modifications to these portablity
requirements.  That's also not the case, as there's really no way for
vendors to make sure their systems continue to run portable kernels
aside from just releasing them publicly so we can test them.
---
 arch/riscv/Kconfig | 28 ++++++++++++++++++++++++++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 5adcbd9b5e88..de0916d7aca7 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -9,6 +9,7 @@ config 64BIT
 
 config 32BIT
 	bool
+	depends on NONPORTABLE
 
 config RISCV
 	def_bool y
@@ -485,6 +486,7 @@ config STACKPROTECTOR_PER_TASK
 
 config PHYS_RAM_BASE_FIXED
 	bool "Explicitly specified physical RAM address"
+	depends on NONPORTABLE
 	default n
 
 config PHYS_RAM_BASE
@@ -498,7 +500,7 @@ config PHYS_RAM_BASE
 
 config XIP_KERNEL
 	bool "Kernel Execute-In-Place from ROM"
-	depends on MMU && SPARSEMEM
+	depends on MMU && SPARSEMEM && NONPORTABLE
 	# This prevents XIP from being enabled by all{yes,mod}config, which
 	# fail to build since XIP doesn't support large kernels.
 	depends on !COMPILE_TEST
@@ -538,9 +540,31 @@ endmenu
 
 config BUILTIN_DTB
 	bool
-	depends on OF
+	depends on OF && NONPORTABLE
 	default y if XIP_KERNEL
 
+config NONPORTABLE
+	bool "Allow configurations that result in non-portable kernels"
+	help
+	  RISC-V kernel binaries are compatibile between all known systems
+	  whenever possible, but there are some use cases that can only be
+	  satisfied by configurations that result in kernel binaries that are
+	  not portable between systems.
+
+	  Selecting N does not guarntee kernels will be portable to all knows
+	  systems.  Selecting any of the options guarded by NONPORTABLE will
+	  result in kernel binaries that are unlikely to be portable between
+	  systems.
+
+	  If unsure, say N.
+
+config PORTABLE
+	bool
+	default !NONPORTABLE
+	select EFI
+	select OF
+	select MMU
+
 menu "Power management options"
 
 source "kernel/power/Kconfig"
-- 
2.34.1