From: Alice Ryhl <aliceryhl@google.com>
To: Daniel Almeida <daniel.almeida@collabora.com>
Cc: "Danilo Krummrich" <dakr@kernel.org>,
"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 v3 3/6] rust: gpuvm: add GpuVm::obtain()
Date: Thu, 22 Jan 2026 08:20:53 +0000 [thread overview]
Message-ID: <aXHd5aU-kV-9q_GW@google.com> (raw)
In-Reply-To: <C31C1A08-D626-48D6-8F8C-39209BF94B50@collabora.com>
On Wed, Jan 21, 2026 at 02:31:26PM -0300, Daniel Almeida wrote:
> Hi Alice,
>
> This looks good. See a few nits below:
>
> > On 21 Jan 2026, at 08:31, Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > This provides a mechanism to create (or look up) VMBO instances, which
> > represent the mapping between GPUVM and GEM objects.
> >
> > The GpuVmBoResident<T> type can be considered like ARef<GpuVm<T>>,
> > except that no way to increment the refcount is provided.
>
> So this is like GpuVmCore, right? Since that is an ARef whose refcount cannot
> be incremented.
Sort of, except that GpuVmBoResident is not truly unique since you can
call obtain() twice.
> > The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVm<T>, so
> > it's not really a GpuVm<T> yet. Its destructor could call
>
> Maybe you mean a pre-allocated GpuVmBo?
Yes that's what I meant.
> > drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently
> > private and never called anywhere, this perf optimization does not need
> > to happen now.
> >
> > Pre-allocating and obtaining the gpuvm_bo object is exposed as a single
> > step. This could theoretically be a problem if one wanted to call
> > drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical
> > path, but that's not a possibility because:
> >
> > 1. Adding the BO to the extobj list requires the resv lock, so it cannot
> > happen during the fence signalling critical path.
> > 2. obtain() requires that the BO is not in the extobj list, so obtain()
> > must be called before adding the BO to the extobj list.
> >
> > Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence
> > signalling critical path. (For extobjs at least.)
>
> What about internal objects? This is merely a sanity check from my side.
There are only two lists: extobj and evicted.
The extobj list is used to find the dma_resv locks of external objects.
This isn't required for internal ones, as they all share the resv lock
of the GPUVM itself.
> > + #[inline]
> > + fn raw_resv_lock(&self) -> *mut bindings::dma_resv {
> > + // SAFETY: `r_obj` is immutable and valid for duration of GPUVM.
> > + unsafe { (*(*self.as_raw()).r_obj).resv }
> > + }
>
> Shouldn’t we call this raw_resv? Adding “lock” to a name may incorrectly
> hint that the lock is actually taken.
Good call.
> > + /// Custom function for allocating a `drm_gpuvm_bo`.
> > + ///
> > + /// # Safety
> > + ///
> > + /// Always safe to call.
> > + // Unsafe to match function pointer type in C struct.
>
> Is this missing an extra “/“ token? Also, I think this is a bit hard to parse initially.
Well, I didn't meant to include it in the docs. But I can reformat this
to be less confusing.
> > + /// Look up whether there is an existing [`GpuVmBo`] for this gem object.
> > + #[inline]
> > + pub(super) fn obtain(self) -> GpuVmBoResident<T> {
> > + let me = ManuallyDrop::new(self);
> > + // SAFETY: Valid `drm_gpuvm_bo` not already in the lists.
> > + let ptr = unsafe { bindings::drm_gpuvm_bo_obtain_prealloc(me.as_raw()) };
> > +
> > + // If the vm_bo does not already exist, ensure that it's in the extobj list.
>
> Wording is a bit off. Obviously only external objects should be in the extobj
> list. This is correctly captured by the check below, but the wording above
> makes it sound unconditional.
I'll update the comment. The "does not already exist" refers to the
`ptr::eq()` part of the condition, which checks whether the
pre-allocated vm_bo was created, or whether the GPUVM already has a
vm_bo for this GEM object.
> > + if ptr::eq(ptr, me.as_raw()) && me.gpuvm().is_extobj(me.obj()) {
> > + let resv_lock = me.gpuvm().raw_resv_lock();
> > + // SAFETY: The GPUVM is still alive, so its resv lock is too.
> > + unsafe { bindings::dma_resv_lock(resv_lock, ptr::null_mut()) };
> > + // SAFETY: We hold the GPUVMs resv lock.
> > + unsafe { bindings::drm_gpuvm_bo_extobj_add(ptr) };
> > + // SAFETY: We took the lock, so we can unlock it.
> > + unsafe { bindings::dma_resv_unlock(resv_lock) };
> > + }
> > +
> > + // INVARIANTS: Valid `drm_gpuvm_bo` in the GEM list.
> > + // SAFETY: `drm_gpuvm_bo_obtain_prealloc` always returns a non-null ptr
> > + GpuVmBoResident(unsafe { NonNull::new_unchecked(ptr.cast()) })
> > + }
> > +}
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Thanks for the reivew!
Alice
next prev parent reply other threads:[~2026-01-22 8:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 11:31 [PATCH v3 0/6] Rust GPUVM immediate mode Alice Ryhl
2026-01-21 11:31 ` [PATCH v3 1/6] rust: drm: add base GPUVM immediate mode abstraction Alice Ryhl
2026-01-21 17:04 ` Daniel Almeida
2026-01-22 9:23 ` Alice Ryhl
2026-01-21 11:31 ` [PATCH v3 2/6] rust: helpers: Add bindings/wrappers for dma_resv_lock Alice Ryhl
2026-01-21 12:39 ` Daniel Almeida
2026-01-21 15:44 ` Gary Guo
2026-01-21 11:31 ` [PATCH v3 3/6] rust: gpuvm: add GpuVm::obtain() Alice Ryhl
2026-01-21 17:31 ` Daniel Almeida
2026-01-22 8:20 ` Alice Ryhl [this message]
2026-01-26 15:00 ` Boris Brezillon
2026-01-26 15:07 ` Alice Ryhl
2026-01-26 15:35 ` Boris Brezillon
2026-01-26 16:44 ` Danilo Krummrich
2026-01-21 11:31 ` [PATCH v3 4/6] rust: gpuvm: add GpuVa struct Alice Ryhl
2026-01-22 22:09 ` Daniel Almeida
2026-01-21 11:31 ` [PATCH v3 5/6] rust: gpuvm: add GpuVmCore::sm_unmap() Alice Ryhl
2026-01-22 22:43 ` Daniel Almeida
2026-01-23 9:23 ` [PATCH v3 5/6] rust: gpuvm: add GpuVmCore::sm_unmap()' Alice Ryhl
2026-01-21 11:31 ` [PATCH v3 6/6] rust: gpuvm: add GpuVmCore::sm_map() Alice Ryhl
2026-01-22 22:58 ` Daniel Almeida
2026-01-23 9:23 ` 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=aXHd5aU-kV-9q_GW@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.