drm/gpuvm: rust: add RUST_DRM_GPUVM option to Kconfig

Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM
module must also be built-in to use GPUVM from Rust. Adjust the Kconfig

drm/gpuvm: rust: add RUST_DRM_GPUVM option to Kconfig

Since Rust uses GPUVM via the kernel crate, which is built-in, the GPUVM
module must also be built-in to use GPUVM from Rust. Adjust the Kconfig
settings accordingly.

Suggested-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260427-gpuvm-config-v1-1-8ece03771f8a@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

show more ...

rust: gpuvm: add GpuVm::obtain()

This provides a mechanism to create (or look up) VMBO instances, which
represent the mapping between GPUVM and GEM objects.

The GpuVmBoRegistered<T> type can be con

rust: gpuvm: add GpuVm::obtain()

This provides a mechanism to create (or look up) VMBO instances, which
represent the mapping between GPUVM and GEM objects.

The GpuVmBoRegistered<T> type can be considered like ARef<GpuVm<T>>,
except that no way to increment the refcount is provided.

The GpuVmBoAlloc<T> type is more akin to a pre-allocated GpuVmBo<T>, so
it's not really a GpuVmBo<T> yet. Its destructor could call
drm_gpuvm_bo_destroy_not_in_lists(), but as the type is currently
private and never called anywhere, this perf optimization does not need
to happen now.

Pre-allocating and obtaining the gpuvm_bo object is exposed as a single
step. This could theoretically be a problem if one wanted to call
drm_gpuvm_bo_obtain_prealloc() during the fence signalling critical
path, but that's not a possibility because:

1. Adding the BO to the extobj list requires the resv lock, so it cannot
happen during the fence signalling critical path.
2. obtain() requires that the BO is not in the extobj list, so obtain()
must be called before adding the BO to the extobj list.

Thus, drm_gpuvm_bo_obtain_prealloc() cannot be called during the fence
signalling critical path. (For extobjs at least.)

Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-2-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

show more ...

rust: drm: add base GPUVM immediate mode abstraction

Add a GPUVM abstraction to be used by Rust GPU drivers.

GPUVM keeps track of a GPU's virtual address (VA) space and manages the
corresponding vi

rust: drm: add base GPUVM immediate mode abstraction

Add a GPUVM abstraction to be used by Rust GPU drivers.

GPUVM keeps track of a GPU's virtual address (VA) space and manages the
corresponding virtual mappings represented by "GPU VA" objects. It also
keeps track of the gem::Object<T> used to back the mappings through
GpuVmBo<T>.

This abstraction is only usable by drivers that wish to use GPUVM in
immediate mode. This allows us to build the locking scheme into the API
design. It means that the GEM mutex is used for the GEM gpuva list, and
that the resv lock is used for the extobj list. The evicted list is not
yet used in this version.

This abstraction provides a special handle called the UniqueRefGpuVm,
which is a wrapper around ARef<GpuVm> that provides access to the
interval tree. Generally, all changes to the address space requires
mutable access to this unique handle.

Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
Co-developed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-1-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

show more ...