All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Daniel Almeida" <daniel.almeida@collabora.com>,
	"Boris Brezillon" <boris.brezillon@collabora.com>,
	"Janne Grunau" <j@jannau.net>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Lyude Paul" <lyude@redhat.com>,
	"Asahi Lina" <lina+kernel@asahilina.net>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v4 1/6] rust: drm: add base GPUVM immediate mode abstraction
Date: Thu, 19 Feb 2026 14:41:20 +0000	[thread overview]
Message-ID: <aZchECrW8mPbZMq8@google.com> (raw)
In-Reply-To: <DGJ0IL3LLZRW.3JC9RY1GDIJA6@kernel.org>

On Thu, Feb 19, 2026 at 03:36:20PM +0100, Danilo Krummrich wrote:
> On Fri Jan 30, 2026 at 3:24 PM CET, Alice Ryhl wrote:
> > +/// A DRM GPU VA manager.
> > +///
> > +/// This object is refcounted, but the "core" is only accessible using a special unique handle. The
> > +/// core consists of the `core` field and the GPUVM's interval tree.
> 
> I think this is still a bit confusing, I think we should just rename GpuVmCore
> to UniqueGpuVm and rewrite this to something like:
> 
> "The driver specific data of of `GpuVm` is only accessible through a
> [`UniqueGpuVm`], which guarantees exclusive access."

But it's not really the same as e.g. UniqueArc<_>, which implies that
there are no normal Arc<_>s whatsoever. This one is just a special ref,
but there may also be normal refs at the same time.

> > +    pub unsafe fn from_raw<'a>(ptr: *mut bindings::drm_gpuvm) -> &'a Self {
> > +        // SAFETY: Caller passes a pointer to the `drm_gpuvm` in a `GpuVm<T>`. Caller ensures the
> > +        // pointer is valid for 'a.
> > +        unsafe { &*kernel::container_of!(Opaque::cast_from(ptr), Self, vm) }
> 
> I'd pull the Opaque::cast_from() call out of the unsafe block.

I think that's a bit verbose, and all existing uses do it inside the
`container_of!`.

> > +/// The manager for a GPUVM.
> 
> This description seems a bit odd. In the end, the trait makes GPUVM aware of
> other driver specific types. So, maybe a better name would be
> gpuvm::DriverAttributes, gpuvm::DriverTypes, gpuvm::DriverInfo or just
> gpuvm::Driver. My favorite is gpuvm::DriverInfo.
> 
> We should also change the doc-comment accordingly. Maybe somthing like: "This
> trait make the [`GpuVm`] aware of the other driver specific DRM types."

I mean, it doesn't just do that. The type implementing this is the type
stored in the `core` field, so you really do get more than just some
type relationships from it.

Alice

> > +pub trait DriverGpuVm: Sized {
> > +    /// Parent `Driver` for this object.
> > +    type Driver: drm::Driver<Object = Self::Object>;
> > +
> > +    /// The kind of GEM object stored in this GPUVM.
> > +    type Object: IntoGEMObject;
> > +}

  reply	other threads:[~2026-02-19 14:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30 14:24 [PATCH v4 0/6] Rust GPUVM immediate mode Alice Ryhl
2026-01-30 14:24 ` [PATCH v4 1/6] rust: drm: add base GPUVM immediate mode abstraction Alice Ryhl
2026-02-02 15:15   ` Boris Brezillon
2026-02-19 14:36   ` Danilo Krummrich
2026-02-19 14:41     ` Alice Ryhl [this message]
2026-02-19 14:55       ` Danilo Krummrich
2026-01-30 14:24 ` [PATCH v4 2/6] rust: helpers: Add bindings/wrappers for dma_resv_lock Alice Ryhl
2026-02-19 14:40   ` Danilo Krummrich
2026-02-19 14:45     ` Alice Ryhl
2026-01-30 14:24 ` [PATCH v4 3/6] rust: gpuvm: add GpuVm::obtain() Alice Ryhl
2026-02-19 19:22   ` Danilo Krummrich
2026-02-20  8:16     ` Alice Ryhl
2026-02-20 16:08       ` Danilo Krummrich
2026-02-21  8:46         ` Alice Ryhl
2026-02-21 15:09           ` Danilo Krummrich
2026-02-23  9:15             ` Alice Ryhl
2026-02-23 10:44               ` Danilo Krummrich
2026-02-23 11:22                 ` Alice Ryhl
2026-02-25 15:46                   ` Danilo Krummrich
2026-01-30 14:24 ` [PATCH v4 4/6] rust: gpuvm: add GpuVa struct Alice Ryhl
2026-01-30 14:24 ` [PATCH v4 5/6] rust: gpuvm: add GpuVmCore::sm_unmap() Alice Ryhl
2026-01-30 14:24 ` [PATCH v4 6/6] rust: gpuvm: add GpuVmCore::sm_map() Alice Ryhl
2026-02-06 20:17   ` Deborah Brouwer
2026-02-09  8:17     ` Alice Ryhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZchECrW8mPbZMq8@google.com \
    --to=aliceryhl@google.com \
    --cc=boris.brezillon@collabora.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j@jannau.net \
    --cc=lina+kernel@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=matthew.brost@intel.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.