Message-Id: <a9dddc3d-d03d-4614-9d55-1ce48c6ad5ef@app.fastmail.com>
Date: Wed, 26 Mar 2025 07:55:17 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: guoren <guoren@...nel.org>
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 Wed, Mar 26, 2025, at 07:07, Guo Ren wrote:
> 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:
>>
>> 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.

The problem I see here is that there are many more drivers
that you did not modify than drivers that you did change this
way.  The union is particularly ugly, but even if you find
a nicer method of doing this, you now also put the burden
on future driver writers to do this right for your platform.

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

There is a big difference between making it work for a particular
set of userspace binaries and making it correct for the entire
kernel ABI.

I agree that limiting the hacks to the compat side while keeping
the native ABI as ilp32 as in your previous versions is better,
but I also don't think this can be easily done without major
changes to how compat mode works in general, and that still
seems like a show-stopper for two reasons:

- it still puts the burden on driver writers to get it right
  for your platform. The scope is a bit smaller than in the
  current version because that would be limited to the compat
  handlers and not change the native codepath, but that's
  still a lot of drivers.

- the way that I would imagine this to be implemented in
  practice would require changing the compat code in a way that
  allows multiple compat ABIs, so drivers can separate the
  normal 32-on-64 handling from the 64-on-32 version you need.
  We have discussed something like this in the past, but Linus
  has already made it very clear that he doesn't want it done
  that way. Whichever way you do it, this is unlikely to
  find consensus.  

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

I'm not following here, please clarify. I do understand that
having a mixed 32/64 userspace can help for development, but
that can already be done on a 64-bit kernel and it doesn't
seem to be useful for deployment because having two sets of
support libraries makes this counterproductive for the goal
of saving RAM.

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

Ok, thanks for the link.

       Arnd

Powered by blists - more mailing lists