From: Honglei Huang <honghuan@amd.com>
To: <intel-xe@lists.freedesktop.org>
Cc: Honglei Huang <honghuan@amd.com>
Subject: [PATCH v7 0/5] drm/gpusvm: split MM and device state across gpusvm/range/pages
Date: Mon, 29 Jun 2026 10:29:16 +0800 [thread overview]
Message-ID: <20260629022921.17533-1-honghuan@amd.com> (raw)
The intent of this series is to make drm_gpusvm more flexible and give
drivers more freedom over how they assemble the MM related and device
side operations. It implements the direction Matt suggested in [1]:
Mirror MR in gitlab: [4]
- Move struct drm_gpusvm_pages out of struct drm_gpusvm_range.
- Embed a struct drm_device in struct drm_gpusvm_pages and drive all
DMA through it.
- Drop struct drm_device from struct drm_gpusvm.
- Have the driver's range structure embed one or more struct
drm_gpusvm_pages in addition to struct drm_gpusvm_range.
- Drop the range-based helpers (drm_gpusvm_range_pages_valid,
drm_gpusvm_range_get_pages, drm_gpusvm_range_unmap_pages) and update
drivers to use the drm_gpusvm_pages helpers instead.
In essence the series does only two abstractions, plus the xe
adaptation that follows from them:
- range vs pages: split drm_gpusvm_range (MM / VA range state) from
drm_gpusvm_pages (device physical related), so the two sides can
have independent lifetimes and ownership.
- drm_gpusvm vs drm_device: make drm_gpusvm pure MM level and push
the device side down onto drm_gpusvm_pages, which is where DMA
actually happens.
- xe is updated to fit the modifications, no functional change
intended.
V7:
- patch 1: split MM state flags: the AI review found a KCSAN / memory
model cleanliness issue. Address it for consistency with
drm_gpusvm_pages_flags, set the range flags with WRITE_ONCE() on
__flags and read them with READ_ONCE().
V6:
- The AI review flagged a potential DMA free issue: the DMA unmap
step was moved into the range_free callback, but on the invalidate
path a range can be removed from the MMU interval tree while its DMA
mappings are still live, so a concurrent unmap event can miss it.
- patch 3: have xe_svm_range embed one drm_gpusvm_pages: explicitly
call drm_gpusvm_unmap_pages() before drm_gpusvm_range_remove() in the
garbage collector, so a range is never off the tree while still DMA
mapped, and document this caller contract in drm_gpusvm_range_remove()
kernel-doc.
- patch 4: move struct drm_gpusvm_pages out: document the
unmap before remove contract in the garbage collector example and
note that range_free()'s drm_gpusvm_free_pages() as a final fallback.
- patch 1: split MM state flags: return -EACCES directly.
- Fold in the pre existing IOVA/DMA unmap fixes the AI review found
previously sent separately: the uninitialized dma_addr[0].dir on
the get_pages() error path, the whole reservation IOVA free for
mixed ranges, and the device mapping leak on the get_pages() error
path. [6]
V5:
- add reviewed-by in patches 1, 2, 3, 5 for Matt's review.
V4:
- drm_gpusvm_init_pages(): memset() the pages to zero before recording
the owning drm_device.
- DOC: overview: recommend a zeroing allocator: kcalloc() for the
N:1 pages array.
- Rebased onto the latest drm-xe.
- The AI review of this series flagged two preexisting issues in the
IOVA unmap path that are not introduced by this series; they are
fixed in a separate series [5].
V3:
- Fix a kernel-doc/Sphinx warning from the kernel test robot: use
".. code-block:: c" for the drm_gpusvm_pages example in DOC: overview.
- drm_gpusvm_range_set_unmapped(): use WRITE_ONCE() on the whole
pages[i].flags.__flags word to pair with the lockless READ_ONCE()
readers and avoid a data race.
- xe_userptr_setup(): call drm_gpusvm_init_pages() before
mmu_interval_notifier_insert() to avoid exposing uninitialized
pages.drm to invalidation callbacks.
- Fix per commit build of the set_unmapped() pages.
V2:
- Followed in Matt's v0 review fixups [2]:
- keep unmapped flag in pages structures.
- add pages_count to drm_gpusvm_range_set_unmapped() to set the pages
unmapped flag, so the framework can check unmapped status in
drm_gpusvm_get_pages().
- Add drm_gpusvm_init_pages to init the drm_device and sequence number.
- Remove drm_device from drm_gpusvm_get_pages() parameters.
- Reworked the DOC: overview and usage examples to describe the new
model: struct drm_gpusvm_pages, the 1:1 / N:1 driver layouts, and
examples that operate on a driver embedded pages object by the
drm_gpusvm_pages helpers and etc.
- remove WARN_ON_ONCE in __drm_gpusvm_unmap_pages.
- Dropped RFC.
Follow-up (not in this series):
- modify drm_gpusvm_get_pages() to support one time hmm range fault
and multi drm device dma mapping.
- Add no dma device support for drm_gpusvm_get_pages().
tests:
AMDGPU:
based on amdgpu adaptation patch in [3], but still SVM:DRM = 1:1,
1:n is on going needs many modifications and testings.
Tested on gfx943 (MI300X) and gfx906 (MI60) with XNACK on/off:
- KFD test: 95%+ passed.
- ROCR test: all passed.
- HIP catch test: gfx943 (MI300X): 99% passed.
gfx906 (MI60): 99% passed.
INTEL XE:
Waiting for the xe driver git lab CI result: [4]
links:
[1] https://lore.kernel.org/amd-gfx/acRgr7QwdULsn6G2@gsse-cloud1/#:~:text=I%20think%20roughly,drm_gpusvm_pages%0A%20%20helpers%20instead.
[2] https://gitlab.freedesktop.org/mbrost/xe-kernel-driver-svn-perf-6-15-2025/-/commit/623f6a50c037d9e44f6c9fbe6859a0ba7ad50177
[3] https://lore.kernel.org/amd-gfx/20260603065030.2554403-1-honglei1.huang@amd.com/
[4] https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/360
[5] https://lore.kernel.org/all/20260627033325.3795298-1-honglei1.huang@amd.com/
[6] https://lore.kernel.org/all/20260628061757.4093701-1-honglei1.huang@amd.com/
Honglei Huang (5):
drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flags
drm/gpusvm: embed struct drm_device into drm_gpusvm_pages
drm/xe: have xe_svm_range embed one drm_gpusvm_pages
drm/gpusvm: move struct drm_gpusvm_pages out of struct
drm_gpusvm_range
drm/gpusvm: let the drm_gpusvm core context purely MM level
drivers/gpu/drm/drm_gpusvm.c | 243 +++++++++++++++++++-------------
drivers/gpu/drm/xe/xe_pt.c | 2 +-
drivers/gpu/drm/xe/xe_svm.c | 49 +++++--
drivers/gpu/drm/xe/xe_svm.h | 8 +-
drivers/gpu/drm/xe/xe_userptr.c | 5 +-
include/drm/drm_gpusvm.h | 67 ++++++---
6 files changed, 235 insertions(+), 139 deletions(-)
--
2.34.1
next reply other threads:[~2026-06-29 2:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 2:29 Honglei Huang [this message]
2026-06-29 2:29 ` [PATCH v7 1/5] drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flags Honglei Huang
2026-06-29 2:29 ` [PATCH v7 2/5] drm/gpusvm: embed struct drm_device into drm_gpusvm_pages Honglei Huang
2026-06-29 2:29 ` [PATCH v7 3/5] drm/xe: have xe_svm_range embed one drm_gpusvm_pages Honglei Huang
2026-06-29 2:29 ` [PATCH v7 4/5] drm/gpusvm: move struct drm_gpusvm_pages out of struct drm_gpusvm_range Honglei Huang
2026-06-29 16:27 ` Matthew Brost
2026-06-29 2:29 ` [PATCH v7 5/5] drm/gpusvm: let the drm_gpusvm core context purely MM level Honglei Huang
2026-06-29 18:51 ` ✗ CI.KUnit: failure for drm/gpusvm: split MM and device state across gpusvm/range/pages (rev2) Patchwork
2026-06-30 3:31 ` [PATCH v8 0/5] drm/gpusvm: split MM and device state across gpusvm/range/pages Honglei Huang
2026-06-30 3:31 ` [PATCH v8 1/5] drm/gpusvm: split MM state flags out of drm_gpusvm_pages_flags Honglei Huang
2026-06-30 3:31 ` [PATCH v8 2/5] drm/gpusvm: embed struct drm_device into drm_gpusvm_pages Honglei Huang
2026-06-30 3:47 ` sashiko-bot
2026-06-30 3:31 ` [PATCH v8 3/5] drm/xe: have xe_svm_range embed one drm_gpusvm_pages Honglei Huang
2026-06-30 3:31 ` [PATCH v8 4/5] drm/gpusvm: move struct drm_gpusvm_pages out of struct drm_gpusvm_range Honglei Huang
2026-06-30 3:58 ` sashiko-bot
2026-06-30 3:31 ` [PATCH v8 5/5] drm/gpusvm: let the drm_gpusvm core context purely MM level Honglei Huang
-- strict thread matches above, loose matches on Subject: below --
2026-06-28 11:14 [PATCH v7 0/5] drm/gpusvm: split MM and device state across gpusvm/range/pages Honglei Huang
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=20260629022921.17533-1-honghuan@amd.com \
--to=honghuan@amd.com \
--cc=intel-xe@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.