kernel/git/stable/linux.git/include/drm/drm_gpusvm.h, branch master

drm/gpusvm: let the drm_gpusvm core context purely MM level

2026-07-09T11:12:49+00:00

The core mechanism of drm_gpusvm is HMM, which is fundamentally an MM side subsystem. A drm_device, enters the picture on the device side at DMA mapping / GPU bind. So move struct drm_device from struct drm_gpusvm in drm_gpusvm. Let drm_gpusvm keep its core neutral and leave device side decisions to the driver. Make drm_gpusvm a pure MM level object. - Move the drm_device from struct drm_gpusvm. drm_device now stored in drm_gpusvm_pages. - Drop the drm parameter from drm_gpusvm_init() - Update the xe call sites in xe_svm_init() and other callers. drm_device does not disappear from the framework, it is relocated onto each drm_gpusvm_pages where DMA actually happens. Suggested-by: Matthew Brost Reviewed-by: Matthew Brost Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260630102127.392396-6-honghuan@amd.com

drm/gpusvm: move struct drm_gpusvm_pages out of struct drm_gpusvm_range

2026-07-09T11:12:48+00:00

Since the pages the physical pages and MM VA range has been abstractly separated. Unbinding a single form of physical page from the MM VA range, brings flexibility to the drm gpu SVM framework, transfer the way of management of MM and device physical pages to the driver layer. framework's range embedded pages object and its range level wrappers have no users left. Remove the following: - Drop pages in drm_gpusvm_range. - Drop drm_gpusvm_range_pages_valid(), drm_gpusvm_range_get_pages() and drm_gpusvm_range_unmap_pages(); drivers should use the drm_gpusvm_pages helpers (drm_gpusvm_pages_valid, drm_gpusvm_get_pages, drm_gpusvm_unmap_pages) directly on a pages object they own. - Drop the notifier_seq seeding in drm_gpusvm_range_alloc(); drivers initialise notifier_seq on their own pages object. Update the DOC: overview to match the new model: document struct drm_gpusvm_pages and the driver owned 1:1 / N:1 layouts, and rewrite the usage examples to operate on a driver embedded pages object by the drm_gpusvm_pages helpers instead of the removed range level wrappers. Suggested-by: Matthew Brost Reviewed-by: Matthew Brost Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260630102127.392396-5-honghuan@amd.com

drm/xe: have xe_svm_range embed one drm_gpusvm_pages

2026-07-09T11:12:45+00:00

With drm_gpusvm_pages now self contained, make xe stop relying on the drm_gpusvm_range pages and take responsibility for the page lifecycle on the driver side. Driver side (xe): - Embed struct drm_gpusvm_pages in xe_svm_range and route all xe accesses through it instead of range->base.pages. - Initialise the embedded pages via drm_gpusvm_init_pages(), which binds the owning &xe->drm up front, and take over the page lifecycle: xe_svm_range_get_pages() calls drm_gpusvm_get_pages() directly; the notifier event_end and xe_svm_range_free() paths drive unmap/free on the embedded pages object. - Convert the open-coded userptr pages init in xe_userptr_setup() to the same drm_gpusvm_init_pages() helper. - Switch xe_svm_range_pages_valid() to drm_gpusvm_pages_valid(). Framework side (drm_gpusvm): - Add a small inline drm_gpusvm_init_pages() helper that records the owning drm_device and initialises the per-pages state, giving drivers a single hook to extend. - Export drm_gpusvm_pages_valid() to let driver owned pages can query mapping state without going through a range. - Lifecycle change: drm_gpusvm_range_remove() no longer *triggers* unmap/free of the embedded pages. The unmap/free logic itself stays in the framework -- drm_gpusvm_free_pages() still performs the DMA unmap (as an idempotent backstop) and frees the dma_addr array -- but the driver now owns *when* it runs, since the driver owns the drm_gpusvm_pages object. Side effect / contract: a driver that owns a drm_gpusvm_pages is now responsible for its lifecycle: drm_gpusvm_init_pages() before first use, and drm_gpusvm_free_pages() when the owner goes away. Xe does the latter from its ops->range_free callback, which the framework invokes once the range refcount drops to zero in drm_gpusvm_range_remove(). The timely DMA unmap for the IOMMU security model still happens in the notifier invalidate path via drm_gpusvm_unmap_pages(); the unmap inside drm_gpusvm_free_pages() is only a backstop for pages that were never invalidated. Suggested-by: Matthew Brost Reviewed-by: Matthew Brost Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260630102127.392396-4-honghuan@amd.com

