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 99D9AC3600B for ; Thu, 27 Mar 2025 13:14:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 67B622800EE; Thu, 27 Mar 2025 09:13:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 605282800E4; Thu, 27 Mar 2025 09:13:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A6B82800EE; Thu, 27 Mar 2025 09:13:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 2970D2800E4 for ; Thu, 27 Mar 2025 09:13:59 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 87D7F140D56 for ; Thu, 27 Mar 2025 13:14:00 +0000 (UTC) X-FDA: 83267373840.04.5BED4B2 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf13.hostedemail.com (Postfix) with ESMTP id A134020010 for ; Thu, 27 Mar 2025 13:13:58 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vPWU2EP+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1743081238; 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=oawZ5DQCvYYy8AvTgHWAnmn3QH5U7JaSsU9gal2V+0g=; b=2PuhRPBN9+B9zhYktBps+QDcib8zXGiKowOzKCPrMBJcuPSX0rXO1z3N/x29POCvQvyfvV z2j9BVKo8wpSTTh0xlMkrPGR8V8PtU+JgqmsIQhWjpP2qgpiN3wWqMSOlECTM2kvuACeph ZQefBcNKt8e4adAVc2CKBGDsKUog1fY= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vPWU2EP+; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf13.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=1743081238; a=rsa-sha256; cv=none; b=OmnPg1nCqbN1rt8B27OXaEHYuuO+v3+dn8LQWrvwBkoSJkd8lUHZYmT2+g3O9WJuqQIp2C gMUgPT6lmAL+Czf614h0O0Gp37Hpm/SquEsVIcqmCwZ4jjLaRfzCx9se/pmfGj9QsCZ+YI opmS6bwtrqVEAoaWQojhXkNAM6//yTU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E6F6744B66 for ; Thu, 27 Mar 2025 13:13:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32991C4CEEA for ; Thu, 27 Mar 2025 13:13:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743081237; bh=fKz9pnQ+RHCIb1EIYOpjNQk9UHkPlQZ8YelVCnzImCE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vPWU2EP+vla73VGaagp0gakCZbfnpMd6n3U1ym3pAL/ZFQdsoIsI6ZKtqN8TXbEM1 9onvg6std8I9/wXtLvdJs+K+mCzOGzZhz1pFLA2ixFsOeqtTQghmI8qYe9S9QyvarJ daRdEkvMM6qfIunF3iMtD1MZ2Zg0G72S6cuYMaIFWUujkH6WcGiF6Dc3YhPRe0K+YS /H0XGrNIW4/lA+KFRPK7Yiy7tRW1c+W9gQamnws2oTCijwpZoM/e09sj0S4o+fR70+ S0kQ0ggNxsF6V7sNtB1KqpGT+AQPwKvoC1wnStGFOlJvaaLcNKb4fGxrXtfKG4PFh9 rGNsSERDGHStg== Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-43d04dc73b7so10716855e9.3 for ; Thu, 27 Mar 2025 06:13:57 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXTx1aVpWcHtNQcFFLVn2sOsEa7H6TaHnZX3Ej6exFLw4j7ssvD8ECfJbfM/fNo0mspJFCs81PA+w==@kvack.org X-Gm-Message-State: AOJu0YxYJHSbn9GE++tDqRtJUZMT8HH2ZZCgSEEfg5PJH6rXp7fAMC5Z 1/3/b2juR3zst9qU7x7MV8o5+UKt7EaOx3clrVn3ywsxEm5SFtCqyG4iiPkY4NcOGaZF3iG7qxA KY/M0gI91NjDdtCEUc4QtzejgTPs= X-Google-Smtp-Source: AGHT+IEY5BSiBwNXEMT+eJeprlWhvYaVjud2VavXTPTPRvbe/6IFqzcZmwQqb+uo+KChSyUJAdyAvfkgwaIRQv6W9xk= X-Received: by 2002:a05:6000:1ace:b0:391:29f:4f70 with SMTP id ffacd0b85a97d-39ad17544e8mr3039357f8f.3.1743081235006; Thu, 27 Mar 2025 06:13:55 -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: Thu, 27 Mar 2025 21:13:43 +0800 X-Gmail-Original-Message-ID: X-Gm-Features: AQ5f1JrgAJHOCdrriP16_V_QmEg1YQ85TRRC6Mrmapp2zXhvmV1mwcc9X_F3CrI 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-Server: rspam01 X-Stat-Signature: a43yhu9f1j6ckih439qdrrke8f78a4jj X-Rspam-User: X-Rspamd-Queue-Id: A134020010 X-HE-Tag: 1743081238-567871 X-HE-Meta: U2FsdGVkX19KE934VGaJCSZwOo6gqzC59jkKGdpks4wOkETvnjIvrQ/ygxZ6oAQ1z0Wat8ox4RdTqbUmWZp/Bn/gKbDn8/lpF3+1pFwf0P/saVSJKxrafnLBZSmJoTr5o2ffGUOGiqnAJrLMvyvK8ruY04t2VVHZR6IF3OSDTQUDawl8KLQuGmahCfgG2tD/6mB6MCKgOl8EYQI854C4X3tj7M6IaWknC+BDSnmBdlphGcZLmyMC8+vnT3xE3vobYyYyKuLZY/nWshNKbCNGP56CgP3aW9eXcPZ9P6HbjyxgOwf7RBY3Ps0vys9hteb15Ay1/RwK4kJKv+X9c6XgI4nYn6JQsrx7LleGJH27KQOqNfMQl5oB4hZ0NjDCG3xTYYbgSDDPfrDucfLp/WicXsEy/BgfETFA9KHPdYIlRyfYylazwBkE1bzQUHcAgCf/PUc58V8h/uZSyU/TccsJnsdXZfwJuwhDvdtv+cCM/NPWq1W0hB4wRJrNiRGN0xQfvsJgvdfKKW2XVwcKo5gVuQKz2Xhkphd02mxWVjslgvKZrGafhoTC1FPB89VPtD5vLx6j7Hv+hYhxnBv0mNfQjMkCpS6xtTzmPr0fpVe0RMsiyBE3dVQNSHKfXj5Eoku3ehHCqyxJkTOf+zfzvWEVnKZPLGRD9Y6TEfsMJIy9keU3TdnZORFJG5Q6dKqe3RrlWDBN4NDz5WNtIXDTtaqwEfys0MWvJ/mzYE2e1ScmO1gJHTx2dsuTKYGwJCFNa7NijsaR7Ovld2CDsnXFXtmRXvMzrJsoYLqzdhyJNBjTL72C1hlVM0Mnk9F5DtiUUDvH8abpmp9yMxq9912w/e+yxCkF+5bOWxnNlTIGWAsqP1VO3651VHLPv1PN4QYa3PFlsD+kqG+pkKMzJg/4ekIgMKIVY7NzouC1IPop8YTovSVgmbg9fboGLnB4dU3+TFu9B+ehdJeZHNCkfsaaBWU g4SQ5IQz u/o3P74b6rMN7E3aLBNArL6HKVfnkL7GWaaYPGHoBMMyRjPaLYyWYqN/DNCIFy9dSmnEbi6LKPNGcQXZ48Fp9jCq4ASYpMqzvYp1TfxczNgOoRqI= 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 Wed, Mar 26, 2025 at 2:56=E2=80=AFPM Arnd Bergmann wrote= : > > On Wed, Mar 26, 2025, at 07:07, Guo Ren wrote: > > On Tue, Mar 25, 2025 at 9:18=E2=80=AFPM Arnd Bergmann w= rote: > >> 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: > >> > >> 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. Got it. > > >> 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. Got it, thanks for analysing. > > > 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. In my case, most binaries and libraries are based on 32-bit, but a small part would remain on 64-bit, which may be statically linked. For RISC-V, the rv64 ecosystem is more complete than the rv32's. So, rv64-abi is always necessary, and rv32-abi is a supplement. > > >> 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 > --=20 Best Regards Guo Ren