wireguard-linux/drivers/gpu/drm/amd/amdkfd, branch stable

drm/amdkfd: preserve VRAM MQD across hibernation via unpin/repin

2026-08-12T13:37:44Z

On gfx9 ASICs with mqd_on_vram(), a compute queue MQD lives in a pinned VRAM buffer object. Pinned BOs are skipped by the VRAM eviction done at S4 suspend, so the MQD contents are lost across hibernation and the first submission after resume page-faults on a stale MQD. Unpin the MQD BO at suspend so the eviction migrates it into the hibernation image, and pin it back to VRAM on resume. The BO may return at a different VRAM address, so refresh the kernel mapping and cached GPU addresses and patch the MQD self-address via a new update_mqd_gpu_addr() mqd_manager op; skip eviction with a warning if that op is not implemented. v3: use unpin/repin instead of shadowing the MQD into a separate buffer. v4: drop the explicit VRAM->GTT placement at evict (a bare unpin is enough for the eviction pass to move the BO out of VRAM), and also repin at queue destroy. KFD queue restore runs late - user processes thaw before it, and under SR-IOV it is deferred until the VF exits full access - so once the VM has resumed an application can destroy a queue before its MQD BO is repinned, which would otherwise unpin an already-unpinned BO and touch a stale q->mqd. v5: drop support for no-HWS mode, and set q->mqd to NULL at eviction. Signed-off-by: Shikang Fan Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdgpu: Fix typo in comment

2026-08-06T17:47:02Z

Fix a spelling mistake in a comment. Signed-off-by: Kenji Takahashi Signed-off-by: Alex Deucher

drm/amdkfd: enable rs64mem for kfd queue

2026-08-06T16:46:14Z

Enabled RS64mem for KFD queues by integrating process and gang context index allocation in the per KFD device process and queue creation. Signed-off-by: Prike Liang Reviewed-by: Michael Chen Signed-off-by: Alex Deucher

drm/amdkfd: Unmap svm range from GPU set to no-access

2026-08-06T13:25:49Z

When KFD_IOCTL_SVM_ATTR_NO_ACCESS is applied to a GPU that has an SVM range mapped, unmap the range from that GPU. Once no GPU maps the range, the MMU notifier can skip queue eviction on CPU page faults. Replace the mapped_to_gpu boolean with bitmap_mapped to track which GPUs currently have the range mapped. Set bits in svm_range_map_to_gpus() and clear them in svm_range_unmap_from_gpus(). This is separate from bitmap_access/bitmap_aip which track user-requested attributes and must not be used to determine mapping state. Add bitmap_needs_unmap to svm_range, set for each GPU given no-access. Add svm_range_needs_unmap() to unmap the range from those GPUs when the app sets the no-access attribute. Bump the checkpoint timestamp on unmap so retry faults queued before the no-access unmap are dropped instead of restoring the mapping. v4: - Rename and set prange->mapping_done to false if validate and map not complete successfully (Felix) v3: - Correct error handling, support app retry update mapping (Felix) v2: - Add bitmap_mapped to not break get_attr (Felix) Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdkfd: Add helper svm_range_update_checkpoint_timestamp

2026-08-06T13:25:42Z

Extract svm_range_update_checkpoint_timestamp() from svm_range_unmap_from_cpu(). The next patch calls it when the app sets the no-access attribute. Change checkpoint_ts in svm_range_list from uint64_t to atomic64_t so svm_range_restore_pages() can read it from the page fault handler without holding the svms lock. No functional change, preparation for the next patch. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdkfd: Remove svm_bo eviction fence

2026-07-29T21:52:20Z

SVM BOs are now migrated back to system memory synchronously from the TTM eviction path (svm_range_evict_svm_bo), so the per-svm_bo eviction fence is no longer used. Remove the eviction fence from svm_range_bo, drop the amdgpu_amdkfd_fence->svm_bo back pointer and the amdgpu_amdkfd_evict_svm_bo() helper, and stop special-casing svm_bo fences in the KFD fence enable_signaling and check_mm paths. Embed struct amdgpu_bo directly in svm_range_bo with a dedicated svm_range_bo_destroy() callback, and keep the owning mm via mmgrab()/mmdrop() instead of through the fence. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdkfd: Evict SVM BOs synchronously from TTM eviction

