[PATCH v4 02/40] drm/gpuvm: Allow VAs to hold soft reference to BOs

[Rob Clark]

On Thu, May 15, 2025 at 2:00 AM Danilo Krummrich <dakr at kernel.org> wrote:
>
> On Wed, May 14, 2025 at 10:53:16AM -0700, Rob Clark wrote:
> > From: Rob Clark <robdclark at chromium.org>
> >
> > Eases migration for drivers where VAs don't hold hard references to
> > their associated BO, avoiding reference loops.
> >
> > In particular, msm uses soft references to optimistically keep around
> > mappings until the BO is distroyed.  Which obviously won't work if the
> > VA (the mapping) is holding a reference to the BO.
>
> Ick! This is all complicated enough. Allow drivers to bypass the proper
> reference counting for GEM objects in the context of VM_BO structures seems like
> an insane footgun.
>
> I don't understand why MSM would need weak references here. Why does msm need
> that, but nouveau, Xe, panthor, PowerVR do not?

Most of those drivers were designed (and had their UABI designed) with
gpuvm, or at least sparse, in mind from the get go.  I'm not sure
about nouveau, but I guess it just got lucky that it's UABI semantics
fit having the VMA hold a reference to the BO.

Unfortunately, msm pre-dates sparse.. and in the beginning there was
only a single global VM, multiple VMs was something retrofitted ~6yrs
(?) back.  For existing msm, the VMA(s) are implicitly torn down when
the GEM obj is freed.  This won't work with the VMA(s) holding hard
references to the BO.

When userspace opts-in to "VM_BIND" mode, which it has to do before
the VM is created, then we don't set this flag, the VMA holds a hard
reference to the BO as it does with other drivers.  But consider this
use-case, which is perfectly valid for old (existing) userspace:

1) Userspace creates a BO
2) Submits rendering referencing the BO
3) Immediately closes the BO handle, without waiting for the submit to complete

In this case, the submit holds a reference to the BO which holds a
reference to the VMA.  Everything is torn down gracefully when the
submit completes.  But if the VMA held a hard reference to the BO then
you'd have a reference loop.

So there really is no other way to use gpuvm _and_ maintain backwards
compatibility with the semantics of the pre-VM_BIND UAPI without this
flag.

Fortunately DRM_GPUVM_VA_WEAK_REF is minimally intrusive.  Otherwise I
probably would have had to fork my own copy of gpuvm.

BR,
-R