AMD posts phase-1 amdgpu SVM on shared DRM GPUSVM core

AMD has posted version 10 of a large patch series that rebuilds Shared Virtual Memory (SVM) for amdgpu on the common DRM GPUSVM and drm_pagemap infrastructure, rather than the driver-private KFD SVM path.

The point is convergence. Intel’s Xe driver already uses that shared core for HMM-based unified memory. By adopting the same reviewed page-migration layer, amdgpu stops carrying a parallel stack and both drivers share one path for fault handling, range tracking, and RAM-device migration.

This drop is phase 1 of a staged plan: one GPU, XNACK on (retry faults), compute VMs only. GPU page faults are retried after the driver lazily fills page-table entries. Transparent migration moves pages between system RAM and local VRAM over SDMA, with TTM eviction when VRAM is overcommitted. XNACK-off eager mapping and multi-GPU XGMI/P2P work are deferred to later phases already in progress elsewhere.

The series depends on Christian König’s recent amdgpu VM rework, including eviction-lock changes so VM updates and MMU notifiers can share a read/write semaphore with the GPUSVM notifier path without deadlocking on reclaim. Supporting fixes land in drm_pagemap as well, including correct base-page accounting for compound (THP) migration sources that could under-count and spuriously fail with -EBUSY.

Everything sits behind a new default-n Kconfig option, so the experimental path stays opt-in until the later phases land. For compute users and anyone tracking driver unification, the practical outcome is a single well-reviewed SVM core instead of two divergent implementations.