2026-07-28T23:17:34Z

svm_range_evict_svm_bo_worker() migrated an SVM BO's pages back to system memory from a work item that took mmap_read_lock. When an mmap writer was pending, that read lock blocked behind the writer while the thread allocating a new migration VRAM BO waited on this BO's eviction fence - a circular wait that hung the SVM workers. Evict the SVM BO synchronously from the TTM eviction path (amdgpu_ttm_bo_eviction_valuable) instead of deferring to a work item. The BO is already reserved and the lock order is mmap_lock -> BO reservation, so only trylock the owning process's mmap lock; on contention return -EBUSY so TTM skips this BO. This removes the eviction work item and the enable_signaling path, so no worker can block on mmap_read_lock. The SVM BO uses AMDGPU_GEM_CREATE_DISCARDABLE, so ttm_bo_evict takes the pipeline_gutting path and skips allocating a system memory placement. That would be wasted work, since svm_migrate_vram_to_ram allocates the system pages and copies the data back itself. Eviction now migrates ranges directly, so it must serialize with the owning process: it trylocks migrate_mutex under svm_bo->list_lock before unlinking the range, and svm_range_free() unlinks the range then waits on migrate_mutex, so a concurrent eviction cannot free a range under it. Drop the mm reference with mmput_async so exit_mmap() does not run under the BO reservation. Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher

drm/amdkfd: Fix signal reset event

2026-07-28T23:17:33Z

When a mode reset happens, driver needs to notify the process on that GPU a reset event is happening. The existing code assumes the process is using the GPU that is getting mode reset, which is not always true. For example, on a 8G system, the process may be only using GPU 0~4 but a mode 2 reset is resetting the all 8 GPUs connected by XGMI. Trying to find a process on GPU 5~7 will fail, which is fine and should skip the event signal. Signed-off-by: Amber Lin Reviewed-by: David Yat Sin Signed-off-by: Alex Deucher

drm/amdkfd: allow CWSR grace period of 0 on supported firmware

2026-07-28T23:17:33Z

The debugger sets the CWSR grace period via AMDKFD_IOC_DBG_TRAP and may request a value of 0. An earlier change clamped 0 to 1 unconditionally because most firmware revisions locked up when given an infinite (0) grace period. Firmware has since been fixed on most ASICs, so gate the clamp on ASIC type and MEC firmware version and allow 0 where the running firmware is known to handle it. Navi3x and MI350 support 0 in every firmware revision and need no version check. MI100 never received the firmware fix and is kept clamped. Any unlisted or future ASIC defaults to the safe (clamped) behaviour. Signed-off-by: William Palacek Reviewed-by: Kent Russell Signed-off-by: Alex Deucher

drm/amdkfd: hold event_mutex while checkpointing CRIU events

2026-07-28T23:17:32Z

kfd_criu_checkpoint_events() counts the entries in p->event_idr via kfd_get_num_events(), allocates an array sized to that count, and then walks the same IDR to fill it. Neither the count nor the walk holds p->event_mutex. The CRIU checkpoint caller holds only p->mutex. Event create and destroy (kfd_event_create()/kfd_event_destroy()) take p->event_mutex and do not take p->mutex, so a second thread in the same process can insert or remove events between the count and the walk. If an event is inserted, the walk iterates more entries than were counted and writes past the end of the ev_privs allocation; if an event is removed, the walk dereferences an entry that is being freed. Hold p->event_mutex across the count and the walk so both observe a consistent view of p->event_idr. The lock is released before copy_to_user(), which only touches the local buffer. The caller already holds p->mutex and the create/destroy paths never take p->mutex, so the p->mutex -> p->event_mutex order is not inverted and no deadlock is introduced. Fixes: 40e8a766a761 ("drm/amdkfd: CRIU checkpoint and restore events") Signed-off-by: William Palacek Reviewed-by: Alysa Liu Signed-off-by: Alex Deucher