From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Tejas Upadhyay <tejas.upadhyay@intel.com>,
intel-xe@lists.freedesktop.org
Cc: Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 1/3] drm/xe/xe3p_lpg: flush userptr/shrinker bo cachelines manually
Date: Tue, 25 Nov 2025 16:06:40 +0100 [thread overview]
Message-ID: <e3b54213adab24d5620241ec9e701ced2c1f4f85.camel@linux.intel.com> (raw)
In-Reply-To: <20251125094335.12028-2-tejas.upadhyay@intel.com>
Hi.
On Tue, 2025-11-25 at 15:13 +0530, Tejas Upadhyay wrote:
> Starting NVL, HW will flush cachelines marked with XA only
> when media is off. We have few cases where kernel will have
> non-XA cachelines which needs manual flush as we postpone
> the invalidation. Flush asap from correctness POV to ensure
> non accelerated CPU copy to swap/shmem file will see coherent
> view of memory, but also from security POV where later flush
> can't corrupt the next user of those pages.
>
> Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
I had a number of concerns last time this patch was sent to the list,
none of which seems to have been addressed?
https://lore.kernel.org/intel-xe/d2517d66f571e11a760cb143981b7ca238f5cd58.camel@linux.intel.com/
The main concern is that the code indicates that not all GPU caches are
flushed when all fences are signalled (bo / userptr idle)?
Thanks,
Thomas
> ---
> drivers/gpu/drm/xe/xe_bo.c | 3 ++-
> drivers/gpu/drm/xe/xe_device.c | 20 ++++++++++++++++++++
> drivers/gpu/drm/xe/xe_device.h | 1 +
> drivers/gpu/drm/xe/xe_userptr.c | 3 ++-
> 4 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 465cf9fc7ce9..97e1e9d40e96 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -689,7 +689,8 @@ static int xe_bo_trigger_rebind(struct xe_device
> *xe, struct xe_bo *bo,
>
> if (!xe_vm_in_fault_mode(vm)) {
> drm_gpuvm_bo_evict(vm_bo, true);
> - continue;
> + if (!xe_device_needs_cache_flush(xe))
> + continue;
> }
>
> if (!idle) {
> diff --git a/drivers/gpu/drm/xe/xe_device.c
> b/drivers/gpu/drm/xe/xe_device.c
> index 92f883dd8877..6e8335b493e8 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c
> @@ -1079,6 +1079,26 @@ void xe_device_l2_flush(struct xe_device *xe)
> spin_unlock(>->global_invl_lock);
> }
>
> +/**
> + * xe_device_needs_cache_flush - Whether the cache needs to be
> flushed
> + * @xe: The device to check.
> + *
> + * Return: true if the device needs cache flush, false otherwise.
> + */
> +bool xe_device_needs_cache_flush(struct xe_device *xe)
> +{
> + /*
> + * Starting NVL, HW will flush cachelines marked with XA
> only when media is off. We have
> + * few cases where kernel will have non-XA cachelines which
> needs manual flush and this is
> + * one of them as we postpone the invalidation. Flush asap
> from correctness POV to ensure
> + * non accelerated CPU copy to swap/shmem file will see
> coherent view of memory, but also
> + * from security POV where later flush can't corrupt the
> next user of those pages.
> + */
> + if (GRAPHICS_VER(xe) >= 35 && !IS_DGFX(xe))
> + return true;
> + return false;
> +}
> +
> /**
> * xe_device_td_flush() - Flush transient L3 cache entries
> * @xe: The device
> diff --git a/drivers/gpu/drm/xe/xe_device.h
> b/drivers/gpu/drm/xe/xe_device.h
> index 32cc6323b7f6..15e67db44b56 100644
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -179,6 +179,7 @@ void xe_device_snapshot_print(struct xe_device
> *xe, struct drm_printer *p);
> u64 xe_device_canonicalize_addr(struct xe_device *xe, u64 address);
> u64 xe_device_uncanonicalize_addr(struct xe_device *xe, u64
> address);
>
> +bool xe_device_needs_cache_flush(struct xe_device *xe);
> void xe_device_td_flush(struct xe_device *xe);
> void xe_device_l2_flush(struct xe_device *xe);
>
> diff --git a/drivers/gpu/drm/xe/xe_userptr.c
> b/drivers/gpu/drm/xe/xe_userptr.c
> index 0d9130b1958a..a93c7e887cca 100644
> --- a/drivers/gpu/drm/xe/xe_userptr.c
> +++ b/drivers/gpu/drm/xe/xe_userptr.c
> @@ -114,7 +114,8 @@ static void __vma_userptr_invalidate(struct xe_vm
> *vm, struct xe_userptr_vma *uv
> false, MAX_SCHEDULE_TIMEOUT);
> XE_WARN_ON(err <= 0);
>
> - if (xe_vm_in_fault_mode(vm) && userptr->initial_bind) {
> + if ((xe_vm_in_fault_mode(vm) ||
> xe_device_needs_cache_flush(vm->xe)) &&
> + userptr->initial_bind) {
> err = xe_vm_invalidate_vma(vma);
> XE_WARN_ON(err);
> }
next prev parent reply other threads:[~2025-11-25 15:06 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 9:43 [PATCH 0/3] drm/xe/xe3p_lpg: L2 flush optimization Tejas Upadhyay
2025-11-25 9:43 ` [PATCH 1/3] drm/xe/xe3p_lpg: flush userptr/shrinker bo cachelines manually Tejas Upadhyay
2025-11-25 10:17 ` Matthew Auld
2025-11-25 13:39 ` Souza, Jose
2025-11-25 15:06 ` Thomas Hellström [this message]
2025-11-25 15:31 ` Upadhyay, Tejas
2025-11-26 10:26 ` Thomas Hellström
2025-11-25 9:43 ` [PATCH 2/3] drm/xe/xe3p_lpg: Enable L2 flush optimization feature Tejas Upadhyay
2025-11-25 9:43 ` [PATCH 3/3] drm/xe/xe3p: Skip TD flush Tejas Upadhyay
2025-11-25 13:20 ` ✓ CI.KUnit: success for drm/xe/xe3p_lpg: L2 flush optimization Patchwork
2025-11-25 14:47 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-25 17:42 ` ✓ Xe.CI.Full: " Patchwork
-- strict thread matches above, loose matches on Subject: below --
2026-02-10 12:51 [PATCH 0/3] " Tejas Upadhyay
2026-02-10 12:51 ` [PATCH 1/3] drm/xe/xe3p_lpg: flush userptr/shrinker bo cachelines manually Tejas Upadhyay
2026-02-10 21:05 ` Matt Roper
2026-02-11 0:02 ` Matthew Brost
2026-02-11 19:06 ` Upadhyay, Tejas
2026-02-11 21:11 ` Matt Roper
2026-02-12 9:53 ` Matthew Auld
2026-02-13 11:17 ` Upadhyay, Tejas
2026-02-13 13:27 ` Matthew Auld
2026-02-13 13:30 ` Souza, Jose
2026-02-13 16:23 ` Upadhyay, Tejas
2026-02-13 16:48 ` Souza, Jose
2026-02-13 17:16 ` Matt Roper
2026-02-13 17:31 ` Souza, Jose
2026-02-13 17:31 ` Matthew Auld
2026-02-16 10:23 ` Thomas Hellström
2026-02-16 10:58 ` Matthew Auld
2026-02-16 12:07 ` Thomas Hellström
2026-02-16 14:55 ` Matthew Auld
2026-02-16 15:38 ` Thomas Hellström
2026-02-16 16:41 ` Matthew Auld
2026-02-17 6:19 ` Upadhyay, Tejas
2026-02-17 9:53 ` Thomas Hellström
2026-02-17 17:04 ` Thomas Hellström
2026-02-17 18:41 ` Matthew Auld
2026-02-16 10:56 ` Thomas Hellström
2026-02-16 11:26 ` Upadhyay, Tejas
2026-02-13 17:29 ` Matthew Auld
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=e3b54213adab24d5620241ec9e701ced2c1f4f85.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=tejas.upadhyay@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.