drm/gpusvm: embed struct drm_device into drm_gpusvm_pages

2026-07-09T11:12:44+00:00

drm_gpusvm_pages is the layer that actually represents physical pages/mappings it owns the dma_addr array, the dma_iova_state... With the previous patch, so drm_gpusvm_pages is now strictly about physical pages and their DMA view. Since now the drm_gpusvm_pages instance is inherently bound to one specific drm_device, make that ownership explicit by giving drm_gpusvm_pages its own drm_device handle, and drive all DMA through it instead of through the gpusvm: - Add drm to struct drm_gpusvm_pages and route all DMA in drm_gpusvm_get_pages() / __drm_gpusvm_unmap_pages() through svm_pages->drm instead of gpusvm->drm. - Bind svm_pages->drm where the pages object is initialised (drm_gpusvm_range_alloc() and the xe userptr setup) and require it to be set on entry to drm_gpusvm_get_pages(); the dma device is immutable for the lifetime of the pages instance. A later patch introduces drm_gpusvm_init_pages() to centralise this. Suggested-by: Matthew Brost Reviewed-by: Matthew Brost Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260630102127.392396-3-honghuan@amd.com

drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flags

2026-07-09T11:12:42+00:00

drm_gpusvm_pages_flags currently mixes two status: - MM / virtual-address state: whether the range has been (partially) unmapped by the Linux MM, these follow the lifetime of the VMA and are a single per VA range fact. - Device mapping state: has_devmem_pages and has_dma_mapping, which describe the current page mapping status held by device itself. Keeping both on the pages object blurs the semantics of the abstraction of pages and VA range. So move the MM state flags onto the range, and keep drm_gpusvm_pages_flags strictly for mapping state. - Introduce drm_gpusvm_range_flags { migrate_devmem, unmapped, partial_unmap } on drm_gpusvm_range. - Shrink drm_gpusvm_pages_flags to just has_devmem_pages and has_dma_mapping. Side effect: drivers now need to check the unmap flags in the driver itself to avoid handling the unmapped pages. Mirror that bit onto drm_gpusvm_pages so the framework can still short circuit drm_gpusvm_get_pages() under the notifier lock, and make drm_gpusvm_range_set_unmapped() propagate it to the backing pages. This follows Matt's review fixup for the v0 series; see the Link below. Like drm_gpusvm_pages_flags, drm_gpusvm_range_flags unions its bits with a u16 __flags member. Build the new value in a local copy and publish it with a single WRITE_ONCE() on __flags, and have the lockless readers use READ_ONCE(), so concurrent bitfield access stays data-race free and KCSAN quiet. Suggested-by: Matthew Brost Reviewed-by: Matthew Brost Link: https://gitlab.freedesktop.org/mbrost/xe-kernel-driver-svn-perf-6-15-2025/-/commit/623f6a50c037d9e44f6c9fbe6859a0ba7ad50177 Signed-off-by: Honglei Huang Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260630102127.392396-2-honghuan@amd.com

drm/gpusvm: Drop redundant @flags.* kernel-doc on struct drm_gpusvm_pages

2026-05-07T07:17:15+00:00

The kernel-doc block above struct drm_gpusvm_pages duplicates the descriptions of the bit-flags that live in struct drm_gpusvm_pages_flags using dotted notation (@flags.migrate_devmem, @flags.unmapped, ...). That dotted notation is intended for nested anonymous structs/unions that the parser flattens into the parent's parameter list. Here, however, flags is of a named external type, so the parser does not flatten its members and the dotted entries do not match any member of drm_gpusvm_pages. They also duplicate the canonical descriptions already present in the kernel-doc of struct drm_gpusvm_pages_flags itself. Drop the five @flags.* lines and replace them with a single @flags entry that cross-references the type via kernel-doc's "&struct ..." syntax. This eliminates the redundancy and removes warnings emitted by the new parameterdescs check in scripts/kernel-doc: Excess struct member 'flags.migrate_devmem' description in 'drm_gpusvm_pages' Excess struct member 'flags.unmapped' description in 'drm_gpusvm_pages' Excess struct member 'flags.partial_unmap' description in 'drm_gpusvm_pages' Excess struct member 'flags.has_devmem_pages' description in 'drm_gpusvm_pages' Excess struct member 'flags.has_dma_mapping' description in 'drm_gpusvm_pages' No functional change. Assisted-by: Claude:claude-opus-4.6 Cc: Matthew Auld Signed-off-by: Shuicheng Lin Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://patch.msgid.link/20260501175956.4054088-1-shuicheng.lin@intel.com

