linux-next.git/drivers/gpu/drm/xe/xe_userptr.c, branch master

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

Merge tag 'drm-misc-next-2026-07-02' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next

2026-07-06T23:34:04+00:00

drm-misc-next for 7.3: UAPI Changes: Cross-subsystem Changes: Core Changes: - bridge: Add atomic_create_state callback and helpers, drop atomic_reset - dp: Add support for DSC max delta BPP - edid: Parse panel type from DisplayID 2.x Display Parameters - sysfb: Improve panel, stride and framebuffer size validation Driver Changes: - hibmc: Improvements to the plane formats handling, switch to gem-shmem - nouveau: race fixes, misc improvements - bridges: - Convert all bridges to atomic_create_state - panels: - panel-edp: New quirks for BOE NE160QDM-NY1, MB116AS01 Signed-off-by: Dave Airlie From: Maxime Ripard Link: https://patch.msgid.link/20260702-powerful-successful-raptor-eded34@houat

drm/xe/userptr: Drop bogus static from finish in force_invalidate

2026-07-02T10:29:43+00:00

The local "finish" pointer in xe_vma_userptr_force_invalidate() is unconditionally written before each read, so the static storage class serves no purpose. Worse, it makes the variable a process-wide shared slot: the function's per-VM asserts do not exclude concurrent callers on different VMs, so two such callers can race on the slot and take the wrong if (finish) branch. The function is gated by CONFIG_DRM_XE_USERPTR_INVAL_INJECT (developer/test option, default n), so production builds are unaffected. Drop the static. Fixes: 18c4e536959e ("drm/xe/userptr: Convert invalidation to two-pass MMU notifier") Assisted-by: Claude:claude-opus-4.7 Cc: Thomas Hellström Cc: Matthew Brost Reviewed-by: Matthew Brost Reviewed-by: Zongyao Bai Link: https://patch.msgid.link/20260625224452.3243231-1-shuicheng.lin@intel.com Signed-off-by: Shuicheng Lin (cherry picked from commit ed382e3b07fae51a09d7290485bff0592f6b168b) Signed-off-by: Thomas Hellström

dma-buf: rename dma_fence_enable_sw_signaling

2026-07-01T14:52:48+00:00

Dropping the _sw_ part from the names was proposed multiple times now and IIRC people generally agreed with the idea already. The function requests a fence to signal and triggers some sort of HW interaction on most backends. So this is not really software related at all and the callback is already just named enable_signaling as well. Just streamline that and use a consistent name everywhere. Assisted-by: Claude Sonet 4 Signed-off-by: Christian König Reviewed-by: Matthew Brost Reviewed-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260624122917.2483-2-christian.koenig@amd.com

drm/xe/userptr: Defer Waiting for TLB invalidation to the second pass if possible

2026-03-11T08:33:01+00:00

Now that the two-pass notifier flow uses xe_vma_userptr_do_inval() for the fence-wait + TLB-invalidate work, extend it to support a further deferred TLB wait: - xe_vma_userptr_do_inval(): when the embedded finish handle is free, submit the TLB invalidation asynchronously (xe_vm_invalidate_vma_submit) and return &userptr->finish so the mmu_notifier core schedules a third pass. When the handle is occupied by a concurrent invalidation, fall back to the synchronous xe_vm_invalidate_vma() path. - xe_vma_userptr_complete_tlb_inval(): new helper called from invalidate_finish when tlb_inval_submitted is set. Waits for the previously submitted batch and unmaps the gpusvm pages. xe_vma_userptr_invalidate_finish() dispatches between the two helpers via tlb_inval_submitted, making the three possible flows explicit: pass1 (fences pending) -> invalidate_finish -> do_inval (sync TLB) pass1 (fences done) -> do_inval -> invalidate_finish -> complete_tlb_inval (deferred TLB) pass1 (finish occupied) -> do_inval (sync TLB, inline) In multi-GPU scenarios this allows TLB flushes to be submitted on all GPUs in one pass before any of them are waited on. Also adds xe_vm_invalidate_vma_submit() which submits the TLB range invalidation without blocking, populating a xe_tlb_inval_batch that the caller waits on separately. v3: - Add locking asserts and notifier state asserts (Matt Brost) - Update the locking documentation of the notifier state members (Matt Brost) - Remove unrelated code formatting changes (Matt Brost) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260305093909.43623-5-thomas.hellstrom@linux.intel.com

drm/xe/userptr: Convert invalidation to two-pass MMU notifier

2026-03-11T08:32:58+00:00

In multi-GPU scenarios, asynchronous GPU job latency is a bottleneck if each notifier waits for its own GPU before returning. The two-pass mmu_interval_notifier infrastructure allows deferring the wait to a second pass, so all GPUs can be signalled in the first pass before any of them are waited on. Convert the userptr invalidation to use the two-pass model: Use invalidate_start as the first pass to mark the VMA for repin and enable software signalling on the VM reservation fences to start any gpu work needed for signaling. Fall back to completing the work synchronously if all fences are already signalled, or if a concurrent invalidation is already using the embedded finish structure. Use invalidate_finish as the second pass to wait for the reservation fences to complete, invalidate the GPU TLB in fault mode, and unmap the gpusvm pages. Embed a struct mmu_interval_notifier_finish in struct xe_userptr to avoid dynamic allocation in the notifier callback. Use a finish_inuse flag to prevent two concurrent invalidations from using it simultaneously; fall back to the synchronous path for the second caller. v3: - Add locking asserts in notifier components (Matt Brost) - Clean up newlines (Matt Brost) - Update the userptr notifier state member locking documentation (Matt Brost) Assisted-by: GitHub Copilot:claude-sonnet-4.6 Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20260305093909.43623-3-thomas.hellstrom@linux.intel.com

drm/xe: Use the drm_pagemap_util helper to get a svm pagemap owner

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

Register a driver-wide owner list, provide a callback to identify fast interconnects and use the drm_pagemap_util helper to allocate or reuse a suitable owner struct. For now we consider pagemaps on different tiles on the same device as having fast interconnect and thus the same owner. v2: - Fix up the error onion unwind in xe_pagemap_create(). (Matt Brost) Signed-off-by: Thomas Hellström Reviewed-by: Matthew Brost Link: https://patch.msgid.link/20251219113320.183860-12-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