mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH v2 0/2] drm/amdkfd: bound SVM mappings by the GPU address limits
@ 2026-10-16 17:05 Daniel Huang
  2026-10-16 17:05 ` [PATCH v2 1/2] drm/amdkfd: disable SVM when the GPUVM cannot cover CPU addresses Daniel Huang
  2026-10-16 17:05 ` [PATCH v2 2/2] drm/amdkfd: validate SVM ranges against the target GPU address limits Daniel Huang
  0 siblings, 2 replies; 3+ messages in thread
From: Daniel Huang @ 2026-10-16 17:05 UTC (permalink / raw)
  To: Felix.Kuehling, alexander.deucher
  Cc: christian.koenig, alex.sierra, Philip.Yang, amd-gfx, dri-devel,
	linux-kernel, stable, Daniel Huang

KFD SVM maps memory in GPUVM at the same virtual address used by the
CPU, but no code bounds that address against what the GPU can actually
represent. kfd_ioctl_svm() validates only page alignment and a non-zero
size, and svm_range_map_to_gpu() passes the PFNs straight to
amdgpu_vm_update_range(). The BO mapping path, by contrast, validates
through amdgpu_vm_verify_parameters().

Patch 1 is the crash reported in [1]: with an explicit amdgpu.vm_size
override the GPUVM can be smaller than the CPU address range, and the
page-table walker indexes past the root page-table entries. It disables
SVM when the GPUVM cannot cover AMDGPU_GMC_HOLE_START.

Patch 2 addresses a gap in that check, found by the Sashiko AI review
bot [3]. The comparison is against the GPU's own address hole, so on a
system whose CPU address space is larger than the GPU's it succeeds and
SVM stays enabled, while individual addresses can still fall outside the
GPUVM. Every current GMC generation uses a 4-level, 48-bit GPUVM except
one gfx12 variant, so a 5-level paging CPU reaches this whenever
userspace passes an mmap hint above DEFAULT_MAP_WINDOW.

Patch 2 validates each range against the limits of the GPU it is mapped
on instead, covering the mapping, unmapping and fault recovery paths.
Using TASK_SIZE_MAX for the patch 1 check was considered and rejected:
it would disable SVM on every 5-level paging host for every 4-level
GPU, including the gfx9 datacenter parts.

Patch 2 alone would also prevent the crash in [1], by rejecting the
mapping rather than by refusing to advertise SVM. Both are included
because without patch 1 the topology still reports
HSA_CAP_SVMAPI_SUPPORTED, so userspace sees runtime failures instead of
a clear signal that the device cannot do SVM. If only one is wanted,
dropping either is straightforward.

Changes since v1 [2]:
- Moved the warning from amdgpu_amdkfd_device_init() to
  kfd_update_svm_support_properties(). pgmap.type is only assigned in
  kgd2kfd_init_zone_device(), which runs in late init, after
  amdgpu_amdkfd_device_init(). Testing the capability at the old site
  therefore never fired for dGPUs, and amdgpu_reset.c calls the two in
  the opposite order, making the behaviour path dependent.
- Scoped the warning to devices that would otherwise have advertised
  SVM, so GMC v6/v7/v8 no longer warn, and made it dev_warn_once() since
  the surrounding loop can match several topology nodes per adev.
- Guarded the new code with CONFIG_HSA_AMD_SVM. kfd_topology.o builds
  unconditionally while kfd_svm.o does not, so the reference to the new
  helper breaks a CONFIG_HSA_AMD_SVM=n build without it.
- Fixed the [1] reference, which was a placeholder in v1.
- Added patch 2.

[1] https://lore.kernel.org/amd-gfx/da43b0e3-5bd9-4aa1-86d3-b733f3bad108@amd.com/
[2] https://lore.kernel.org/amd-gfx/20261016145129.69645-1-danielhu@amd.com/
[3] https://sashiko.dev/#/patchset/20261016145129.69645-1-danielhu%40amd.com

Per Documentation/process/generated-content.rst: an AI coding assistant
was used throughout this series, as recorded by the Assisted-by tags. It
diagnosed the fault path ordering that determines where patch 1 emits
its warning, designed kfd_svm_range_fits_gpu() and its call sites in
patch 2, and drafted both changelogs and this cover letter. I reviewed
and tested the result and take responsibility for it.

Patch 1 is tested on a Radeon 780M as described in its notes. Patch 2 is
compile-tested only; I do not have a 5-level paging host with a 4-level
GPU to exercise the out-of-range path directly, so review of the bounds
arithmetic in kfd_svm_range_fits_gpu() would be welcome.

Daniel Huang (2):
  drm/amdkfd: disable SVM when the GPUVM cannot cover CPU addresses
  drm/amdkfd: validate SVM ranges against the target GPU address limits

 drivers/gpu/drm/amd/amdkfd/kfd_svm.c      | 42 +++++++++++++++++++++
 drivers/gpu/drm/amd/amdkfd/kfd_svm.h      | 45 ++++++++++++++++++++++-
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 14 ++++++-
 3 files changed, 98 insertions(+), 3 deletions(-)


base-commit: fe9f3ed36c83dcc24b4ca3e8913edd6e33a89150
-- 
2.53.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-10-16  9:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-16 17:05 [PATCH v2 0/2] drm/amdkfd: bound SVM mappings by the GPU address limits Daniel Huang
2026-10-16 17:05 ` [PATCH v2 1/2] drm/amdkfd: disable SVM when the GPUVM cannot cover CPU addresses Daniel Huang
2026-10-16 17:05 ` [PATCH v2 2/2] drm/amdkfd: validate SVM ranges against the target GPU address limits Daniel Huang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®