Re: [PATCH v4 3/6] rust: gpuvm: add GpuVm::obtain()

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Feb 20, 2026 at 05:08:09PM +0100, Danilo Krummrich wrote:
> On Fri Feb 20, 2026 at 9:16 AM CET, Alice Ryhl wrote:
> >> > +/// A [`GpuVmBo`] object in the GEM list.
> >> > +///
> >> > +/// # Invariants
> >> > +///
> >> > +/// Points at a `drm_gpuvm_bo` that contains a valid `T::VmBoData` and is present in the gem list.
> >> > +pub struct GpuVmBoRegistered<T: DriverGpuVm>(NonNull<GpuVmBo<T>>);
> >> 
> >> I know that I proposed to rename this from GpuVmBoResident to GpuVmBoRegistered
> >> in a drive-by comment on v3.
> >> 
> >> But now that I have a closer look, I think it would be nice to just have GpuVmBo
> >> being the registered one and GpuVmBoAlloc being the pre-allocated one.
> >> 
> >> As it is currently, I think it is bad to ever present a &GpuVmBo to a driver
> >> because it implies that we don't know whether it is a pre-allocated one or a
> >> "normal", registered one. But we do always know.
> >
> > Actually, I think GpuVmBo is already the registered one.
> > GpuVmBoRegistered is just ARef<GpuVmBo<T>>.
> 
> GpuVmBoAlloc<T> dereferences to GpuVmBo<T>, so currently it is not.

I will drop the Deref impl.

> >> For instance, in patch 6 we give out &'op GpuVmBo<T>, but it actually carries
> >> the invariant of being registered.
> >> 
> >> Of course, we could fix this by giving out a &'op GpuVmBoRegistered<T> instead,
> >> but it would be nice to not have drivers be in touch with a type that can be one
> >> or the other.
> >> 
> >> I know that the current GpuVmBo<T> also serves the purpose of storing common
> >> code. Maybe we can make it private, call it GpuVmBoInner<T> and have inline
> >> forwarding methods for GpuVmBo<T> and GpuVmBoAlloc<T>. This is slightly more
> >> overhead in this implementation due to the forwarding methods, but less
> >> ambiguity for drivers, which I think is more important.
> >
> > I think we should keep the current state that GpuVmBo is registered, and
> > only GpuVmBoAlloc is not. That is most useful.
> 
> We seem to agree then: What I want is that from a driver perspective there is
> only GpuVmBo<T> (which is the registered thing) and GpuVmBoAlloc<T> which is the
> pre-allocated thing, i.e.  no separate GpuVmBoRegistered<T> type.

So, should we get rid of GpuVmBoRegistered in favor of ARef<GpuVm<T>>?

Alice