Message-ID: <CAJF2gTSHpZMyUk+8HL0=bevCd4XZYRAkrPM600qLPCKxG+bfrg@mail.gmail.com>
Date: Wed, 26 Mar 2025 14:07:47 +0800
From: Guo Ren <guoren@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Peter Zijlstra <peterz@...radead.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Paul Walmsley <paul.walmsley@...ive.com>, 
	Palmer Dabbelt <palmer@...belt.com>, Anup Patel <anup@...infault.org>, 
	Atish Patra <atishp@...shpatra.org>, Oleg Nesterov <oleg@...hat.com>, Kees Cook <kees@...nel.org>, 
	Thomas Gleixner <tglx@...utronix.de>, Will Deacon <will@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, Christian Brauner <brauner@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, 
	Eric Dumazet <edumazet@...gle.com>, Chen Wang <unicorn_wang@...look.com>, 
	Inochi Amaoto <inochiama@...look.com>, gaohan@...as.ac.cn, shihua@...as.ac.cn, 
	jiawei@...as.ac.cn, wuwei2016@...as.ac.cn, Drew Fustini <drew@...7.com>, 
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>, ctsai390@...estech.com, 
	wefu@...hat.com, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Ingo Molnar <mingo@...hat.com>, 
	Boqun Feng <boqun.feng@...il.com>, Xiao W Wang <xiao.w.wang@...el.com>, 
	qingfang.deng@...lower.com.cn, Leonardo Bras <leobras@...hat.com>, 
	Jisheng Zhang <jszhang@...nel.org>, "Conor.Dooley" <conor.dooley@...rochip.com>, 
	Samuel Holland <samuel.holland@...ive.com>, yongxuan.wang@...ive.com, 
	Xu Lu <luxu.kernel@...edance.com>, David Hildenbrand <david@...hat.com>, 
	Ruan Jinjie <ruanjinjie@...wei.com>, Yunhui Cui <cuiyunhui@...edance.com>, 
	Kefeng Wang <wangkefeng.wang@...wei.com>, qiaozhe@...as.ac.cn, 
	Ard Biesheuvel <ardb@...nel.org>, Alexei Starovoitov <ast@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, kvm@...r.kernel.org, 
	kvm-riscv@...ts.infradead.org, linux-mm@...ck.org, 
	linux-crypto@...r.kernel.org, bpf@...r.kernel.org, 
	linux-input@...r.kernel.org, linux-perf-users@...r.kernel.org, 
	linux-serial@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	Linux-Arch <linux-arch@...r.kernel.org>, maple-tree@...ts.infradead.org, 
	linux-trace-kernel@...r.kernel.org, Netdev <netdev@...r.kernel.org>, 
	linux-atm-general@...ts.sourceforge.net, linux-btrfs@...r.kernel.org, 
	netfilter-devel@...r.kernel.org, coreteam@...filter.org, 
	linux-nfs@...r.kernel.org, linux-sctp@...r.kernel.org, 
	linux-usb@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT
 kernel-self with ILP32 ABI

On Tue, Mar 25, 2025 at 9:18 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Tue, Mar 25, 2025, at 13:26, Peter Zijlstra wrote:
> > On Tue, Mar 25, 2025 at 08:15:41AM -0400, guoren@...nel.org wrote:
> >> From: "Guo Ren (Alibaba DAMO Academy)" <guoren@...nel.org>
> >>
> >> Since 2001, the CONFIG_64BIT kernel has been built with the LP64 ABI,
> >> but this patchset allows the CONFIG_64BIT kernel to use an ILP32 ABI
> >
> > Please, don't do this. This adds a significant maintenance burden on all
> > of us.
>
> It would be easier to this with CONFIG_64BIT disabled and continue
> treating CONFIG_64BIT to be the same as BITS_PER_LONG=64, but I still
> think it's fundamentally a bad idea to support this in mainline
> kernels in any variation, other than supporting regular 32-bit
> compat mode tasks on a regular 64-bit kernel.
>
> >> The patchset targets RISC-V and is built on the RV64ILP32 ABI, which
> >> was introduced into RISC-V's psABI in January 2025 [1]. This patchset
> >> equips an rv64ilp32-abi kernel with all the functionalities of a
> >> traditional lp64-abi kernel, yet restricts the address space to 2GiB.
> >> Hence, the rv64ilp32-abi kernel simultaneously supports lp64-abi
> >> userspace and ilp32-abi (compat) userspace, the same as the
> >> traditional lp64-abi kernel.
>
> You declare the syscall ABI to be the native 64-bit ABI, but this
> is fundamentally not true because a many uapi structures are
> defined in terms of 'long' or pointer values, in particular in
> the ioctl call.

I modified uapi with
void __user *msg_name;
->
union {void __user *msg_name; u64 __msg_name;};
to make native 64-bit ABI.

I would look at compat stuff instead of using __riscv_xlen macro.

> This might work for an rv64ilp32 userspace that
> uses the same headers and the same types, but you explicitly
> say that the goal is to run native rv64 or compat rv32 tasks,
> not rv64ilp32 (thanks!).

It's not for rv64ilp32-abi userspace, no rv64ilp32-abi userspace
introduced in the patch set.
It's for native lp64-abi.

Let's discuss this in the first patch thread:
uapi: Reuse lp64 ABI interface

>
> As far as I can tell, there is no way to rectify this design flaw
> other than to drop support for 64-bit userspace and only support
> regular rv32 userspace. I'm also skeptical that supporting rv64
> userspace helps in practice other than for testing, since
> generally most memory overhead is in userspace rather than the
> kernel, and there is much more to gain from shrinking the larger
> userspace by running rv32 compat mode binaries on a 64-bit kernel
> than the other way round.

The lp64-abi userspace rootfs works fine in this patch set, which
proves the technique is valid. But the modification on uapi is raw,
and I'm looking at compat stuff.

Supporting lp64-abi userspace is essential because riscv lp64-abi and
ilp32-abi userspace are hybrid deployments when the target is
ilp32-abi userspace. The lp64-abi provides a good supplement to
ilp32-abi which eases the development.

>
> If you remove the CONFIG_64BIT changes that Peter mentioned and
> the support for ilp64 userland from your series, you end up
> with a kernel that is very similar to a native rv32 kernel
> but executes as rv64ilp32 and runs rv32 userspace. I don't have
> any objections to that approach, and the same thing has come
> up on arm64 as a possible idea as well, but I don't know if
> that actually brings any notable advantage over an rv32 kernel.
>
> Are there CPUs that can run rv64 kernels and rv32 userspace
> but not rv32 kernels, similar to what we have on Arm Cortex-A76
> and Cortex-A510?

Yes, there is, and it only supports rv32 userspace, not rv32 kernel.
https://www.xrvm.com/product/xuantie/C908

Here are the products:
https://developer.canaan-creative.com/k230_canmv/en/dev/userguide/boards/canmv_k230d.html
http://riscv.org/ecosystem-news/2024/07/unpacking-the-canmv-k230-risc-v-board/

-- 
Best Regards
 Guo Ren

Powered by blists - more mailing lists