Re: [RFC v2 18/21] drm/xe/svm: Define access counter migration policy

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Access counter triggered setup for un-migratable ranges incorrectly returns -EACCES, dropping valid events and rendering the graceful skip path unreachable.
- [Medium] Stale access counter events bypass the explicitly configured madvise preferred location policy.
--

commit 7722d68606c2a2a1e92cb30c951c55b50aca4779
Author: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>

drm/xe/svm: Define access counter migration policy

This commit defines the policy for which GPU should own access
counter-triggered migration in a multi-GPU system, keying off the VMA's madvise
preferred location. It configures the PTE NC (no-count) bit based on this
preference.

> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index 7aa09e30fa467..fd42969d9e620 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c
[ ... ]
> @@ -1339,9 +1371,15 @@ static int __xe_svm_range_setup(struct xe_vm *vm, struct xe_vma *vma,
>  
>  	range_debug(range, "PAGE FAULT");
>  
> -	if (acc_ctr_trigger && !range_flags.migrate_devmem) {
> +	/*
> +	 * AC-triggered setup: if the range is already in device memory a
> +	 * rebind is all that's needed.  Otherwise proceed to the
> +	 * migration path — with no explicit madvise preferred location, the
> +	 * default first-touch-then-migrate-on-hot policy applies and we
> +	 * should attempt VRAM placement for this hot range.
> +	 */
> +	if (acc_ctr_trigger && !range_flags.migrate_devmem)
>  		goto out;

[Severity: Medium]
This is a pre-existing issue, but does this explicit graceful skip path ever
get reached?

Earlier in __xe_svm_range_setup(), the code checks:

	if (ctx.devmem_only && !range_flags.migrate_devmem) {
		err = -EACCES;
		goto err_out;
	}

Since setting acc_ctr_trigger to true forces ctx.devmem_only to true, the
earlier check appears to force a hard failure (-EACCES) for access counter
events on un-migratable ranges, masking this intended graceful skip.

This could cause the access counter worker in
xe_access_counter_queue_work_func() to abort the loop for the current
granularity window, dropping legitimate migration hints for other VMAs in the
same window.

Is this the intended behavior, or should the access counter triggers be treated
as advisory and gracefully skipped?

[Severity: Medium]
This is also a pre-existing issue, but can stale access counter events bypass
the explicitly configured madvise preferred location policy?

Earlier in __xe_svm_range_setup(), dpagemap is resolved as follows:

	dpagemap = ctx.devmem_only ? xe_tile_local_pagemap(tile) :
		xe_vma_resolve_pagemap(vma, tile);

Because acc_ctr_trigger sets ctx.devmem_only to true, this unconditional
ternary assignment always sets the target to the local tile for access counter
events, completely bypassing the xe_vma_resolve_pagemap() policy check.

If a userspace application makes asynchronous madvise calls concurrently with
GPU memory accesses to set the preferred location to
DRM_XE_PREFERRED_LOC_DEFAULT_SYSTEM, could the memory be incorrectly migrated
to the local GPU's VRAM?

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