Hi,
On 9/8/25 14:20, Danilo Krummrich wrote:
On 9/8/25 2:11 PM, Boris Brezillon wrote:
On Mon, 08 Sep 2025 13:11:32 +0200
"Danilo Krummrich" <[email protected]> wrote:
I'm saying exactly what you say: "has to be a special unlink function" ->
drm_gpuva_unlink_defer_put(). :)
I don't see how calling drm_gpuva_unlink() instead of
drm_gpuva_unlink_defer_put() would leak the vm_bo though.
Initially (i.e. a few mails back), it sounded to me as if you'd propose to drop
the drm_gpuva's vm_bo reference only when it is freed.
No, drivers can't iterate the evict/extobj lists directly; or at least this is
not intended by GPUVM's API and if drivers do so, this is considered peeking
into GPUVM internals, so drivers are on their own anyways.
Iterators, such as for_each_vm_bo_in_list() are not exposed to drivers.
Okay, that's a good thing. I thought Xe was doing some funky stuff with
the list...
Maybe, I don't know. If they do so, the should send patches adding the
corresponding iterators and provide a rationale why drivers need to access those
lists directly and why we can't provide an API that handles the overall
use-case, such as drm_gpuvm_prepare_objects(), etc.
We're using the drm_gpuvm_*for_each* macros in drm_gpuvm.h, assuming
from name and docs they are driver api.
Also the drm_gem_for_each_gpuvm_bo(), although this usage could easily
be converted to a helper.
So I don't think we're abusing internals ATM. If so we should ofc fix that.
IMO if some iteration macros or members that are exposed in the
driver-facing headers need to be private (where it's not totally
obvious) they should be marked as such or moved to private headers.
Thanks,
Thomas
