Re: [PATCH v10 08/22] drm/amdgpu: implement SVM range notifier and GC helpers

["Huang, Honglei" <honghuan@amd.com>]

On 11/10/2026 1:12 AM, Aveline Noir wrote:
> Hi Ray,
> 
> On Wed, 21 Oct 2026 10:58:47 +0800 Huang Rui wrote:
> 
>> + * Invalidate the GPU view of @range over the notifier window: zap the
>> + * affected PTEs and clear the gpu_mapped flag. The range is not removed
>> + * here; structural removal if needed happens in the event-end phase.
> 
> I think this can leave stale PTEs behind when only part of a range is
> invalidated. Take a one-page notifier event on a larger system-memory
> range mapped with 4K PTEs. This zaps that one PTE but clears gpu_mapped
> for the whole range, and then the event-end callback unmaps DMA for the
> whole range. The other PTEs are still valid at that point, but their DMA
> mappings are gone. A later notifier won't zap them either, because
> gpu_mapped is already false.
> 
> Maybe the zap should cover the full range when its DMA mapping is
> going away?

Yes, the zep should cover the entire range, will fix it in next version.

> 
>> +			if (crosses_boundary) {
> 
> Another case is GPU_RO going from 1 to 0 over a whole mapped
> GPUSVM range. This branch isn't taken, so the PTEs are zapped but the
> old DMA_TO_DEVICE mapping stays around. The next get_pages() sees valid
> pages and reuses it, so the writable GPU PTE goes in without an
> HMM_PFN_REQ_WRITE fault or a DMA_BIDIRECTIONAL remap. If it's a VM_WRITE
> MAP_PRIVATE mapping whose CPU PTE still needs COW, I think it can miss
> the write fault. So could the old DMA mapping be dropped before the
> writable PTE goes in?

Will apply the drm_gpusvm_unmap_pages when attr is change, regardless of 
whether crosses_boundary.

> 
> I couldn't tell from the cover which drm_gpusvm base this is on, so I
> used 671b7825dbfe for both of these. I haven't reproduced either one on
> a GPU, though.

Regards,
Honglei

> 
> Thanks,
> Aveline Noir