tjh.dev / kernel
Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

drm_gem: add mutex to drm_gem_object.gpuva

There are two main ways that GPUVM might be used:

* staged mode, where VM_BIND ioctls update the GPUVM immediately so that
the GPUVM reflects the state of the VM *including* staged changes that
are not yet applied to the GPU's virtual address space.
* immediate mode, where the GPUVM state is updated during run_job(),
i.e., in the DMA fence signalling critical path, to ensure that the
GPUVM and the GPU's virtual address space has the same state at all
times.

Currently, only Panthor uses GPUVM in immediate mode, but the Rust
drivers Tyr and Nova will also use GPUVM in immediate mode, so it is
worth to support both staged and immediate mode well in GPUVM. To use
immediate mode, the GEMs gpuva list must be modified during the fence
signalling path, which means that it must be protected by a lock that is
fence signalling safe.

For this reason, a mutex is added to struct drm_gem_object that is
intended to achieve this purpose. Adding it directly in the GEM object
both makes it easier to use GPUVM in immediate mode, but also makes it
possible to take the gpuva lock from core drm code.

As a follow-up, another change that should probably be made to support
immediate mode is a mechanism to postpone cleanup of vm_bo objects, as
dropping a vm_bo object in the fence signalling path is problematic for
two reasons:

* When using DRM_GPUVM_RESV_PROTECTED, you cannot remove the vm_bo from
the extobj/evicted lists during the fence signalling path.
* Dropping a vm_bo could lead to the GEM object getting destroyed.
The requirement that GEM object cleanup is fence signalling safe is
dubious and likely to be violated in practice.

Panthor already has its own custom implementation of postponing vm_bo
cleanup.

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-1-bd89f5a82c0d@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

authored by

Alice Ryhl and committed by
Danilo Krummrich e7fa80e2 bddf32f1

+20 -6
+2
drivers/gpu/drm/drm_gem.c
··· 187 187 kref_init(&obj->refcount); 188 188 obj->handle_count = 0; 189 189 obj->size = size; 190 + mutex_init(&obj->gpuva.lock); 190 191 dma_resv_init(&obj->_resv); 191 192 if (!obj->resv) 192 193 obj->resv = &obj->_resv; ··· 211 210 WARN_ON(obj->dma_buf); 212 211 213 212 dma_resv_fini(&obj->_resv); 213 + mutex_destroy(&obj->gpuva.lock); 214 214 } 215 215 EXPORT_SYMBOL(drm_gem_private_object_fini); 216 216
+18 -6
include/drm/drm_gem.h
··· 398 398 struct dma_resv _resv; 399 399 400 400 /** 401 - * @gpuva: 402 - * 403 - * Provides the list of GPU VAs attached to this GEM object. 404 - * 405 - * Drivers should lock list accesses with the GEMs &dma_resv lock 406 - * (&drm_gem_object.resv) or a custom lock if one is provided. 401 + * @gpuva: Fields used by GPUVM to manage mappings pointing to this GEM object. 407 402 */ 408 403 struct { 404 + /** 405 + * @gpuva.list: list of GPUVM mappings attached to this GEM object. 406 + * 407 + * Drivers should lock list accesses with either the GEMs 408 + * &dma_resv lock (&drm_gem_object.resv) or the 409 + * &drm_gem_object.gpuva.lock mutex. 410 + */ 409 411 struct list_head list; 412 + 413 + /** 414 + * @gpuva.lock: lock protecting access to &drm_gem_object.gpuva.list 415 + * when the resv lock can't be used. 416 + * 417 + * Should only be used when the VM is being modified in a fence 418 + * signalling path, otherwise you should use &drm_gem_object.resv to 419 + * protect accesses to &drm_gem_object.gpuva.list. 420 + */ 421 + struct mutex lock; 410 422 411 423 #ifdef CONFIG_LOCKDEP 412 424 struct lockdep_map *lock_dep_map;