From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
dri-devel@lists.freedesktop.org, himal.prasad.ghimiray@intel.com,
apopple@nvidia.com, airlied@gmail.com,
"Simona Vetter" <simona.vetter@ffwll.ch>,
"Felix Kühling" <felix.kuehling@amd.com>,
"Philip Yang" <philip.yang@amd.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Christian König" <christian.koenig@amd.com>,
dakr@kernel.org, "Mrozek, Michal" <michal.mrozek@intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>
Subject: [PATCH v3 0/3] drm/gpusvm, drm/pagemap, drm/xe: Restructure migration in preparation for multi-device
Date: Fri, 13 Jun 2025 16:02:16 +0200 [thread overview]
Message-ID: <20250613140219.87479-1-thomas.hellstrom@linux.intel.com> (raw)
This patchset modifies the migration part of drm_gpusvm to drm_pagemap and
adds a populate_mm() op to drm_pagemap.
The idea is that the device that receives a pagefault determines if it wants to
migrate content and to where. It then calls the populate_mm() method of relevant
drm_pagemap.
This functionality was mostly already in place, but hard-coded for xe only without
going through a pagemap op. Since we might be dealing with separate devices moving
forward, it also now becomes the responsibilit of the populate_mm() op to
grab any necessary local device runtime pm references and keep them held while
its pages are present in an mm (struct mm_struct).
On thing to decide here is whether the populate_mm() callback should sit on a
struct drm_pagemap for now while we sort multi-device usability out or whether
we should add it (or something equivalent) to struct dev_pagemap.
v2:
- Rebase.
v3:
- Documentation updates (CI, Matt Brost)
- Don't change TTM buffer object type for VRAM allocations (Matt Brost)
Matthew Brost (1):
drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemap
Thomas Hellström (2):
drm/pagemap: Add a populate_mm op
drm/xe: Implement and use the drm_pagemap populate_mm op
Documentation/gpu/rfc/gpusvm.rst | 12 +-
drivers/gpu/drm/Makefile | 6 +-
drivers/gpu/drm/drm_gpusvm.c | 760 +-----------------------
drivers/gpu/drm/drm_pagemap.c | 832 +++++++++++++++++++++++++++
drivers/gpu/drm/xe/Kconfig | 10 +-
drivers/gpu/drm/xe/xe_bo_types.h | 2 +-
drivers/gpu/drm/xe/xe_device_types.h | 2 +-
drivers/gpu/drm/xe/xe_svm.c | 124 ++--
drivers/gpu/drm/xe/xe_svm.h | 10 +-
drivers/gpu/drm/xe/xe_tile.h | 11 +
drivers/gpu/drm/xe/xe_vm.c | 2 +-
include/drm/drm_gpusvm.h | 96 ----
include/drm/drm_pagemap.h | 135 +++++
13 files changed, 1090 insertions(+), 912 deletions(-)
create mode 100644 drivers/gpu/drm/drm_pagemap.c
--
2.49.0
next reply other threads:[~2025-06-13 14:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 14:02 Thomas Hellström [this message]
2025-06-13 14:02 ` [PATCH v3 1/3] drm/gpusvm, drm/pagemap: Move migration functionality to drm_pagemap Thomas Hellström
2025-06-17 12:55 ` Ghimiray, Himal Prasad
2025-06-17 13:11 ` Thomas Hellström
2025-06-17 14:47 ` Ghimiray, Himal Prasad
2025-06-17 14:55 ` Thomas Hellström
2025-06-17 17:04 ` Matthew Brost
2025-06-17 19:37 ` Thomas Hellström
2025-06-17 20:44 ` Matthew Brost
2025-06-13 14:02 ` [PATCH v3 2/3] drm/pagemap: Add a populate_mm op Thomas Hellström
2025-06-17 17:05 ` Matthew Brost
2025-06-13 14:02 ` [PATCH v3 3/3] drm/xe: Implement and use the drm_pagemap " Thomas Hellström
2025-06-17 17:09 ` Matthew Brost
2025-06-17 19:24 ` Thomas Hellström
2025-06-13 15:56 ` ✗ CI.checkpatch: warning for drm/gpusvm, drm/pagemap, drm/xe: Restructure migration in preparation for multi-device (rev3) Patchwork
2025-06-13 15:57 ` ✓ CI.KUnit: success " Patchwork
2025-06-13 17:09 ` ✓ Xe.CI.BAT: " Patchwork
2025-06-15 9:44 ` ✗ Xe.CI.Full: failure " Patchwork
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=20250613140219.87479-1-thomas.hellstrom@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=apopple@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=felix.kuehling@amd.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.mrozek@intel.com \
--cc=philip.yang@amd.com \
--cc=simona.vetter@ffwll.ch \
/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.