Claude review: drm/amdgpu: SVM VRAM migration via drm_pagemap

[Claude Code Review Bot <claude-review@example.com>]

Overall Series Review

Subject: drm/amdgpu: SVM VRAM migration via drm_pagemap
Author: Junhua Shen <Junhua.Shen@amd.com>
Patches: 7
Reviewed: 2026-04-28T14:43:03.699323

---

This is a v3 of a 5-patch series adding VRAM migration support to the amdgpu SVM subsystem via `drm_pagemap`. The architecture is sound — it layers cleanly on top of the existing drm_pagemap/drm_gpusvm infrastructure with a clear separation of concerns: infrastructure (patch 1), SDMA callbacks (patch 2), decision layer (patch 3), attribute extensions (patch 4), and integration (patch 5).

The series builds on an unmerged dependency (the drm_pagemap SVM series), which explains why patches don't apply to drm-next. Within its own scope, the code is reasonably well-structured.

**Key concerns:**

1. **The `pre_migrate_fence` parameter is completely ignored** in both `copy_to_devmem` and `copy_to_ram`. The drm_pagemap API documentation explicitly states this fence "must be waited for before migration start." This is a correctness bug that can cause data races.

2. **Migration failure in the map path is silently ignored** (patch 5) — `amdgpu_svm_range_migrate_range()` return value is discarded.

3. **The `amdgpu_svm_range_rebuild_locked()` behavior change** in patch 5 drops the GPU unmap + TLB flush fallback path with no replacement, which looks like a regression for the `!rebuild` case.

4. **Variable declaration after statement** in patch 5 (`enum amdgpu_svm_migrate_mode` declared after `lockdep_assert_held_write()`), which violates C89 style expected by the kernel.

5. **`AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS`** forces contiguous VRAM for every migration, which will cause allocation failures under fragmentation. This should be reconsidered.

---

---
Generated by Claude Code Patch Reviewer