From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76278C36008 for ; Wed, 26 Mar 2025 06:08:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E89BB28005C; Wed, 26 Mar 2025 02:08:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1335280056; Wed, 26 Mar 2025 02:08:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C8BC028005C; Wed, 26 Mar 2025 02:08:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id A8CC3280056 for ; Wed, 26 Mar 2025 02:08:03 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E22691A0595 for ; Wed, 26 Mar 2025 06:08:04 +0000 (UTC) X-FDA: 83262671688.06.53D3451 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf19.hostedemail.com (Postfix) with ESMTP id CF2D31A0004 for ; Wed, 26 Mar 2025 06:08:02 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Nco888oV; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of guoren@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=guoren@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742969283; a=rsa-sha256; cv=none; b=pZGoGawt5SaZ/KG7lcJDBUJSMuzvW/KXrWLjv84ESEk+xwsu25yVYgYnCdQgYoxOIttt6v cohD4BzJZ/leGTrfLMrCfBVBs5/3cVWZnpus1/8segAbMgGw/y896PNSK7Ws/DuLZKUw7G R6/13c8psfjbhiAxgSNNeIobP7TjDXU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Nco888oV; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf19.hostedemail.com: domain of guoren@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=guoren@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742969283; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=17ilzGvreeHm226kkfQPsyEFUeLiEMTwZ00oVMu8jpY=; b=dGPu3IEkvmvnVKhWZrdD6kuQHgPSCtkp4rkXxhkTnRA/Tr+OQ1M2n0kmZej6DGhlL1/jc+ vptECJdDSeqys834OKjgkYkhcXrS+I+oGmnc9HK3atGXZSUO/WlGSIO9nBB8ttqnZLgfGz irpJvnTOQtaXgGHw5xzve1gFreBZJ5U= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 2B83F437D8 for ; Wed, 26 Mar 2025 06:08:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B767C4CEE8 for ; Wed, 26 Mar 2025 06:08:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742969281; bh=17ilzGvreeHm226kkfQPsyEFUeLiEMTwZ00oVMu8jpY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Nco888oVkpWvjjpmwWCThvxb1AtfGv+uxSw1N4XjTkec3DRuVqc8KPvc5gyVt3uyU IV7JpaJMp0N1G9bNlo7QCS6M3AKZni7g3eSBUqYTCiax5dYr0YNhkTLa/iLtyFs7Wv HtMjo1vjIyvsz1Ery/OFJdGpHbx7zWh4Jt/U+jmcfT2/psOB/aVWJLouBgMnlcLXxi iQ6JWvJv52TlmS30JjLarPhhTiwvQVU+efwiS9Qj/9tY8Xh5NXnQExI9PhYTcscXed SkD/3WaA4QEW7XPf0f3AnBRtjzDT5qFOrBTZk3J5UH2yTDn5Ts9Hsd2ScdykbJt4y0 tZfx12/Kj/UNA== Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-43cef035a3bso44682485e9.1 for ; Tue, 25 Mar 2025 23:08:01 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVYO3FFmwteV+l5fPzMbpzMQ42uvclZs8E90UOvJrel42XSXdzl9jFEgQ/UpSfobgJHvKT6W6iM1w==@kvack.org X-Gm-Message-State: AOJu0YysFQa/HdhNErl2T+FdHwmRrzYy5Qivq+47T1vKvUACE6mEaPeo sB2c4tXqKXFeAKsY2JsVbacTldmYOnLdHX062t8g7+P2RJWlBwz4iE5HlpVmyMLNAFo4cwMs6TY dk7L/+1OyMpmhcI8OUAKNlSX3R4M= X-Google-Smtp-Source: AGHT+IEuIFNoPjN0AZZplDS08UZSXPKtCbe3v92zS/QV8r4A1uiHzUqZnFSHaB3urAWjtmc7YALAB9tDHWY70m3ocVw= X-Received: by 2002:a05:6000:1fa7:b0:390:e5c6:920 with SMTP id ffacd0b85a97d-3997f9008c2mr16208871f8f.3.1742969279888; Tue, 25 Mar 2025 23:07:59 -0700 (PDT) MIME-Version: 1.0 References: <20250325121624.523258-1-guoren@kernel.org> <20250325122640.GK36322@noisy.programming.kicks-ass.net> In-Reply-To: From: Guo Ren Date: Wed, 26 Mar 2025 14:07:47 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1JqPvj-l64SFz6C-IoAkuirA5RSoM_MAB1hbvMnwwKSuwLAnDrMsa14MaDw Message-ID: Subject: Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI To: Arnd Bergmann Cc: Peter Zijlstra , Greg Kroah-Hartman , Linus Torvalds , Paul Walmsley , Palmer Dabbelt , Anup Patel , Atish Patra , Oleg Nesterov , Kees Cook , Thomas Gleixner , Will Deacon , Mark Rutland , Christian Brauner , Andrew Morton , Steven Rostedt , Eric Dumazet , Chen Wang , Inochi Amaoto , gaohan@iscas.ac.cn, shihua@iscas.ac.cn, jiawei@iscas.ac.cn, wuwei2016@iscas.ac.cn, Drew Fustini , "Lad, Prabhakar" , ctsai390@andestech.com, wefu@redhat.com, Jakub Kicinski , Paolo Abeni , Josef Bacik , David Sterba , Ingo Molnar , Boqun Feng , Xiao W Wang , qingfang.deng@siflower.com.cn, Leonardo Bras , Jisheng Zhang , "Conor.Dooley" , Samuel Holland , yongxuan.wang@sifive.com, Xu Lu , David Hildenbrand , Ruan Jinjie , Yunhui Cui , Kefeng Wang , qiaozhe@iscas.ac.cn, Ard Biesheuvel , Alexei Starovoitov , linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, kvm@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-mm@kvack.org, linux-crypto@vger.kernel.org, bpf@vger.kernel.org, linux-input@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-serial@vger.kernel.org, linux-fsdevel@vger.kernel.org, Linux-Arch , maple-tree@lists.infradead.org, linux-trace-kernel@vger.kernel.org, Netdev , linux-atm-general@lists.sourceforge.net, linux-btrfs@vger.kernel.org, netfilter-devel@vger.kernel.org, coreteam@netfilter.org, linux-nfs@vger.kernel.org, linux-sctp@vger.kernel.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: CF2D31A0004 X-Stat-Signature: 9qkthtcjwepxk4j4z4bxyk8s9hb1k57o X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1742969282-568923 X-HE-Meta: U2FsdGVkX1/QjeNDFrCG8shlXNXyFL+H807P1vBcZS6zy9aloEoZ2i9BN5nuIkkQp+aXUIdoI8AMlccj4u+a7bI37CYl0ozLJ1Xej6O0yHOr5QQD2ZPA9rBuGxjeUml7m8iMoqvy8inVfQ084jg+ZaL04KiYLgOuzkCyxNeVO/Wqxq6fH4MXE8NRbWD1l9uaSCDZXDREAh+GYcPwl5q7z132g87exbWMXhqZDeFAnW2+5cuuV5pIj+qerRJlo/F4lbpzmPqADAAqQoriJoewaxqCcNzF8ogGaTlUUOhGUbBS4NySeAcoHZJ2rdhrIyw4kfvqqEBDNGSt0VCQui7+Q1dcAEB4nA8835/3UD38nwVos0TdiQCqm8aVc8C5r5i/yqE+S4ohY3SKckJpBx/GttUmHtf53LYsKAsaBuoqjiCLHCu7WRJKrPOj0p1NDNkxgr/hTtkLkPpwKjdfBUA08fxL6Ao7HpVfeBqI4dxAA69Y8Wy56DDbqR8Ykf3zm3r97oWv/zhB1Dk8+AwXACNGiTmKPkj2rx/SbdByVpHXaQUCtVfAq4Cum++MwzwbaPyILQ3mmtHMee70N7s8EIqjhnTUJMH8x1fnTOYciW5WklSLUYjfRhSGDJ/GFGII/hEIf41H7QHF2vhus3E9N7wXWjuE5lB5qrqQ4n8+4eguff1KBQ0O70lBmR0wGfUQ8rpYIfGNPlS2m1nOVANKEORQmt64HHxUPtvlZnK4cWjhudWXgkxMG1/7PGHWl6hHHc4h4TIoXkty2GgcDNHcX+5C/8Hue1ZaJzpZWtkn6hhzcDnd7USjD+yvbb1ySnT9T3FO69bZi1Oe/tGqcFQg82Plnj/FO1TDLQE4HItDELsG354m2VKfLcS0kWNs9tmlU3spKNLyeYqjokhV8qTg6iJCzIUrg42t5vQNted/+7l9Nj7rd6eB5zsPOnuVcZrhQeATVHaUMGTqdg8fATRhMb8 /SKBfsr/ B5OZqWimuPhW2O8GxqQmVLCwRLd1KPemNcLFHfif7W5YULSaM08tGDbWnbaOl8ugJs0O50kcmZUKFUjboBF/NcM8qcVyssjaZdQOEyDeBgZ1rNCpUDNKjh2Jlqz5FZW5dWa03xFaNFFqJAvkpJFI/HZ2zGuVL6mNSohFMiL9ieOz2J4cCbKn5iFtIfTurRikpMDR0U9EpVwEUILM1JEuUrP7Km73/VJrtHgo5nr0CKrlDheO28uhGMj1S/pTZnGT1ZSDOeDZKha2uO/0Wq0sQbAWpFErH15yE5p767Q0VCkCyHk3JdQs5kenGTik4xqYNxrRVIv9cBKHVWnJPulmlxgrDVtUcrEIVOvEFVkGVTbTJIoWMP9x5/x3OBnxUr+mlA68wU9mZzYMtij23/d+O1FtytdXr+n6qyPMiVdSd/J7MeGSxDUjxHX7va21KPBIKzOj/hvFz1DnXrzrW8nS/mEBkBjOIVjJBzNMPE37NIkEYvyFC/akdV1AIVTQ0gI7dMDcv8VMvhk2meqZCeIORt7bTi1+F5/o6XXj7fd09OZHKYbXEE+dTM+TW3vD1M9muFBG9iAixje9q2UCjL2HSSxX7rg4+0q0f6bCkiB3VSW0cNYUiOvJKhBg0Iw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 25, 2025 at 9:18=E2=80=AFPM Arnd Bergmann wrote= : > > On Tue, Mar 25, 2025, at 13:26, Peter Zijlstra wrote: > > On Tue, Mar 25, 2025 at 08:15:41AM -0400, guoren@kernel.org wrote: > >> From: "Guo Ren (Alibaba DAMO Academy)" > >> > >> 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 al= l > > 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=3D64, 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/ca= nmv_k230d.html http://riscv.org/ecosystem-news/2024/07/unpacking-the-canmv-k230-risc-v-boa= rd/ --=20 Best Regards Guo Ren