[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <6d325ce0-f5b6-4e81-9f66-d48d1e9e2000@nvidia.com>
Date: Thu, 22 Jan 2026 19:09:20 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Gary Guo <gary@...yguo.net>, Danilo Krummrich <dakr@...nel.org>
Cc: Alexandre Courbot <acourbot@...dia.com>,
Joel Fernandes <joelagnelf@...dia.com>, Alistair Popple
<apopple@...dia.com>, Zhi Wang <zhiw@...dia.com>,
Simona Vetter <simona@...ll.ch>, Bjorn Helgaas <bhelgaas@...gle.com>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, nouveau@...ts.freedesktop.org,
rust-for-linux@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Gent Binaku <binakugent@...il.com>
Subject: Re: [PATCH 01/31] gpu: nova-core: print FB sizes, along with ranges
On 1/13/26 6:23 PM, John Hubbard wrote:
> On 1/13/26 5:28 AM, Gary Guo wrote:
>> On Wed Dec 3, 2025 at 5:58 AM GMT, John Hubbard wrote:
> ...
>>> +pub(crate) struct FbRange(Range<u64>);
>>
>> How useful do you think this is in general? Would it make sense to have a
>> dedicated PhysAddrRange type in kernel crate that provides this feature?
I still like this general direction.
>
> Pretty useful. Yes that sounds like a good move. And I see from Miguel's
> reply that Gent Binaku (+CC) has a patch that proposes adding a
> PhysAddrRange. I'll go review it in detail.
(correction: PhysAddr, actually. No PhysAddrRange just yet.)
OK, I looked into this in some detail. Based on my experience with this
area in HMM (a linux-mm feature that deals with both CPU and GPU memory
addresses), I'm pretty solidly convinced that PhysAddr is meant for CPU
physical addresses.
FbRange, on the other hand, is intended for VRAM (a GPU's dedicated
memory), which is often in a separate address space. So these should not
be the same Rust type. We'll likely want separate types for CPU, GPU
(or "device") memory, and even DMA memory.
In order to avoid seriously derailing the review of this Blackwell
series, I'm going to continue that thought, in more detail, as part of
my review of the PhysAddr patch [1].
Meanwhile, I propose letting this aspect of this series remain as-is.
[1] https://lore.kernel.org/rust-for-linux/20251122055256.264180-1-binakugent@gmail.com/
thanks,
--
John Hubbard
Powered by blists - more mailing lists