Re: [RFC v2 19/21] drm/xe/svm: Add MIGRATE_ON_ACCESS_COUNTER bind flag

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The MIGRATE_ON_ACCESS_COUNTER flag unconditionally blocks VRAM migration on page faults, breaking device atomics and explicit madvise placement.
--

commit 4c656fa9adbce2593cc353b10a62bd8a06ad4f02
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>

drm/xe/svm: Add MIGRATE_ON_ACCESS_COUNTER bind flag

This commit introduces a new bind flag allowing userspace to defer
first-touch VRAM migration until an access counter event indicates the
range is hot.

> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index fd42969d9e620..58063b1c97377 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c
[ ... ]
> @@ -1381,7 +1384,13 @@ static int __xe_svm_range_setup(struct xe_vm *vm, struct xe_vma *vma,
>  	if (acc_ctr_trigger && !range_flags.migrate_devmem)
>  		goto out;
>  
> +	/*
> +	 * With MIGRATE_ON_ACCESS_COUNTER, defer first placement to access
> +	 * counters: skip the eager migrate on a normal page fault, but still
> +	 * migrate when this setup was itself triggered by an AC event.
> +	 */
>  	if (--migrate_try_count >= 0 &&
> +	    (acc_ctr_trigger || !(vma->gpuva.flags & XE_VMA_MIGRATE_ON_ACC)) &&
>  	    xe_svm_range_needs_migrate_to_vram(range, vma, dpagemap)) {
>  		ktime_t migrate_start = xe_gt_stats_ktime_get();

[Severity: High]
Does this condition inadvertently block VRAM migration on initial faults
when XE_VMA_MIGRATE_ON_ACC is set, even if device atomics or madvise
require it?

If an application binds a VMA with the new flag and then performs a device
atomic operation (which sets ctx.devmem_only and need_vram to true) or
uses madvise to set a preferred device location (which provides dpagemap),
the page fault handler will reach this check with acc_ctr_trigger set to
false.

Because acc_ctr_trigger is false and the new flag is set, the condition
short-circuits. This skips xe_svm_alloc_vram() entirely in
__xe_svm_range_setup().

The subsequent xe_svm_range_get_pages() call will then fail with -EOPNOTSUPP
because ctx.devmem_only demands VRAM placement that was just bypassed, which
could result in an unresolvable page fault and cause the application to crash.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909124457.1610890-23-himal.prasad.ghimiray@intel.com?part=19