Message-ID: <ace23f5a-f4cb-44d6-a0d6-f3b72440394f@nvidia.com>
Date: Wed, 4 Feb 2026 20:00:50 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: Dave Airlie <airlied@...il.com>
Cc: linux-kernel@...r.kernel.org,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Simona Vetter <simona@...ll.ch>, Jonathan Corbet <corbet@....net>,
 Alex Deucher <alexander.deucher@....com>,
 Christian König <christian.koenig@....com>,
 Jani Nikula <jani.nikula@...ux.intel.com>,
 Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Tvrtko Ursulin
 <tursulin@...ulin.net>, Huang Rui <ray.huang@....com>,
 Matthew Auld <matthew.auld@...el.com>,
 Matthew Brost <matthew.brost@...el.com>,
 Lucas De Marchi <lucas.demarchi@...el.com>,
 Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
 Helge Deller <deller@....de>, Danilo Krummrich <dakr@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>, 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 <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
 John Hubbard <jhubbard@...dia.com>, Alistair Popple <apopple@...dia.com>,
 Timur Tabi <ttabi@...dia.com>, Edwin Peer <epeer@...dia.com>,
 Alexandre Courbot <acourbot@...dia.com>, Andrea Righi <arighi@...dia.com>,
 Andy Ritger <aritger@...dia.com>, Zhi Wang <zhiw@...dia.com>,
 Alexey Ivanov <alexeyi@...dia.com>, Balbir Singh <balbirs@...dia.com>,
 Philipp Stanner <phasta@...nel.org>, Elle Rhumsaa
 <elle@...thered-steel.dev>, Daniel Almeida <daniel.almeida@...labora.com>,
 joel@...lfernandes.org, nouveau@...ts.freedesktop.org,
 dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org,
 linux-doc@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
 intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org,
 linux-fbdev@...r.kernel.org
Subject: Re: [PATCH RFC v6 03/26] rust: gpu: Add GPU buddy allocator bindings



On 2/3/2026 10:55 PM, Dave Airlie wrote:
>> +///
>> +/// These flags control the allocation behavior of the buddy allocator.
>> +#[derive(Clone, Copy, Default, PartialEq, Eq)]
>> +pub struct BuddyFlags(usize);
>> +
>> +impl BuddyFlags {
>> +    /// Range-based allocation from start to end addresses.
>> +    pub const RANGE_ALLOCATION: usize = bindings::GPU_BUDDY_RANGE_ALLOCATION;
>> +
>> +    /// Allocate from top of address space downward.
>> +    pub const TOPDOWN_ALLOCATION: usize = bindings::GPU_BUDDY_TOPDOWN_ALLOCATION;
>> +
>> +    /// Allocate physically contiguous blocks.
>> +    pub const CONTIGUOUS_ALLOCATION: usize = bindings::GPU_BUDDY_CONTIGUOUS_ALLOCATION;
>> +
>> +    /// Request allocation from the cleared (zeroed) memory. The zero'ing is not
>> +    /// done by the allocator, but by the caller before freeing old blocks.
>> +    pub const CLEAR_ALLOCATION: usize = bindings::GPU_BUDDY_CLEAR_ALLOCATION;
>> +
>> +    /// Disable trimming of partially used blocks.
>> +    pub const TRIM_DISABLE: usize = bindings::GPU_BUDDY_TRIM_DISABLE;
>> +
>> +    /// Mark blocks as cleared (zeroed) when freeing. When set during free,
>> +    /// indicates that the caller has already zeroed the memory.
>> +    pub const CLEARED: usize = bindings::GPU_BUDDY_CLEARED;
>> +
>> +    /// Create [`BuddyFlags`] from a raw value with validation.
>> +    ///
>> +    /// Use `|` operator to combine flags if needed, before calling this method.
>> +    pub fn try_new(flags: usize) -> Result<Self> {
>> +        // Flags must not exceed u32::MAX to satisfy the GPU buddy allocator C API.
>> +        if flags > u32::MAX as usize {
>> +            return Err(EINVAL);
>> +        }
>> +
>> +        // `TOPDOWN_ALLOCATION` only works without `RANGE_ALLOCATION`. When both are
>> +        // set, `TOPDOWN_ALLOCATION` is silently ignored by the allocator. Reject this.
>> +        if (flags & Self::RANGE_ALLOCATION) != 0 && (flags & Self::TOPDOWN_ALLOCATION) != 0 {
>> +            return Err(EINVAL);
>> +        }
>> +
>> +        Ok(Self(flags))
>> +    }
>> +
>> +    /// Get raw value of the flags.
>> +    pub(crate) fn as_raw(self) -> usize {
>> +        self.0
>> +    }
>> +}
>> +
>> +/// Parameters for creating a GPU buddy allocator.
>> +#[derive(Clone, Copy)]
>> +pub struct GpuBuddyParams {
>> +    /// Base offset in bytes where the managed memory region starts.
>> +    /// Allocations will be offset by this value.
>> +    pub base_offset_bytes: u64,
>> +    /// Total physical memory size managed by the allocator in bytes.
>> +    pub physical_memory_size_bytes: u64,
>> +    /// Minimum allocation unit / chunk size in bytes, must be >= 4KB.
>> +    pub chunk_size_bytes: u64,
>> +}
>> +
>> +/// Parameters for allocating blocks from a GPU buddy allocator.
>> +#[derive(Clone, Copy)]
>> +pub struct GpuBuddyAllocParams {
>> +    /// Start of allocation range in bytes. Use 0 for beginning.
>> +    pub start_range_address: u64,
>> +    /// End of allocation range in bytes. Use 0 for entire range.
>> +    pub end_range_address: u64,
>> +    /// Total size to allocate in bytes.
>> +    pub size_bytes: u64,
>> +    /// Minimum block size for fragmented allocations in bytes.
>> +    pub min_block_size_bytes: u64,
>> +    /// Buddy allocator behavior flags.
>> +    pub buddy_flags: BuddyFlags,
>> +}
>> +
> 
> (not a full review)
> 
> Any reason these two need Clone, Copy? I'm not seeing a use case for
> that, maybe we should pass them as non-mutable references, but I don't
> think there is any point in passing them by value ever.
Yes, one reason I did that is because the doctests reuse the same params. But I
could also just pass by reference as you suggest. It might remove some mem
copies in the doctests. I will make this change then, thanks!

--
Joel Fernandes

Powered by blists - more mailing lists