From: Honglei Huang <honghuan@amd.com>
To: <matthew.brost@intel.com>, <sima@ffwll.ch>,
<rodrigo.vivi@intel.com>, <thomas.hellstrom@linux.intel.com>,
<himal.prasad.ghimiray@intel.com>, <dakr@kernel.org>,
<intel-xe@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>
Cc: <aliceryhl@google.com>, <Alexander.Deucher@amd.com>,
<Felix.Kuehling@amd.com>, <Christian.Koenig@amd.com>,
<Ray.Huang@amd.com>, <Junhua.Shen@amd.com>,
<amd-gfx@lists.freedesktop.org>, <honghuan@amd.com>
Subject: [PATCH v4 0/6] drm/gpusvm: share one HMM fault and keep single mappings inline
Date: Sat, 5 Sep 2026 21:31:36 +0800 [thread overview]
Message-ID: <20260905133142.3628027-1-honghuan@amd.com> (raw)
Patches 1 to 4 are the get_pages() split already posted as v2. Patches 5
and 6 implement the dma_addr storage optimization Matt suggested in [6].
They build on the DMA paths v2 reworks, so they are sent in the same
series; I can split them out if that is preferred.
drm_gpusvm_get_pages() does two things at once: the MM level HMM fault
of the CPU range, and the device DMA mapping of the faulted pages. When
one CPU range is mirrored on several devices, every device has to call
get_pages() and redo the HMM fault. Matt suggested [2] passing an array
of drm_gpusvm_pages plus a count so the fault is taken once and shared,
while the notifier retry loop stays in common code so drivers never open
code it.
For patches 5 and 6, the focus is on optimizing the storage of DMA
addresses for THP pages and IOVA mapped ranges. get_pages() sizes
dma_addr for the worst case of one entry per page, but the mapping loop
advances by page order, so a 2 MiB THP holds an 8 KiB array with 16
bytes of address in it. Patch 5 keeps that single mapping inline. Patch
6 extends the optimization to IOVA mapped ranges, where contiguous
device addresses allow for a similar inline approach.
A range folds only when one drm_pagemap_addr describes all of it, which
leaves three shapes not included:
- Mixed device and system pages: the device addresses come from
device_map(), outside the IOVA reservation, so they are not
contiguous. Not included for inline storage.
- Mixed orders: contiguous under IOVA and foldable in principle, but
one entry carries one order; expressing two needs an entry count or
a segment iterator. Needs additional handling for mixed orders.
So not included for this inline storage change.
- Several huge entries: needs a chunk larger than PMD size, which no
consumer configures today.
Patches overview:
- patch 1 moves the dma_addr allocation out of the notifier locked
section, so the mapping step becomes self contained.
- patch 2 pulls the per-device mapping loop into
drm_gpusvm_dma_map_pages(). Code motion only.
- patch 3 makes get_pages() take an array of drm_gpusvm_pages plus a
count: fault once, then DMA map each instance, one per owning
drm_device, under a single notifier retry gate. Instances that are
already mapped are skipped, so an -EAGAIN retry does not redo them.
The common 1:1 case passes count == 1 and is unchanged.
- patch 4 adds a no_dma_map context flag so a driver that only needs
the CPU pages faulted in can skip the device DMA mapping.
- patch 5: keeps a single mapping inline for THP.
- patch 6: extends that to IOVA mapped ranges.
v2:
- Rebased on drm-tip.
- Dropped v1 patch 1 ("drm/gpusvm: extract drm_gpusvm_hmm_fault()
helper"), it is part of [3] now.
- patch 3: drm_gpusvm_pages_valid_unlocked() takes the array and the
count itself, instead of get_pages() open coding an all_valid loop.
- patch 3: fixed the N:1 doc example, it used the wrong union member
when the count is 1. Added a driver_pages() accessor.
- patch 3: documented that on error the instances mapped before the
failing one stay mapped, the caller must unmap and free all of them.
- patch 4: reject no_dma_map together with devmem_only, without the
DMA mapping step there is no page type check to enforce it.
- patch 4: documented that no_dma_map only returns a snapshot, the
caller must recheck mmu_interval_read_retry() itself.
V3:
- Patch 3: check svm_pages[0].flags.unmapped instead of walking every
instance, per Matt's review. drm_gpusvm_range_set_unmapped() flags
the whole array in one go under the write lock, so any instance
answers for all of them.
- Patch 3: reject a zero page count instead of relying on the caller.
- Patch 5: new, keeps a single mapping inline for THP.
- Patch 6: new, extends that to IOVA mapped range.
- Add Reviewed-by Matt in patches 1, 2 and 4.
V4:
- Patch 5: add xe_svm_range_first_dma(), with a stub for the
CONFIG_DRM_XE_GPUSVM disabled build, so xe_pt_stage_bind() type
checks in both configurations. Reported by Intel CI [7].
- Patch 6: the wrapper hands out the contiguous flag too, and the stub
clears it.
- Add Reviewed-by Matt in patch 3.
tests:
AMDGPU:
SVM:DRM N:1 multi device support is work in progress on top of this
series. The single device (1:1) path was tested with the amdgpu SVM
adaptation on top. Based on amdgpu SVM [4].
Tested on gfx906 (MI60) with XNACK on, in three configurations:
THP ON + IOVA ON, THP ON + IOVA OFF, NO THP + NO IOVA.
- KFD test: SVM all passed except the get attr refactor.
- ROCR test: all passed.
- HIP catch test: gfx943 (MI300X): 99% passed.
gfx906 (MI60): 99% passed.
links:
[1] drm_gpusvm_pages decoupling series:
https://lore.kernel.org/amd-gfx/20260630102127.392396-1-honghuan@amd.com/
[2] Matt's suggested direction:
https://lore.kernel.org/amd-gfx/aijdg7RWwrEDEMxC@gsse-cloud1.jf.intel.com/
[3] drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults:
https://lore.kernel.org/20260723-hmm-v10-v11-8-c55b003a4b61@gmail.com
[4] amdgpu SVM:
https://lore.kernel.org/amd-gfx/20260804094246.1719318-1-ray.huang@amd.com/
[5] v2 of this series:
https://lore.kernel.org/amd-gfx/20260901090100.2024933-1-honghuan@amd.com/
[6] Matt on keeping the dma address inline:
https://lore.kernel.org/amd-gfx/apcp%2FXJpPdG3jzPd@gsse-cloud1.jf.intel.com/
[7] Intel CI build report on v3:
https://patchwork.freedesktop.org/series/173405/
Honglei Huang (6):
drm/gpusvm: move dma_addr allocation before the notifier lock
drm/gpusvm: extract drm_gpusvm_dma_map_pages() helper
drm/gpusvm: let drm_gpusvm_get_pages() map an array of pages
drm/gpusvm: make the DMA mapping step in get_pages() optional
drm/gpusvm: keep a single DMA mapping inline for THP
drm/gpusvm: keep an IOVA mapped range dma address inline
drivers/gpu/drm/drm_gpusvm.c | 406 +++++++++++++++++++++--------
drivers/gpu/drm/xe/xe_pt.c | 22 +-
drivers/gpu/drm/xe/xe_res_cursor.h | 5 +-
drivers/gpu/drm/xe/xe_svm.c | 2 +-
drivers/gpu/drm/xe/xe_svm.h | 20 ++
drivers/gpu/drm/xe/xe_userptr.c | 2 +-
include/drm/drm_gpusvm.h | 71 ++++-
7 files changed, 400 insertions(+), 128 deletions(-)
base-commit: 313da1cc22491f07075c7ae36372343aa235d11e
--
2.34.1
next reply other threads:[~2026-09-05 13:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 13:31 Honglei Huang [this message]
2026-09-05 13:31 ` [PATCH v4 1/6] drm/gpusvm: move dma_addr allocation before the notifier lock Honglei Huang
2026-09-05 13:31 ` [PATCH v4 2/6] drm/gpusvm: extract drm_gpusvm_dma_map_pages() helper Honglei Huang
2026-09-05 13:31 ` [PATCH v4 3/6] drm/gpusvm: let drm_gpusvm_get_pages() map an array of pages Honglei Huang
2026-09-05 13:31 ` [PATCH v4 4/6] drm/gpusvm: make the DMA mapping step in get_pages() optional Honglei Huang
2026-09-05 13:31 ` [PATCH v4 5/6] drm/gpusvm: keep a single DMA mapping inline for THP Honglei Huang
2026-09-08 3:12 ` Matthew Brost
2026-09-05 13:31 ` [PATCH v4 6/6] drm/gpusvm: keep an IOVA mapped range dma address inline Honglei Huang
2026-09-08 3:18 ` Matthew Brost
2026-09-08 3:49 ` Matthew Brost
2026-09-08 5:40 ` Huang, Honglei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260905133142.3628027-1-honghuan@amd.com \
--to=honghuan@amd.com \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Felix.Kuehling@amd.com \
--cc=Junhua.Shen@amd.com \
--cc=Ray.Huang@amd.com \
--cc=aliceryhl@google.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=sima@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox