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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EF6A8C36005 for ; Tue, 25 Mar 2025 13:18:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:References:In-Reply-To: Message-Id:Cc:To:From:Date:MIME-Version:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=iEJbIDu987oR77UORlGV5IvFPgjkBN0WzfOLWndaimw=; b=WZn50vP3fpBhSz1kaRTD7GYxWP sWLEaEqMjdZqmXx8PdXm1DYZYwoyifnjL5bk6ZPkmWYzpMl3uj8Ug18JBxMeoF4eV9t1tgX+jRckP SE7oK4qQ+7UcxWrl4UR69b0CrqkNFZLK4gQAp+eohR4lsKzhAroWC1oOii2D1ToaG60LBIGKHRl1l HwfUVRXe+858CbD8wj/3g9UUMrqoHGlctG5NHjLwUnS40ZpyPMYa8dB+TxUiXKjZhQMdxU/1H1Z18 dmyTGJUAItJjRjtcyDw1Wb1SAY8XdH/sLtn9LCwEL/TSAO9rIA+s8zZmdru0SWfGZK3LOwONhAbOc 6o5HN3hg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1tx4B5-000000060Rz-1bGp; Tue, 25 Mar 2025 13:18:47 +0000 Received: from desiato.infradead.org ([2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by bombadil.infradead.org with esmtps (Exim 4.98.1 #2 (Red Hat Linux)) id 1tx4B2-000000060R4-3WzJ; Tue, 25 Mar 2025 13:18:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=Content-Transfer-Encoding:Content-Type :Subject:References:In-Reply-To:Message-Id:Cc:To:From:Date:MIME-Version: Sender:Reply-To:Content-ID:Content-Description; bh=7uJCsElQFNSpp9yzC8ZbXV0umGMGK1SA9vUHShT/4EA=; b=G+Y+PLPGq3KqRN134MwcYECwx1 Jo0/C/tGmC3tu5hB9jzVzt4Cz139rgwQcs9uUR3SgaHP45avA+RNE5uCHDMflGCDDUbW/oP0pcgYY obNFihSbTPdgLEvgzI7LIyPBos5DMsPb+oSbVzULwEC8AJzjuHGtzt/ZNyXD6oaVotstt0CiP0JOo CsJViICw3lue1baW8m0SC8ypPFv+ACn30sdClgXvDg2ZaKSnMNEmIoffQtmbqD25TeBqeCydfgOgn ClUCiy0jicjnE4W1xDGxLo40SScG5ik5kixATiPi3TYH8EgDfd25N0p1oj/LSCZL50fy87cm9n3DK IvGCGmaQ==; Received: from flow-b2-smtp.messagingengine.com ([202.12.124.137]) by desiato.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tx4Az-00000005SJX-30ug; Tue, 25 Mar 2025 13:18:43 +0000 Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailflow.stl.internal (Postfix) with ESMTP id 2825F1D4180B; Tue, 25 Mar 2025 09:18:34 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-07.internal (MEProxy); Tue, 25 Mar 2025 09:18:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1742908714; x=1742915914; bh=7uJCsElQFNSpp9yzC8ZbXV0umGMGK1SA9vUHShT/4EA=; b= RTmZlZugzrB2Xpp2UNcmLvJ2IMWE1xdWamWnVAKU5SL2JAeh+Vzm0Hxb/YmAQpL9 mEwDWbQjzIx8gVGWNo0GPuIaibxKIdPeyAEapZyop9O5Rc5uyFfdcKWj0mXXSMHV tLwO/tb+6euKYNuN8vIwReVYQNxdhZzz2I3fCYWR5ISpjQrEgrTKfSAa4Tgb96FJ NNa5zvPiac2GlPmzCNKAS2OeK8aRzxprhy6dPptHE2iTkY1G7veSKjDOshKcIkI1 NwEKOiSERdwYBqG5jZ84YGoyPos94OBmvljQjiCmF1cWxzKZZsaQrQNkJ10870a8 HF71PKpsLcSgvdnbenoHmw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1742908714; x= 1742915914; bh=7uJCsElQFNSpp9yzC8ZbXV0umGMGK1SA9vUHShT/4EA=; b=B rsqAGkTFZ3e7xsyWdPC+FXwVIENkzzxocGOEQttZ5W+XR+GQpG4zAES5j4XgeCAd eD6S/IG0JPU4POYy8+9bTeUcSTeohmduHNbYSLdztyMoKfkDfg9G2NzngxuQGixe eFxOgaxRleW2TpHUcOSW9GfofxLfMGG9wCfGXT/joYzpEbxOPO7rs3hh4UFbFfb0 Q4I0uXtwCKM17CbTMUdn151LDA7ZP089MSe7ujEUqAgobo5lJWYXNygdFIUSvaxn StCRqsm02WEA4qHGz0MwAqLsSWSHI8yWHtiBId1grcbZVOuf26de0t1VAbsZUzkt vt88I1ftKH2A7KsJ1ALJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduiedvjeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertder tddtnecuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnug gsrdguvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeet fefggfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohep hedtpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegtthhsrghifeeltdesrghnug gvshhtvggthhdrtghomhdprhgtphhtthhopehmrghrkhdrrhhuthhlrghnugesrghrmhdr tghomhdprhgtphhtthhopegrthhishhhphesrghtihhshhhprghtrhgrrdhorhhgpdhrtg hpthhtohepphhrrggshhgrkhgrrhdrmhgrhhgruggvvhdqlhgrugdrrhhjsegsphdrrhgv nhgvshgrshdrtghomhdprhgtphhtthhopegrnhhuphessghrrghinhhfrghulhhtrdhorh hgpdhrtghpthhtoheptghuihihuhhnhhhuihessgihthgvuggrnhgtvgdrtghomhdprhgt phhtthhopehluhiguhdrkhgvrhhnvghlsegshihtvggurghntggvrdgtohhmpdhrtghpth htohepphgrlhhmvghrsegurggssggvlhhtrdgtohhmpdhrtghpthhtohepsghoqhhunhdr fhgvnhhgsehgmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id DF35E2220071; Tue, 25 Mar 2025 09:18:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: T218a0d8b70d1a53d Date: Tue, 25 Mar 2025 14:17:44 +0100 From: "Arnd Bergmann" To: "Peter Zijlstra" , guoren Cc: "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 Message-Id: In-Reply-To: <20250325122640.GK36322@noisy.programming.kicks-ass.net> References: <20250325121624.523258-1-guoren@kernel.org> <20250325122640.GK36322@noisy.programming.kicks-ass.net> Subject: Re: [RFC PATCH V3 00/43] rv64ilp32_abi: Build CONFIG_64BIT kernel-self with ILP32 ABI X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250325_131842_055604_5798EAE1 X-CRM114-Status: GOOD ( 19.41 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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 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. 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!). 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. 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? Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv