Re: Refcounting dma_resv and using that for drm_exec support in TTM

[Matthew Brost <matthew.brost@intel.com>]

On Mon, Jul 13, 2026 at 01:32:48PM +0200, Thomas Hellström wrote:
> Hi, Christian,
> 
> On Fri, 2026-07-10 at 20:52 +0200, Christian König wrote:
> > Hi everybody,
> > 
> > The idea of ref-counting dma_resv or ww_mutex came up multiple times
> > from
> > different people, but so far at least I have abandoned that as to
> > complicated to implement considering how widely used that object is.
> > 
> > Thanks to AI I gave the task to refcount dma_resv to Claude Sonet 4
> > just
> > to check how horrible it would look like.
> > 
> > Well turns out that this is actually a cleanup we should most likely
> > aim
> > for and I'm really wondering why we haven't done it like this in the
> > first place.
> > 
> > Not only resolves it a bunch of issues with dma_resv instances shared
> > by
> > multiple GEM objects (we just recently had a bunch of patches for
> > that on
> > the mailing list), but also allows TTM to implement it's delayed
> > delete
> > handling without any zombie resurrection or similar hacks.
> > 
> > The patch set is totally work in progress and only survives a smoke
> > test
> > with amdgpu, but I still wanted to check if the idea is valuable and
> > should be looked in further.
> > 
> > Please comment and/or tear apart :)
> 
> Before starting to look at this, in the spirit of trying to aligning on
> a "final" solution for ww transactions used in TTM, could we agree on
> how we are supposed to pass the importer's ww transaction context to
> the exporter's dma_map_attachment() operation to handle exporter
> evictions while mapping, because that decides what abstaction we should
> use for WW transations within TTM.
> 
> drm_exec_init()
> xe_bo_validate() // IMporter
> dma_buf_map()    // importer;
> map_attachment() // callback in exporter
> xe_bo_validate() // exporter tries to move exportert bo to VRAM but
> runs out of memory.
> ttm_bo_evict()   // exporter's evict needs importer's drm_exec
> 
> As mentioned a couple of times before, we can't pass a drm_exec to the
> exporter because that would make dma-buf depend on drm.
> 
> So with this series it would be sufficient to move drm_exec to the dma-
> buf layer and rename it, but I still think we should have a plan.

+1 to Thomas's thinking here — drm_exec should be moved to the dma-buf
layer.

I think that would involve dropping the GEM references from the base
layer and instead operating on dma-resv objects. Of course, if we want a
drm_exec layer that operates on GEM objects, it could be built on top of
the base dma-buf mechanism.

Matt

> 
> Thanks,
> Thomas
> 
> 
> 
> 
> > 
> > Cheers,
> > Christian.