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 3D7D5C36008 for ; Wed, 26 Mar 2025 06:56:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0A7428005F; Wed, 26 Mar 2025 02:56:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBBE0280056; Wed, 26 Mar 2025 02:56:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5CA028005F; Wed, 26 Mar 2025 02:56:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 87353280056 for ; Wed, 26 Mar 2025 02:56:28 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 57E98141CF7 for ; Wed, 26 Mar 2025 06:56:28 +0000 (UTC) X-FDA: 83262793656.04.338FC1C Received: from flow-b6-smtp.messagingengine.com (flow-b6-smtp.messagingengine.com [202.12.124.141]) by imf05.hostedemail.com (Postfix) with ESMTP id 35D46100005 for ; Wed, 26 Mar 2025 06:56:26 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=kDfp1JcO; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="L wLKFnj"; spf=pass (imf05.hostedemail.com: domain of arnd@arndb.de designates 202.12.124.141 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=pass (policy=none) header.from=arndb.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742972186; 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=ECmdnGpGt7R784A69CvkoNMp+aXiuLAMl/bxf3OLtmI=; b=JpcBL+q3VZDdM6gs6W7EBA9QbIPbFKzO8LxdiiOv5HTkRPl48MfXzinf8LhtIKw01mwUam HwdM2OxQmHIqS0geRDMDuxTU2yGJMdpGmcGkG4KNNZgv75KN6Ay87qB58pjXi6ha8SNwmA hnvC1+QzR/YlTe37gryuC8XTt166JoU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742972186; a=rsa-sha256; cv=none; b=x/flMiKMgbkTEzFa7ng0/06DYu7sSk0XsjjxkEI1fwKNWAANXvE+hxc1Vbr10jzlosydvk bTVF+NPbe9X3fTz2hUoHVBgNG1lrX9UhBgG8SNdDMza7DVtN0UUHO0B7nlvs/oirYX8jc0 TQCM53MvvzNrlMALabW6+OMSA5DF3RA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=arndb.de header.s=fm1 header.b=kDfp1JcO; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="L wLKFnj"; spf=pass (imf05.hostedemail.com: domain of arnd@arndb.de designates 202.12.124.141 as permitted sender) smtp.mailfrom=arnd@arndb.de; dmarc=pass (policy=none) header.from=arndb.de Received: from phl-compute-07.internal (phl-compute-07.phl.internal [10.202.2.47]) by mailflow.stl.internal (Postfix) with ESMTP id EE8A31D41505; Wed, 26 Mar 2025 02:56:23 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-07.internal (MEProxy); Wed, 26 Mar 2025 02:56:25 -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=1742972183; x=1742979383; bh=ECmdnGpGt7R784A69CvkoNMp+aXiuLAMl/bxf3OLtmI=; b= kDfp1JcOTJJTTyJssul1zn/CcQe7Itgl8uG+6lVBUWsy5Y84lTm/Dj6eIDlIWV0W zx302OMerzA0hE/ghjdyqnHuYzSlRy2kdVTM0KueelvnPp3NpbSFt0oRiFoaXzbO lWuYvEaCj5qKK6Zc6IizJO2AQYpns+Yd/8wvdazYa61rmm0JlGYgC4pxo6X2Pbc6 WYVmF3Eh2RWWiOwdhhVTmXz3m8DQw0UvAu8HD+eG7/sESegP1qryjfZk+QkuAw7m HfYcEzO0L5sZdQ0ZORPc65EuP3iJHCAwRPY2/VIMBsbh+vU0EAlP8jrUV2S3Zrmm TPYH7Y3dwHkVBI2+mC8P2A== 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=1742972183; x= 1742979383; bh=ECmdnGpGt7R784A69CvkoNMp+aXiuLAMl/bxf3OLtmI=; b=L wLKFnjcxtSj11hlHzYXkPz+saypP392BUg14l9VmeGcPzntpMEUqG8V0uW/IqpeG +o9xK5wFshKTDRWmwcqM9eFjgEyVB+pWkVVHX8PuA69DzmjH6KhpOrcDjGb9gR+4 qr2hrziuvLkezI1G9bUpNct7YoeHTl4cpqTdeV8/MiGaJ+mYdj7SPlUo6IopFW77 ZUUxHmcQiJrb3IYSLCFtYccBoRcd0rPQjv+MMoONgz10cyqNLlhz8gDN8QGkQi0b nxewlH+zU79n3ein3A1l94c1VzhzuCVNLzVXZ0SkrH5/McvKIx7gdDhGh9rBmkXu 4XqH4uenW/vOkamVGjDNg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdduieegkeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnegohfhorhgsihguuggvnhffohhmrghinhculdehtddtmden ucfjughrpefoggffhffvvefkjghfufgtgfesthhqredtredtjeenucfhrhhomhepfdetrh hnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrght thgvrhhnpeffffeghffftdejvddutefhfeetiedthfegfeekheekhfejvefhleejhedvke ehteenucffohhmrghinhepgihrvhhmrdgtohhmnecuhfhorhgsihguuggvnhffohhmrghi nhepgihrvhhmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohephedtpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegtthhsrghifeeltdesrghnuggvshhtvg gthhdrtghomhdprhgtphhtthhopehmrghrkhdrrhhuthhlrghnugesrghrmhdrtghomhdp rhgtphhtthhopegrthhishhhphesrghtihhshhhprghtrhgrrdhorhhgpdhrtghpthhtoh epphhrrggshhgrkhgrrhdrmhgrhhgruggvvhdqlhgrugdrrhhjsegsphdrrhgvnhgvshgr shdrtghomhdprhgtphhtthhopegrnhhuphessghrrghinhhfrghulhhtrdhorhhgpdhrtg hpthhtoheptghuihihuhhnhhhuihessgihthgvuggrnhgtvgdrtghomhdprhgtphhtthho pehluhiguhdrkhgvrhhnvghlsegshihtvggurghntggvrdgtohhmpdhrtghpthhtohepph grlhhmvghrsegurggssggvlhhtrdgtohhmpdhrtghpthhtohepsghoqhhunhdrfhgvnhhg sehgmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id DB88E2220072; Wed, 26 Mar 2025 02:56:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: T218a0d8b70d1a53d Date: Wed, 26 Mar 2025 07:55:17 +0100 From: "Arnd Bergmann" To: guoren 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 Message-Id: In-Reply-To: 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 35D46100005 X-Stat-Signature: rmp8e3d8aw45ubptzmiq5tzayb6h1u7e X-HE-Tag: 1742972186-503177 X-HE-Meta: U2FsdGVkX18UCoF7K7OrE2ActGt/mEvRglaFCOGQzjcOkvizjstSA0evTXKOX8Q0h4IDFp+RlVo7/bthdkShgMbY+B8a6S8phTElfSgo36/4/ZwG3xjdPRmOqjsaramubO7E3UiiKDMHVrTniKs0cogk93pcLhMG1v4dgoXxYdMxMRd0Ob5ppcHk6YGfHhZABOzn0sdJJEwsXfFe43Ojh5U4VHgWllMRfYKsNlCfpmNXgEiBKlgHNEnTHIolSar1Xj8drfqhnk/se8vZXHL0oe0W+ZOXH6IDlut6bOCZJbBEirOiEZLiSqYuXfn8Kq39GQHL6uyqtI6WcxuYWG1gCGgfBmdlUvX8i8iBTfwynVMVIxzeLZxYGxEGZThS9wizZfYbCVR7hsWkZYl4iOAwBaVf+CqsVZHY7Qi21jv1ELenJl5r2qePxF/fDJs+dEOvjL4IF93+KhYn4fNR3gwY0F3fuhYX66FhVQ8M900PxGFmmTnWeB3HEPYmV0+9FCRZrev+aNPV4LH8jXrO3YljHqSiEzeMphKVrZ8kzJ3ZLRoLJRHbaeYDaKnQ7LuppZv+69EDij8afuwvwiPkcv+Zo1NSM8k56xs3lyxoFPzqkcRRsxUoX5Oxj3SibZpXivvy6R49QKMov/1gRCghW/BkX1tccm3JPI/Tp7th5/cNtAWIh0o4+Th6XL65U7wXfMxQFghU4BEs/osp/7uCiakrdlGqV/+THPENnM2WbV6UUrR/PhJQP5HHFAjVMqVhuD4OqUU/+XL5Or4P9IeNGyokpKQg2Qs8NpHggOc64Wm1YA0Lrpl9lQZGZZCe+9ZUKKNFUIRANMvXfOIbQyVzo/5Rq/MGlDiFcV3YUydzhU/YU0j9amno6tqtKJpvFJBztZ7j1f32o5oIJb1bKWL4hJXAsiWQTa/HWDG7WXgO230JUkzdeijusLESopUd3RFBKxHxvpcKF1lunIA9VOnuLjW rkoGcO49 oGokLez/MHB/j8i8x5EG45985Gj+Ygl7l15UNjiWVibtKJOM9Dv3LcwSN2Qj9uR7K2vmQQF7BKOO5s9enuJ1e4R10b+7/cXuxwiC8J7wtBUyl2jOmXAmnvK9cV3LfmO6p0bgXbb4PV0kCOyClio5AsdNu2J++XDsftE/3llxBmcBmyX4FVAtrOJhgM9i5bt8z8X6Cs2NjI44RsmtWrNc0KrQ8KB9P21Kjuy5RvBboJDwZkdvMkFT315hZtL13UM47YAPr3ehci7E7wdmI4km4S2Xm6fa9m5kI9HgUEQ4CNKLmhFfy+1WVzwN/slviU3eZX+z2uJMMzapmYcMdso4Uw57bmo3QblQNy1SQ8+pXzko5K4KUr1IbopRctPQTqrLQG91XoVfEC5rM/gqOINh5ngHrmaIIZvNOYiyHZodF8c6lL1EP/s49/UXiRRHXzgNcJGT3Uiq4ZXk5enT6kbfKjxVdQkwWYxNRtvrD 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 07:07, Guo Ren wrote: > 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: >> >> 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. =20 > 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