kernel/drivers/gpu/drm/drm_gpusvm.c, branch linux-rolling-stable

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

2025-10-17T08:25:27Z

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:12Z

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

drm/gpusvm: export drm_gpusvm_pages API

2025-09-05T10:45:47Z

Export get/unmap/free pages API. We also need to tweak the SVM init to allow skipping much of the unneeded parts. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250828142430.615826-15-matthew.auld@intel.com

drm/gpusvm: refactor core API to use pages struct

2025-09-05T10:45:46Z

Refactor the core API of get/unmap/free pages to all operate on drm_gpusvm_pages. In the next patch we want to export a simplified core API without needing fully blown svm range etc. Suggested-by: Matthew Brost Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250828142430.615826-14-matthew.auld@intel.com

drm/gpusvm: pull out drm_gpusvm_pages substructure

2025-09-05T10:45:46Z

Pull the pages stuff from the svm range into its own substructure, with the idea of having the main pages related routines, like get_pages(), unmap_pages() and free_pages() all operating on some lower level structures, which can then be re-used for stuff like userptr. v2: - Move seq into pages struct (Matt B) v3: - Small kernel-doc fixes Suggested-by: Matthew Brost Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250828142430.615826-13-matthew.auld@intel.com

drm/gpusvm: use more selective dma dir in get_pages()

2025-09-05T10:45:46Z

If we are only reading the memory then from the device pov the direction can be DMA_TO_DEVICE. This aligns with the xe-userptr code. Using the most restrictive data direction to represent the access is normally a good idea. Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Matthew Brost Reviewed-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://lore.kernel.org/r/20250828142430.615826-12-matthew.auld@intel.com

drm/gpusvm: fix hmm_pfn_to_map_order() usage

2025-09-05T10:45:46Z

Handle the case where the hmm range partially covers a huge page (like 2M), otherwise we can potentially end up doing something nasty like mapping memory which is outside the range, and maybe not even mapped by the mm. Fix is based on the xe userptr code, which in a future patch will directly use gpusvm, so needs alignment here. v2: - Add kernel-doc (Matt B) - s/fls/ilog2/ (Thomas) Reported-by: Thomas Hellström Signed-off-by: Matthew Auld Cc: Matthew Brost Reviewed-by: Thomas Hellström Link: https://lore.kernel.org/r/20250828142430.615826-11-matthew.auld@intel.com

Merge drm/drm-next into drm-xe-next

2025-08-26T05:08:34Z

Sync with drm-misc-next which is necessary for changes in gpuvm and gpusvm that will be used in xe. Signed-off-by: Lucas De Marchi

drm/gpusvm: Make drm_gpusvm_for_each_* macros public

2025-08-20T04:19:36Z

The drm_gpusvm_for_each_notifier, drm_gpusvm_for_each_notifier_safe and drm_gpusvm_for_each_range_safe macros are useful for locating notifiers and ranges within a user-specified range. By making these macros public, we enable broader access and utility for developers who need to leverage them in their implementations. v2 (Matthew Brost) - drop inline __drm_gpusvm_range_find - /s/notifier_iter_first/drm_gpusvm_notifier_find Signed-off-by: Himal Prasad Ghimiray Reviewed-by: Matthew Brost Signed-off-by: Matthew Brost Link: https://lore.kernel.org/r/20250819162058.2777306-5-himal.prasad.ghimiray@intel.com

drm/pagemap: Rename drm_pagemap_device_addr to drm_pagemap_addr

2025-08-06T11:34:32Z

Rename this struct to the more generic name drm_pagemap_addr so it can be used in a broader context, such as DMA mappings of CPU memory. Reviewed-by: Matthew Brost Acked-by: Maarten Lankhorst Link: https://lore.kernel.org/r/20250805140028.599361-2-francois.dugast@intel.com Signed-off-by: Francois Dugast