drm/gpusvm: Use dma-map IOVA alloc, link, and sync API in GPU SVM

2026-04-13T03:51:10+00:00

The dma-map IOVA alloc, link, and sync APIs perform significantly better than dma-map / dma-unmap, as they avoid costly IOMMU synchronizations. This difference is especially noticeable when mapping a 2MB region in 4KB pages. Use the IOVA alloc, link, and sync APIs for GPU SVM, which create DMA mappings between the CPU and GPU. Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Link: https://patch.msgid.link/20260410205929.3914474-2-matthew.brost@intel.com

drm/gpusvm: Introduce a function to scan the current migration state

2025-12-23T09:00:48+00:00

With multi-device we are much more likely to have multiple drm-gpusvm ranges pointing to the same struct mm range. To avoid calling into drm_pagemap_populate_mm(), which is always very costly, introduce a much less costly drm_gpusvm function, drm_gpusvm_scan_mm() to scan the current migration state. The device fault-handler and prefetcher can use this function to determine whether migration is really necessary. There are a couple of performance improvements that can be done for this function if it turns out to be too costly. Those are documented in the code. v3: - New patch. Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Reviewed-by: Himal Prasad Ghimiray Acked-by: Maarten Lankhorst # For merging through drm-xe. Link: https://patch.msgid.link/20251219113320.183860-21-thomas.hellstrom@linux.intel.com

drm/gpusvm, drm/xe: Allow mixed mappings for userptr

2025-10-17T08:25:27+00:00

Compute kernels often issue memory copies immediately after completion. If the memory being copied is an SVM pointer that was faulted into the device and then bound via userptr, it is undesirable to move that memory. Worse, if userptr is mixed between system and device memory, the bind operation may be rejected. Xe already has the necessary plumbing to support userptr with mixed mappings. This update modifies GPUSVM's get_pages to correctly locate pages in such mixed mapping scenarios. v2: - Rebase (Thomas Hellström) v3: - Remove Fixes tag. v4: - Break out from series since the other patch was merged. - Update patch subject, ensure dri-devel and Maarten are CC'd. Cc: Maarten Lankhorst Cc: dri-devel@lists.freedesktop.org Signed-off-by: Matthew Brost Reviewed-by: Thomas Hellström Reviewed-by: Matthew Auld Reviewed-by: Himal Prasad Ghimiray Link: https://lore.kernel.org/r/20251015120320.176338-1-thomas.hellstrom@linux.intel.com Acked-by: Maarten Lankhorst Signed-off-by: Thomas Hellström

drm/gpusvm, drm/xe: Fix userptr to not allow device private pages

2025-10-02T09:50:12+00:00

When userptr is used on SVM-enabled VMs, a non-NULL hmm_range::dev_private_owner value might mean that hmm_range_fault() attempts to return device private pages. Either that will fail, or the userptr code will not know how to handle those. Use NULL for hmm_range::dev_private_owner to migrate such pages to system. In order to do that, move the struct drm_gpusvm::device_private_page_owner field to struct drm_gpusvm_ctx::device_private_page_owner so that it doesn't remain immutable over the drm_gpusvm lifetime. v2: - Don't conditionally compile xe_svm_devm_owner(). - Kerneldoc xe_svm_devm_owner(). Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") Cc: Matthew Auld Cc: Himal Prasad Ghimiray Cc: Matthew Brost Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld Reviewed-by: Matthew Brost Acked-by: Maarten Lankhorst Link: https://lore.kernel.org/r/20250930122752.96034-1-thomas.hellstrom@linux.intel.com