From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Upadhyay, Tejas" <tejas.upadhyay@intel.com>,
"intel-xe@lists.freedesktop.org"
<intel-xe@lists.freedesktop.org>,
"Auld, Matthew" <matthew.auld@intel.com>
Subject: Re: [PATCH 1/3] drm/xe/xe3p_lpg: flush userptr/shrinker bo cachelines manually
Date: Wed, 26 Nov 2025 11:26:12 +0100 [thread overview]
Message-ID: <9019924acd3218bf679a2f96fcc05c9e5c8a704c.camel@linux.intel.com> (raw)
In-Reply-To: <DS7PR11MB6197137365666F3474A80D0881D1A@DS7PR11MB6197.namprd11.prod.outlook.com>
On Tue, 2025-11-25 at 15:31 +0000, Upadhyay, Tejas wrote:
>
>
> > -----Original Message-----
> > From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> > Sent: 25 November 2025 20:37
> > To: Upadhyay, Tejas <tejas.upadhyay@intel.com>; intel-
> > xe@lists.freedesktop.org
> > Cc: Auld, Matthew <matthew.auld@intel.com>
> > Subject: Re: [PATCH 1/3] drm/xe/xe3p_lpg: flush userptr/shrinker bo
> > cachelines manually
> >
> > 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?
>
> Sorry for missing to address your comments.
>
> >
> > 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)?
>
> Xe3p is introducing feature that when media is off, only XA marked BO
> will be flushed not whole cache. From UMD perspective we might have
> non-XA buffers created which we would like to flush before
> buffer/user goes away during media off.
So for non-XA buffers, how would coherency be maintained for
gpu_write() -> cpu_read() from UMD's perspective? For dma-buf?
Also flushing in move_notify() can't be done unless the bo is idle
first, and that would force us to unnecessarily synchronize.
/Thomas
>
> Tejas
>
> >
> > 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-26 10:26 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
2025-11-25 15:31 ` Upadhyay, Tejas
2025-11-26 10:26 ` Thomas Hellström [this message]
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=9019924acd3218bf679a2f96fcc05c9e5c8a704c.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.