On 8/30/2026 11:40 PM, Honglei Huang wrote:
From: Honglei Huang <[email protected]>
This series follows Christian's suggestions and builds on his earlier
fix work in the amdgpu VM critical section.
My understanding of all amdgpu VM locking details may be incomplete, so
review and confirmation from the VM maintainers would be appreciated.
Hi Christian,
We are preparing the V10 of amdgpu drmsvm, cause your fix series
(drm/amdgpu: fix the HMM range handling for KFD SVM) is absolutely necessary
for the amdgpu drmsvm, so can we
- Include your fix series into the amdgpu drm svm series, cause it is
easy to rebase / test / cherry pick.
- The hole series based on your locking unify design so will add
suggested by you in entire amdgpu drm svm patches.
- Your fix series maybe need some base / change according to the latest
amdgpu drm next, so can we add co-developed by in your fix series?
Regards,
Honglei
It is described that the ordering problem and why both paths need the
same lock:
"Originally the notifier_lock only made sure that the CPU page table
updates were done in order and originally the eviction lock made sure
that the GPU page table updates were done in order, but essentially we
need the order for both.
The point is that the updates need to be serialized. In other words
when one CPU is doing a mapping operation and another CPU is doing an
unmap through an MMU notifier we somehow need to make sure that the
corresponding GPU page table updates execute in the correct order."
Before this series, the update flow uses two locks:
map thread:
notifier_lock (lock A)
validate range
pt_alloc drops only eviction_lock (lock B)
allocation enters direct reclaim
MMU notifier tries notifier_lock (lock A again)
deadlock here
The allocation cannot finish because reclaim waits for a read lock that
the same thread releases only after the allocation returns.
The VM helper also cannot drop and revalidate the notifier lock because
it only knows about the separate eviction lock.
After this series, all three paths use the same rwsem:
map thread:
unified notifier/eviction lock for read (lock A)
validate range
pt_alloc drops lock A
allocation can enter reclaim
MMU notifier can take lock A for write and finish
reacquire lock A for read
revalidate range
range valid -> update PTEs and PDEs -> publish the mapping
range changed -> return -EAGAIN and retry
MMU notifier / eviction:
unified notifier/eviction lock for write (lock A)
clear PTEs or evict page tables
The allocation no longer holds lock A during reclaim. If an MMU
notifier invalidates the range while lock A is dropped, the map thread
detects the changed range after reacquiring lock A and retries instead
of installing stale PTEs.
The three patches make the VM eviction lock read/write, support a
caller held lock with post allocation range revalidation, and use the
drm_gpusvm notifier lock for SVM VMs. Non SVM callers pass NULL and keep
the existing internal locking path.
The patches apply after the AMDGPU SVM build and VM fault-path
integration patch.
Testing:
MI60: KFD svm test passed, 2 known attribute failures (attribute get
refactor).
HIP catch_tests: 98% passed.
Honglei Huang (3):
drm/amdgpu: make VM eviction lock read/write to match notifier lock
drm/amdgpu: recheck range validity after page table allocation
drm/amdgpu: use drm_gpusvm notifier lock for VM eviction
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_svm.c | 37 ++++++--
drivers/gpu/drm/amd/amdgpu/amdgpu_svm_range.c | 52 +++++-------
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 84 ++++++++++++-------
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 15 ++--
.../gpu/drm/amd/amdgpu/amdgpu_vm_internal.h | 30 ++++++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 29 ++++++-
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 7 +-
11 files changed, 176 insertions(+), 86 deletions(-)
