Re: [PATCH] mm/hmm: honor write requests for owned device-private pages

["Christian König" <christian.koenig@amd.com>]

Hi Aveline,

On 11/2/26 13:23, Aveline Noir wrote:
> Hi all,
> 
> On Sun, 01 Nov 2026 19:58:21 +1100 Aveline Noir wrote:
> 
>> Oh, I missed that. I'll try to fix it.
> 
> While working on this, I found that the fix reaches well beyond
> mm/hmm.c and would likely need rework in several subsystems, so I'd
> like to hear your views before going further. v1 shouldn't be applied
> as is.
> 
> amdkfd holds svms->lock and prange->migrate_mutex across
> hmm_range_fault(), and svm_migrate_to_ram() needs both, so it can't
> migrate the page for the validating task. Migrating under those locks
> can deadlock, since do_swap_page() waits for the device page lock, which
> a concurrent CPU fault can hold while waiting for svms->lock.

Yeah those issues are already known.

Because of that AMDs KFD team is in the process of replacing the self made KFD based SVN handling with the drm_gpusvm module which is also used by Intels XE driver.

> From
> reading the code, amdkfd also maps such read-only pages writable today,
> as it takes GPU write permission from the VMA rather than from
> HMM_PFN_WRITE, so GPU writes after fork() would be visible to the child.
> I haven't been able to confirm this on hardware.

That is a new issue as far as I know.

> One option I tried is an opt-in HMM flag that returns -EDEADLK and the
> page address instead of faulting, so amdkfd can drop its locks, fault
> the page and validate again. It works with test_hmm, but the amdkfd
> side grew to about 550 lines across the GPU fault handler, the restore
> worker and svm_range_set_attr(), and is only compile-tested. Read-only
> entries also come from NUMA hinting scans and mprotect(), so pages that
> aren't shared would be moved out of VRAM too, and Xe and nouveau would
> see their pages migrated in the same cases.

I don't think we should try to fix the KFD SVM code, as said we are already in the process of ditching it because of those problems.

> Would you prefer an opt-in interface like this, a change to the amdkfd
> locking so that migrate_to_ram() can run during validation, or
> something else? I can post the amdkfd part as an RFC if that helps.
> 
> I also found a few smaller related issues, and I'll send fixes for them
> separately.

There is also https://gitlab.freedesktop.org/drm/amd/-/work_items/6003 which I'm not sure how to properly handle.

Current AMD GPUs don't have dirty tracking in their GPUVM, so it doesn't really make sense to set the PTE or struct page dirty from the MMU notifier (both data pointers are not around there any more).

We also can't set the page dirty directly after calling hmm_range_fault() because we don't own a page reference and so it could change at any time.

At least for the GFX CS path it would make most sense to set the pages dirty in hmm_range_fault(), not sure about the SVM use case.

Regards,
Christian.

> 
> Thanks,
> Aveline Noir