rust/kernel/drm/gpuvm/sm_ops.rs
Source file repositories/reference/linux-study-clean/rust/kernel/drm/gpuvm/sm_ops.rs
File Facts
- System
- Linux kernel
- Corpus path
rust/kernel/drm/gpuvm/sm_ops.rs- Extension
.rs- Size
- 15267 bytes
- Lines
- 430
- Domain
- Rust Kernel Layer
- Bucket
- Rust API Membrane
- Inferred role
- Rust Kernel Layer: implementation source
- Status
- source implementation candidate
Why This File Exists
Rust-side wrappers and abstractions around kernel C APIs, ownership contracts, allocation, synchronization, and module integration.
- Rust-side wrappers and abstractions around kernel C APIs, ownership contracts, allocation, synchronization, and module integration.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
function keep
Annotated Snippet
pub fn remove(self) -> (OpUnmapped<'op, T>, GpuVaRemoved<T>) {
// SAFETY: The op references a valid drm_gpuva in the GPUVM.
unsafe { bindings::drm_gpuva_unmap(self.op) };
// SAFETY: The va is no longer in the interval tree so we may unlink it.
unsafe { bindings::drm_gpuva_unlink_defer(self.op.va) };
// SAFETY: We just removed this va from the `GpuVm<T>`.
let va = unsafe { GpuVaRemoved::from_raw(self.op.va) };
(
OpUnmapped {
_invariant: self._invariant,
},
va,
)
}
}
/// Represents a completed [`OpUnmap`] operation.
pub struct OpUnmapped<'op, T> {
_invariant: PhantomData<*mut &'op mut T>,
}
/// Represents an `sm_step_remap` operation that has not yet been completed.
pub struct OpRemap<'op, T: DriverGpuVm> {
op: &'op bindings::drm_gpuva_op_remap,
// This ensures that 'op is invariant, so that `OpRemap<'long, T>` does not
// coerce to `OpRemap<'short, T>`. This ensures that the user can't return the
// wrong`OpRemapped` value.
_invariant: PhantomData<*mut &'op mut T>,
}
impl<'op, T: DriverGpuVm> OpRemap<'op, T> {
/// The preceding part of a split mapping.
#[inline]
pub fn prev(&self) -> Option<&OpRemapMapData> {
// SAFETY: We checked for null, so the pointer must be valid.
NonNull::new(self.op.prev).map(|ptr| unsafe { OpRemapMapData::from_raw(ptr) })
}
/// The subsequent part of a split mapping.
#[inline]
pub fn next(&self) -> Option<&OpRemapMapData> {
// SAFETY: We checked for null, so the pointer must be valid.
NonNull::new(self.op.next).map(|ptr| unsafe { OpRemapMapData::from_raw(ptr) })
}
/// Indicates whether the `drm_gpuva` being removed is physically contiguous with the original
/// mapping request.
///
/// Optionally, if `keep` is set, drivers may keep the actual page table mappings for this
/// `drm_gpuva`, adding the missing page table entries only and update the `drm_gpuvm`
/// accordingly.
#[inline]
pub fn keep(&self) -> bool {
// SAFETY: The unmap pointer is always valid.
unsafe { (*self.op.unmap).keep }
}
/// The range being unmapped.
#[inline]
pub fn va_to_unmap(&self) -> &GpuVa<T> {
// SAFETY: This is a valid va. It's not the `kernel_alloc_node` because you can't unmap it,
// and it's not sparse by the `GpuVm<T>` type invariants.
unsafe { GpuVa::<T>::from_raw((*self.op.unmap).va) }
}
/// The [`drm_gem_object`](DriverGpuVm::Object) whose VA is being remapped.
#[inline]
pub fn obj(&self) -> &T::Object {
self.va_to_unmap().obj()
}
/// The [`GpuVmBo`] that is being remapped.
#[inline]
pub fn vm_bo(&self) -> &GpuVmBo<T> {
self.va_to_unmap().vm_bo()
}
/// Update the GPUVM to perform the remapping.
pub fn remap(
self,
va_alloc: [GpuVaAlloc<T>; 2],
prev_data: impl PinInit<T::VaData>,
next_data: impl PinInit<T::VaData>,
) -> (OpRemapped<'op, T>, OpRemapRet<T>) {
let [va1, va2] = va_alloc;
let mut unused_va = None;
let mut prev_ptr = ptr::null_mut();
Annotation
- Detected declarations: `function keep`.
- Atlas domain: Rust Kernel Layer / Rust API Membrane.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.