From: Matthew Brost <matthew.brost@intel.com>
To: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH v4 08/20] drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zapping
Date: Sun, 22 Jun 2025 21:56:35 -0700 [thread overview]
Message-ID: <aFjegyCdeNlytbH/@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20250613125558.2607665-9-himal.prasad.ghimiray@intel.com>
On Fri, Jun 13, 2025 at 06:25:46PM +0530, Himal Prasad Ghimiray wrote:
> Introduce xe_svm_ranges_zap_ptes_in_range(), a function to zap page table
> entries (PTEs) for all SVM ranges within a user-specified address range.
>
> -v2 (Matthew Brost)
> Lock should be called even for tlb_invalidation
>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> ---
> drivers/gpu/drm/xe/xe_pt.c | 14 ++++++++++++-
> drivers/gpu/drm/xe/xe_svm.c | 42 +++++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_svm.h | 7 +++++++
> 3 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> index 9177c571689e..9a390ef10852 100644
> --- a/drivers/gpu/drm/xe/xe_pt.c
> +++ b/drivers/gpu/drm/xe/xe_pt.c
> @@ -950,7 +950,19 @@ bool xe_pt_zap_ptes_range(struct xe_tile *tile, struct xe_vm *vm,
> struct xe_pt *pt = vm->pt_root[tile->id];
> u8 pt_mask = (range->tile_present & ~range->tile_invalidated);
>
> - xe_svm_assert_in_notifier(vm);
> + /*
> + * Locking rules:
> + *
> + * - notifier_lock (write): full protection against page table changes
> + * and MMU notifier invalidations.
> + *
> + * - notifier_lock (read) + vm_lock (write): combined protection against
> + * invalidations and concurrent page table modifications. (e.g., madvise)
> + *
> + */
> + lockdep_assert(lockdep_is_held_type(&vm->svm.gpusvm.notifier_lock, 0) ||
> + (lockdep_is_held_type(&vm->svm.gpusvm.notifier_lock, 1) &&
> + lockdep_is_held_type(&vm->lock, 0)));
>
> if (!(pt_mask & BIT(tile->id)))
> return false;
> diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c
> index 2fbbd6a604ea..19420635f1fa 100644
> --- a/drivers/gpu/drm/xe/xe_svm.c
> +++ b/drivers/gpu/drm/xe/xe_svm.c
> @@ -999,6 +999,48 @@ int xe_svm_range_get_pages(struct xe_vm *vm, struct xe_svm_range *range,
> return err;
> }
>
> +/**
> + * xe_svm_ranges_zap_ptes_in_range - clear ptes of svm ranges in input range
> + * @vm: Pointer to the xe_vm structure
> + * @start: Start of the input range
> + * @end: End of the input range
> + *
> + * This function removes the page table entries (PTEs) associated
> + * with the svm ranges within the given input start and end
> + *
> + * Return: tile_mask for which gt's need to be tlb invalidated.
> + */
> +u8 xe_svm_ranges_zap_ptes_in_range(struct xe_vm *vm, u64 start, u64 end)
> +{
> + struct drm_gpusvm_notifier *notifier;
> + struct xe_svm_range *range;
> + u64 adj_start, adj_end;
> + struct xe_tile *tile;
> + u8 tile_mask = 0;
> + u8 id;
> +
> + lockdep_assert(lockdep_is_held_type(&vm->svm.gpusvm.notifier_lock, 1) &&
> + lockdep_is_held_type(&vm->lock, 0));
> +
> + drm_gpusvm_for_each_notifier(notifier, &vm->svm.gpusvm, start, end) {
> + struct drm_gpusvm_range *r = NULL;
> +
> + adj_start = max(start, notifier->itree.start);
s/notifier->itree.start/drm_gpusvm_notifier_start
> + adj_end = min(end, notifier->itree.last + 1);
s/notifier->itree.last + 1/drm_gpusvm_notifier_end
> + drm_gpusvm_for_each_range(r, notifier, adj_start, adj_end) {
> + range = to_xe_range(r);
> + for_each_tile(tile, vm->xe, id) {
> + if (xe_pt_zap_ptes_range(tile, vm, range)) {
> + tile_mask |= BIT(id);
> + range->tile_invalidated |= BIT(id);
/* WRITE_ONCE pairs with READ_ONCE in xe_vm_has_valid_gpu_mapping() */
WRITE_ONCE(range->tile_invalidated, range->tile_invalidated | BIT(id));
Also, we need to be careful here. If we can fail after this point but
before the TLB invalidation completes, we could break the notifier, as
the notifier would skip the TLB invalidation. The code, as written, can
only fail if the CT channel is down — in that case, all bets are off and
we are issuing a GT reset. So, I think the code as written is okay, but
I’d add a comment here indicating that there must be no failure points
between setting tile_invalidated and issuing the TLB invalidation.
Matt
> + }
> + }
> + }
> + }
> +
> + return tile_mask;
> +}
> +
> #if IS_ENABLED(CONFIG_DRM_XE_DEVMEM_MIRROR)
>
> static struct drm_pagemap_device_addr
> diff --git a/drivers/gpu/drm/xe/xe_svm.h b/drivers/gpu/drm/xe/xe_svm.h
> index 19ce4f2754a7..af8f285b6caa 100644
> --- a/drivers/gpu/drm/xe/xe_svm.h
> +++ b/drivers/gpu/drm/xe/xe_svm.h
> @@ -91,6 +91,7 @@ bool xe_svm_range_validate(struct xe_vm *vm,
>
> u64 xe_svm_find_vma_start(struct xe_vm *vm, u64 addr, u64 end, struct xe_vma *vma);
>
> +u8 xe_svm_ranges_zap_ptes_in_range(struct xe_vm *vm, u64 start, u64 end);
> /**
> * xe_svm_range_has_dma_mapping() - SVM range has DMA mapping
> * @range: SVM range
> @@ -305,6 +306,12 @@ u64 xe_svm_find_vma_start(struct xe_vm *vm, u64 addr, u64 end, struct xe_vma *vm
> return ULONG_MAX;
> }
>
> +static inline
> +u8 xe_svm_ranges_zap_ptes_in_range(struct xe_vm *vm, u64 start, u64 end)
> +{
> + return 0;
> +}
> +
> #define xe_svm_assert_in_notifier(...) do {} while (0)
> #define xe_svm_range_has_dma_mapping(...) false
>
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-06-23 4:55 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 12:55 [PATCH v4 00/20] MADVISE FOR XE Himal Prasad Ghimiray
2025-06-13 12:43 ` ✗ CI.checkpatch: warning for MADVISE FOR XE (rev2) Patchwork
2025-06-13 12:44 ` ✗ CI.KUnit: failure " Patchwork
2025-06-13 12:55 ` [PATCH v4 01/20] Introduce drm_gpuvm_sm_map_ops_flags enums for sm_map_ops Himal Prasad Ghimiray
2025-06-13 12:55 ` [PATCH v4 02/20] drm/xe/uapi: Add madvise interface Himal Prasad Ghimiray
2025-06-13 14:15 ` Souza, Jose
2025-06-23 4:30 ` Matthew Brost
2025-06-23 6:20 ` Ghimiray, Himal Prasad
2025-06-27 13:47 ` Thomas Hellström
2025-06-27 14:29 ` Thomas Hellström
2025-06-27 18:13 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 03/20] drm/xe/vm: Add attributes struct as member of vma Himal Prasad Ghimiray
2025-06-23 4:18 ` Matthew Brost
2025-06-23 6:21 ` Ghimiray, Himal Prasad
2025-06-27 14:32 ` Thomas Hellström
2025-06-13 12:55 ` [PATCH v4 04/20] drm/xe/vma: Move pat_index to vma attributes Himal Prasad Ghimiray
2025-06-13 12:55 ` [PATCH v4 05/20] drm/xe/vma: Modify new_vma to accept struct xe_vma_mem_attr as parameter Himal Prasad Ghimiray
2025-06-23 4:38 ` Matthew Brost
2025-06-23 16:21 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 06/20] drm/gpusvm: Make drm_gpusvm_for_each_* macros public Himal Prasad Ghimiray
2025-06-13 12:55 ` [PATCH v4 07/20] drm/xe/svm: Split system allocator vma incase of madvise call Himal Prasad Ghimiray
2025-06-13 12:55 ` [PATCH v4 08/20] drm/xe/svm: Add xe_svm_ranges_zap_ptes_in_range() for PTE zapping Himal Prasad Ghimiray
2025-06-23 4:56 ` Matthew Brost [this message]
2025-06-23 6:25 ` Ghimiray, Himal Prasad
2025-06-13 12:55 ` [PATCH v4 09/20] drm/xe: Implement madvise ioctl for xe Himal Prasad Ghimiray
2025-06-23 5:33 ` Matthew Brost
2025-06-26 6:04 ` Lin, Shuicheng
2025-06-26 6:15 ` Matthew Brost
2025-06-26 8:36 ` Ghimiray, Himal Prasad
2025-06-26 8:34 ` Ghimiray, Himal Prasad
2025-06-13 12:55 ` [PATCH v4 10/20] drm/xe/vm: Add an identifier for madvise in xe_vma_ops Himal Prasad Ghimiray
2025-06-23 5:38 ` Matthew Brost
2025-06-23 6:28 ` Ghimiray, Himal Prasad
2025-06-13 12:55 ` [PATCH v4 11/20] drm/xe: Allow CPU address mirror VMA unbind with gpu bindings for madvise Himal Prasad Ghimiray
2025-06-14 4:31 ` kernel test robot
2025-06-23 5:52 ` Matthew Brost
2025-06-23 6:18 ` Ghimiray, Himal Prasad
2025-06-23 11:45 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 12/20] drm/xe/svm : Add svm ranges migration policy on atomic access Himal Prasad Ghimiray
2025-06-23 16:32 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 13/20] drm/xe/madvise: Update migration policy based on preferred location Himal Prasad Ghimiray
2025-06-13 23:31 ` kernel test robot
2025-06-14 5:33 ` kernel test robot
2025-06-13 12:55 ` [PATCH v4 14/20] drm/xe/svm: Support DRM_XE_SVM_ATTR_PAT memory attribute Himal Prasad Ghimiray
2025-06-23 16:34 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 15/20] drm/xe/uapi: Add flag for consulting madvise hints on svm prefetch Himal Prasad Ghimiray
2025-06-23 16:36 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 16/20] drm/xe/svm: Consult madvise preferred location in prefetch Himal Prasad Ghimiray
2025-06-23 22:07 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 17/20] drm/xe/bo: Add attributes field to xe_bo Himal Prasad Ghimiray
2025-06-13 12:55 ` [PATCH v4 18/20] drm/xe/bo: Update atomic_access attribute on madvise Himal Prasad Ghimiray
2025-06-23 16:19 ` Matthew Brost
2025-06-13 12:55 ` [PATCH v4 19/20] drm/xe/uapi: Add UAPI for querying VMA count and memory attributes Himal Prasad Ghimiray
2025-06-23 22:43 ` Matthew Brost
2025-06-24 2:18 ` Matthew Brost
2025-06-27 13:20 ` Thomas Hellström
2025-06-27 13:43 ` Thomas Hellström
2025-06-26 3:44 ` Lin, Shuicheng
2025-06-13 12:55 ` [PATCH v4 20/20] drm/xe/madvise: Skip vma invalidation if mem attr are unchanged Himal Prasad Ghimiray
2025-06-23 22:28 ` Matthew Brost
2025-06-26 8:54 ` Ghimiray, Himal Prasad
2025-06-16 4:30 ` ✗ CI.checkpatch: warning for MADVISE FOR XE (rev3) Patchwork
2025-06-16 4:31 ` ✓ CI.KUnit: success " Patchwork
2025-06-16 4:45 ` ✗ CI.checksparse: warning " Patchwork
2025-06-16 5:13 ` ✓ Xe.CI.BAT: success " Patchwork
2025-06-16 15:06 ` ✗ Xe.CI.Full: failure " Patchwork
2025-07-29 4:41 ` [PATCH v4 00/20] MADVISE FOR XE Matthew Brost
2025-07-30 11:16 ` Ghimiray, Himal Prasad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFjegyCdeNlytbH/@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox