| 727dc02e | 12-Jun-2026 |
Sami Tolvanen <samitolvanen@google.com> |
rust: drm: gpuvm: implement Send and Sync for GpuVaAlloc and GpuVmBo
Moving a GpuVaAlloc or GpuVmBo between threads currently forces drivers
to write their own unsafe Send and Sync impls. Provide th
rust: drm: gpuvm: implement Send and Sync for GpuVaAlloc and GpuVmBo
Moving a GpuVaAlloc or GpuVmBo between threads currently forces drivers
to write their own unsafe Send and Sync impls. Provide the markers in
the abstraction instead.
GpuVaAlloc wraps only uninitialised memory and exposes none of it.
GpuVmBo hands out the driver data and GEM object by shared reference and
drops them in its deferred put; the DriverGpuVm trait already guarantees
both are Send + Sync, so both impls are unconditional.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Link: https://patch.msgid.link/20260611-gpuvm-sync-send-v4-2-6c7f4ab2778a@google.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
show more ...
|
| 5f7410aa | 11-Jun-2026 |
Boris Brezillon <boris.brezillon@collabora.com> |
rust: drm: gpuvm: add SmContext lifetime bound
If a DriverGpuVm implementation is lifetime-parameterized, its
SmContext<'ctx> type may depend on lifetimes carried by that driver
implementation. In t
rust: drm: gpuvm: add SmContext lifetime bound
If a DriverGpuVm implementation is lifetime-parameterized, its
SmContext<'ctx> type may depend on lifetimes carried by that driver
implementation. In this case, SmContext<'ctx> is only valid if the
driver implementation outlives 'ctx.
Add a Self: 'ctx bound to DriverGpuVm::SmContext<'ctx> to express that
requirement. Then propagate the corresponding T: 'ctx bound to the GPUVM
state machine helper types that store T::SmContext<'ctx>.
This allows drivers to provide lifetime-parameterized implementations of
DriverGpuVm.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260610-gpuvm_smcontext_lifetime_bound_v1-v1-1-531e7d2ee7b4@collabora.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 37f748ed | 27-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
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 ...
|
| 0b715b1e | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVmCore::sm_map()
Finally also add the operation for creating new mappings. Mapping
operations need extra data in the context since they involve a vm_bo
coming from the outside.
rust: gpuvm: add GpuVmCore::sm_map()
Finally also add the operation for creating new mappings. Mapping
operations need extra data in the context since they involve a vm_bo
coming from the outside.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net>
Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
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-5-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| dc384604 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVmCore::sm_unmap()
Add the entrypoint for unmapping ranges in the GPUVM, and provide
callbacks and VA types for the implementation.
Co-developed-by: Asahi Lina <lina+kernel@asah
rust: gpuvm: add GpuVmCore::sm_unmap()
Add the entrypoint for unmapping ranges in the GPUVM, and provide
callbacks and VA types for the implementation.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net>
Signed-off-by: Asahi Lina <lina+kernel@asahilina.net>
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-4-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 5540a9c7 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
rust: gpuvm: add GpuVa struct
This struct will be used to keep track of individual mapped ranges in
the GPU's virtual memory.
Sparse VAs are not yet supported.
Co-developed-by: Asahi Lina <lina+ke
rust: gpuvm: add GpuVa struct
This struct will be used to keep track of individual mapped ranges in
the GPU's virtual memory.
Sparse VAs are not yet supported.
Co-developed-by: Asahi Lina <lina+kernel@asahilina.net>
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>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260409-gpuvm-rust-v6-3-b16e6ada7261@google.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
show more ...
|
| 71a39211 | 09-Apr-2026 |
Alice Ryhl <aliceryhl@google.com> |
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 ...
|