[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1eaf66ba-b2d3-448f-938b-913f17ca98a4@redhat.com>
Date: Tue, 4 Feb 2025 11:33:24 +0100
From: David Hildenbrand <david@...hat.com>
To: Asahi Lina <lina@...hilina.net>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Jann Horn <jannh@...gle.com>,
Matthew Wilcox <willy@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>,
Danilo Krummrich <dakr@...nel.org>, Wedson Almeida Filho
<wedsonaf@...il.com>, Valentin Obst <kernel@...entinobst.de>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
airlied@...hat.com, Abdiel Janulgue <abdiel.janulgue@...il.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
asahi@...ts.linux.dev
Subject: Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and
physaddr conversion
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<T> and an Ownable trait. These are
>> similar to ARef<T> 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<Owned<Page>> 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".
So in the future, this interface here will likely look quite a bit
different.
(I know there was a discussion on that on RFC v3 with Willy, just
stumbled over the usage of "folio" here)
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists