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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox