[RFC PATCH 0/3] drm/amdgpu: unify SVM notifier and VM eviction locking

[Honglei Huang <honglei1.huang@amd.com>]

From: Honglei Huang <honghuan@amd.com>

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.

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(-)

-- 
2.34.1