Re: [RFC 15/15] drm/xe/pt: Set NC PTE bit for VMAs ineligible for access counting

[Matthew Brost <matthew.brost@intel.com>]

On Wed, Mar 18, 2026 at 01:14:56PM +0530, Himal Prasad Ghimiray wrote:
> Set XE_PPGTT_PTE_NC on PTEs for VMAs that can't benefit from access
> counter migration hints, avoiding wasteful slot allocation.
> 
> Bspec: 67095
> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> ---
>  drivers/gpu/drm/xe/regs/xe_gtt_defs.h |  2 +-
>  drivers/gpu/drm/xe/xe_pt.c            | 11 +++++++++++
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/regs/xe_gtt_defs.h b/drivers/gpu/drm/xe/regs/xe_gtt_defs.h
> index 4d83461e538b..ace3cbcc13d8 100644
> --- a/drivers/gpu/drm/xe/regs/xe_gtt_defs.h
> +++ b/drivers/gpu/drm/xe/regs/xe_gtt_defs.h
> @@ -28,11 +28,11 @@
>  #define XE_GGTT_PTE_DM			BIT_ULL(1)
>  #define XE_USM_PPGTT_PTE_AE		BIT_ULL(10)
>  #define XE_PPGTT_PTE_DM			BIT_ULL(11)
> +#define XE_PPGTT_PTE_NC			BIT_ULL(5)
>  #define XE_PDE_64K			BIT_ULL(6)
>  #define XE_PTE_PS64			BIT_ULL(8)
>  #define XE_PTE_NULL			BIT_ULL(9)
>  
>  #define XE_PAGE_PRESENT			BIT_ULL(0)
>  #define XE_PAGE_RW			BIT_ULL(1)
> -
>  #endif
> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index 2d9ce2c4cb4f..cc8dcdb6649a 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -755,6 +755,17 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
>  			XE_USM_PPGTT_PTE_AE : 0;
>  	}
>  
> +	if (!xe_vma_supports_access_ctr(xe, vma, tile)) {
> +		xe_walk.default_vram_pte |= XE_PPGTT_PTE_NC;
> +		xe_walk.default_system_pte |= XE_PPGTT_PTE_NC;
> +	}
> +
> +	if (range) {
> +		xe_walk.default_vram_pte |= XE_PPGTT_PTE_NC;
> +		if (!range->base.pages.flags.migrate_devmem)


This isn’t quite right for multi-GPU. We don’t have a madvise policy for
access counters yet—but we likely should define these semantics as part
of this series. My thinking is that if madvise sets a specific GPU as
the preferred location, other GPUs should clear the NC bit so they don’t
generate access-counter events, since the user has explicitly indicated
where the memory should live. In other words, we need a way to say “this
memory has a preferred location—disable access counters accordingly.”
pages.flags.migrate_devmem is not that. I think this point is fairly
straightforward to agree on.

Now, what should the policy be if no preferred location is set? I’d
suggest defaulting to first-touch placement, then migrating once an
access counter becomes hot.

Looking further ahead, we could implement a policy like “don’t migrate
on first device,” e.g., leave pages in system memory initially, and only
migrate them once access counters on a device become hot. NVIDIA does
something similar. This would likely be handled in a follow-on series
with new uAPI, but I think we should all agree on the first two points
above before going there.

Whatever we agree upon for SVM access counters polices, let's also be
sure update any relavent kernel doc.

Also, in general, let’s avoid touching GPUSVM internals in Xe. If we do
need to, we should at minimum add an xe_svm.h helper layer that we can
eventually move into GPUSVM.

Lastly, default_vram_pte is correct for now. However, once we land UAL,
default_vram_pte will also be used for ranges located on a remote
device. It might make sense to add a helper for setting
xe_walk.default_vram_pte that blindly sets XE_PPGTT_PTE_NC, with a
comment explaining the UAL use case so we don’t forget to update this
later.

Matt

> +			xe_walk.default_system_pte |= XE_PPGTT_PTE_NC;
> +	}
> +
>  	xe_walk.default_vram_pte |= XE_PPGTT_PTE_DM;
>  	xe_walk.dma_offset = bo ? vram_region_gpu_offset(bo->ttm.resource) : 0;
>  	if (!range)
> -- 
> 2.34.1
>