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/[email protected]/ [2] https://lore.kernel.org/amd-gfx/[email protected]/ [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
