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 627B3C02194 for ; Tue, 4 Feb 2025 19:01:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE38F6B0085; Tue, 4 Feb 2025 14:01:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B93856B0088; Tue, 4 Feb 2025 14:01:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A82526B0089; Tue, 4 Feb 2025 14:01:10 -0500 (EST) 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 896AA6B0085 for ; Tue, 4 Feb 2025 14:01:10 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 510B41C8465 for ; Tue, 4 Feb 2025 19:01:10 +0000 (UTC) X-FDA: 83083179900.03.9F56D9A Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by imf10.hostedemail.com (Postfix) with ESMTP id EE220C001C for ; Tue, 4 Feb 2025 19:01:07 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=D+MPcFU6; spf=pass (imf10.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738695668; 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=DsukndAcD3lOELO0QKu1nmtz4ZNViX4UEvj1uLkVygw=; b=5rcUk/7uyn1jx2iyKdmEzBIJ2q9w+r8VGu/jIiym+2JiCscRYP38OJYe8V+xfXmIBmak/o kPFW/Z2SLSIYT4/qrQiZxfGz0Rz1lKugpSSAbcPeAbt7Y6uv8C7Z29cOXviN+PZS5Qs7Qx NYP7gwRABJ4iO6UyCI4zaV1VUPMMPjw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=D+MPcFU6; spf=pass (imf10.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738695668; a=rsa-sha256; cv=none; b=Mao1dgAhNddPUshuvIUO8D3VJR3QM1HEyfs5Ky7GEa96S8tlBgRqFZz95Xxn7NwEOOoZMp TIt/KRAnhB3Dd4GexI7BBm21WxfuPIjyZfF7uQV9UhbCGrEwiUeyhpBw0r7DpNZMt8oOu+ Gh9EpKsqzNF3IBzY+kF5Ejbr+lvbfP8= Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lina@asahilina.net) by mail.marcansoft.com (Postfix) with ESMTPSA id 74ACC4331F; Tue, 4 Feb 2025 19:01:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=asahilina.net; s=default; t=1738695664; bh=j1HluQu+SfdI+WQgxoy9vEPWh80MpLWIZgMzLSmRvYY=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=D+MPcFU6p7Oo9Mj2A5QSdzn1y0txF2ESXFgZr9fCpXslAfcOiJWqRv4V4SEEJVOdp Snd0CK4TdO1U/Hi8JyMT6pzpxto8YIbGDbZAcbXUCbkw9afGkdU45x8wx5vm3iK/yA p2KQISHYMO4KSpY/Vihk5csasR741Txi+1AlcYIEyvZ+qcF7Ka7qgGylGx2ElaliIs jSbP8IGjGuMCH3uzs5PCfmZra3uMXrBCF2QG5JwJ7EWwnajzRnXsNBVSWsK/uKUqMb hYDSZdgqjaSr9ggJhpZqsbcYaE3P7EBg8lJQpClqAGvZTZ7RIC6+16BktEzYyXw6Co otXaMNP5KhvQA== Message-ID: <7253bfc0-9a49-4d0e-a7de-43069e6b2e5f@asahilina.net> Date: Wed, 5 Feb 2025 04:01:00 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and physaddr conversion To: Jason Gunthorpe , David Hildenbrand Cc: Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Jann Horn , Matthew Wilcox , Paolo Bonzini , Danilo Krummrich , Wedson Almeida Filho , Valentin Obst , Andrew Morton , linux-mm@kvack.org, airlied@redhat.com, Abdiel Janulgue , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev References: <20250202-rust-page-v1-0-e3170d7fe55e@asahilina.net> <1eaf66ba-b2d3-448f-938b-913f17ca98a4@redhat.com> <20250204183933.GJ2296753@ziepe.ca> Content-Language: en-US From: Asahi Lina In-Reply-To: <20250204183933.GJ2296753@ziepe.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: EE220C001C X-Stat-Signature: 7qj9hrk7zyqwn495pz9tri9ukdthew77 X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738695667-280820 X-HE-Meta: U2FsdGVkX1/++8HvJOnVfTWdENHgo0TrdNwWWwjhf7sdaUGnJhSBl903CSDZXxWHo3HVOJFYstjKSdF+uQ/T081m5ARwYtuRKGG2F0gGJvQQeAZqqsqTWmf+PcXnaRLL/ELQ0CKWrGtIMI3BV+VAYMGYwwCLwMNMj7fpEePpwxfTozdQgcI1G/JMaL74VT1wA3N0hiRmAIVQBrok5JKGadFscOlGkGpEEfpZCtwOGay/7c7Fw1MI8BlvI2+Yo5UszGA9mpSKcutgna4bX3bU5Zvr3UhFN5PNOE4CqYa396PO88Yb+UeXGND21PKPumqLZJWLqMN2LndjybZGCC3nS5C42Xj9uoRuaSwf8MbUvtCnB7xwDlSYGjeyk9KJTiETpdBuEpUxpRdA3nG5X2ok5+Pz//9ThskdjXCoTfrBJUC1kgC0t4PrtNiiSrU43zblraoNr4fT2hI7l8dL7jckP+OFvQO5oX3bIU6mqN7k+faE5atzmZVlcNvkmiZi7p9DG+sQbvp670i65LYLWXyEoYqlRWIhEIHSMwEfTAibdDiQE5XUzWRpCaubIVL/Uufbmgi2zXfbtT+cqJKYUclyyDnhPN2PDTcXqE3U+ZEXK0uQguZifcPo85I89UEGF6x5RtxeEr7Pv6AXF/lDZlbyiza/yWhA9c2QdEL/u6eOfywWuSuQIYy9enRPvhTdLgrR9khoJCr4coeVRZaj6WDl8AfJkbM6ltbqzxtkkPjjc8/XE14FCTGNsSaPk4a03DuTCBguSYymqPlkX+2Ws8t2PyAyHr7s4iuBWZ77IxfbCnWDw+vTVODLjKOqXG6jK9PY6q10aypED87Nxze3QK28AQB08P5mdh5XoIsWxMwX1niCVDWRKVLxujhieaPKVhlfurCCdTdbloIBNd6+rwXvvbXaNght59KCVFG8e5fw3RpOXwMOB32lr3TIA5GeLeTtPR99W7h4NA7jsSfzmij rc6oxo3p zCcHI3rtNHLVLYx1gCmvN7DQb6herRR1yochQwsgpnFAg2WiqW1M1O96K17YzqVoTUrS+in+SvZK5cNyZloNJ8Mwm+9pncshX7V8ui4DvulhM7UTYXv/KUA9x4p2ihTRym7cmEPVlUDubJoPohRL4Uf74xDS7oGKU99aMGZ436JlqGFbci3PCBXzW8drgr+7Sw9dnSVdQNdPJjO6lSeZmSvuehBMSQUS++7cDdUwjS0n9N96P+MTRd5tcT4Q1GsptxO+ZsnDgsKjV9K+ZnAOFyYyfQgVPwr8TOF3nCX4mrvrOwC5CtuWGf8oLOl2lVzicqltLuN89qdeWAgipM6FroRkHZCJKh5bNkQubX0G+jgh/n/Jt10MwbM9oTIwJBC8I17Wm5hfyz41lqEL5FX/ZzkBNzduiiLwkvPU6/TkL5wrOr+WCwYWgcDvvW5YkccriwhEN X-Bogosity: Unsure, tests=bogofilter, spamicity=0.476931, 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 2/5/25 3:39 AM, Jason Gunthorpe wrote: > On Tue, Feb 04, 2025 at 11:33:24AM +0100, David Hildenbrand wrote: >> On 03.02.25 10:58, Simona Vetter wrote: >>> On Sun, Feb 02, 2025 at 10:05:42PM +0900, Asahi Lina wrote: >>>> This series refactors the existing Page wrapper to support borrowing >>>> `struct page` objects without ownership on the Rust side, and converting >>>> page references to/from physical memory addresses. >>>> >>>> The series overlaps with the earlier submission in [1] and follows a >>>> different approach, based on the discussion that happened there. >>>> >>>> The primary use case for this is implementing IOMMU-style page table >>>> management in Rust. This allows drivers for IOMMUs and MMU-containing >>>> SoC devices to be written in Rust (such as embedded GPUs). The intended >>>> logic is similar to how ARM SMMU page tables are managed in the >>>> drivers/iommu tree. >>>> >>>> First, introduce a concept of Owned and an Ownable trait. These are >>>> similar to ARef and AlwaysRefCounted, but are used for types which >>>> are not ref counted but rather have a single intended owner. >>>> >>>> Then, refactor the existing Page support to use the new mechanism. Pages >>>> returned from the page allocator are not intended to be ref counted by >>>> consumers (see previous discussion in [1]), so this keeps Rust's view of >>>> page ownership as a simple "owned or not". Of course, this is still >>>> composable as Arc> if Rust code needs to reference count its >>>> own Page allocations for whatever reason. >>> >>> I think there's a bit a potential mess here because the conversion to >>> folios isn't far enough yet that we can entirely ignore page refcounts and >>> just use folio refcounts. But I guess we can deal with that oddity if we >>> hit it (maybe folio conversion moves fast enough), since this only really >>> starts to become relevant for hmm/svm gpu stuff. >> >> I'll note that in the future only selected things will be folios (e.g., >> pagecache, anonymous memory). Everything else will either get a separate >> memdesc (e.g., ptdesc), or work on bare pages. >> >> Likely, when talking about page tables, "ptdesc" might be what you want to >> allocate here, and not "folios". > > I just posted a series to clean up the iommu code that this is > cribbing the interface from: add an ioptdesc, remove all the struct > page from the API and so forth: > > https://lore.kernel.org/all/0-v1-416f64558c7c+2a5-iommu_pages_jgg@nvidia.com/ > > I strongly suggest that rust not expose these old schemes that will > need another cleanup like the above. Page tables just need an > allocator using simple void *, kmalloc is good enough for simple > cases. > > Drivers should not be exposing or touching struct page just to > implement a page table. iommu-pages.h looks like a private API internal to drivers/iommu. Is there a plan to move that out so it can be used by non-iommu drivers? If you think I should just use kmalloc, then I guess I could literally just use KBox where PageTable is just a wrapper around [u64; PTES_PER_PAGE] with an alignment attribute, or something like that. I guess then just virt_to_phys() and back for the PTEs? So we still need to add at least trivial wrappers to export those for Rust drivers to use. I still need to be able to grab pointers to leaf pages for the crashdump page table walker code though, and I want to keep the pfn and memory type checks to make sure it won't crash trying to dereference the page contents. So we also still need those too. I'm not entirely sure what a higher-level Rust abstraction for this looks like at this point, or whether it makes sense at all instead of just trivially wrapping the C helpers... I don't particularly mind just writing this part of the driver code "like C" (it's pretty much the lowest-level bit of code in the driver anyway) but I guess we have to do some thinking here. Maybe this is one of those cases where we just do it ad-hoc for now, and wait until a second driver that needs to implement page tables comes around and we figure out what can be shared then, and what the API should look like. Hmm, starting to think maybe these should literally be impls on the address types (PhysicalAddr::to_pfn(), PhysicalAddr::to_virt(), etc.). Though that won't work without newtyping everything, but maybe we should? ~~ Lina