From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v6 07/24] drm/xe: Update scheduler job layer to support PT jobs
Date: Fri, 04 Sep 2026 21:37:00 +0000 [thread overview]
Message-ID: <20260904213700.8D5B31F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260904211613.3934307-8-matthew.brost@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] PT jobs consume the TLB flush seqno without executing a hardware TLB flush, potentially causing subsequent GPU jobs to run with stale page tables.
--
commit 3d489d315c4f278dad409a11a04984a2139095c2
Author: Matthew Brost <matthew.brost@intel.com>
drm/xe: Update scheduler job layer to support PT jobs
Update the scheduler job layer to support PT jobs which execute entirely
on the CPU without requiring LRC fences or a batch address. Repurpose
LRC fence storage for PT-job arguments.
Link: https://patch.msgid.link/20260228013501.106680-8-matthew.brost@intel.com
> diff --git a/drivers/gpu/drm/xe/xe_sched_job.c b/drivers/gpu/drm/xe/xe_sched_job.c
> --- a/drivers/gpu/drm/xe/xe_sched_job.c
> +++ b/drivers/gpu/drm/xe/xe_sched_job.c
[ ... ]
> @@ -266,6 +293,9 @@ void xe_sched_job_arm(struct xe_sched_job *job)
> job->ring_ops_flush_tlb = true;
> }
>
> + if (job->is_pt_job)
> + goto arm;
> +
> /* Arm the pre-allocated fences */
> for (i = 0; i < q->width; prev = fence, ++i) {
[Severity: Critical]
Will this cause subsequent GPU jobs to run with stale page tables?
Looking at xe_sched_job_arm() in drivers/gpu/drm/xe/xe_sched_job.c, the code
just above this addition checks if a TLB flush is needed and updates
q->tlb_flush_seqno:
if (vm && !xe_sched_job_is_migration(q) && !xe_vm_in_lr_mode(vm) &&
(vm->batch_invalidate_tlb || vm->tlb_flush_seqno != q->tlb_flush_seqno)) {
xe_vm_assert_held(vm);
q->tlb_flush_seqno = vm->tlb_flush_seqno;
job->ring_ops_flush_tlb = true;
}
If the current job is a PT job, the new check jumps to the arm label,
skipping the hardware ring submission where the flush would normally execute.
Because q->tlb_flush_seqno was already updated, when a subsequent GPU payload
job is submitted to this same queue, it will see the seqnos match and skip
flushing. This could allow the GPU to access memory using a stale TLB.
Should the job->is_pt_job check precede the TLB invalidation check to prevent
the CPU-only PT job from stealing the flush notification?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904211613.3934307-1-matthew.brost@intel.com?part=7
next prev parent reply other threads:[~2026-09-04 21:37 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 21:15 [PATCH v6 00/24] CPU binds and ULLS on migration queue Matthew Brost
2026-09-04 21:15 ` [PATCH v6 01/24] drm/xe: Drop struct xe_migrate_pt_update argument from populate/clear vfuns Matthew Brost
2026-09-04 21:15 ` [PATCH v6 02/24] drm/xe: Add xe_migrate_update_pgtables_cpu_execute helper Matthew Brost
2026-09-04 21:28 ` sashiko-bot
2026-09-04 21:15 ` [PATCH v6 03/24] drm/xe: Decouple exec queue idle check from LRC Matthew Brost
2026-09-04 21:15 ` [PATCH v6 04/24] drm/xe: Add job count to GuC exec queue snapshot Matthew Brost
2026-09-04 21:23 ` sashiko-bot
2026-09-04 21:15 ` [PATCH v6 05/24] drm/xe: Update xe_bo_put_deferred arguments to include writeback flag Matthew Brost
2026-09-04 21:15 ` [PATCH v6 06/24] drm/xe: Add XE_BO_FLAG_PUT_VM_ASYNC Matthew Brost
2026-09-04 21:33 ` sashiko-bot
2026-09-11 13:10 ` Francois Dugast
2026-09-11 19:54 ` Matthew Brost
2026-09-12 0:27 ` Matthew Brost
2026-09-04 21:15 ` [PATCH v6 07/24] drm/xe: Update scheduler job layer to support PT jobs Matthew Brost
2026-09-04 21:37 ` sashiko-bot [this message]
2026-09-11 15:24 ` Francois Dugast
2026-09-11 19:25 ` Matthew Brost
2026-09-04 21:15 ` [PATCH v6 08/24] drm/xe: Add helpers to access PT ops Matthew Brost
2026-09-04 21:15 ` [PATCH v6 09/24] drm/xe: Add struct xe_pt_job_ops Matthew Brost
2026-09-04 21:40 ` sashiko-bot
2026-09-04 21:15 ` [PATCH v6 10/24] drm/xe: Update GuC submission backend to run PT jobs Matthew Brost
2026-09-04 21:39 ` sashiko-bot
2026-09-04 21:16 ` [PATCH v6 11/24] drm/xe: Store level in struct xe_vm_pgtable_update Matthew Brost
2026-09-04 21:16 ` [PATCH v6 12/24] drm/xe: Don't use migrate exec queue for page fault binds Matthew Brost
2026-09-04 21:16 ` [PATCH v6 13/24] drm/xe: Enable CPU binds for jobs Matthew Brost
2026-09-04 21:44 ` sashiko-bot
2026-09-04 21:16 ` [PATCH v6 14/24] drm/xe: Remove unused arguments from xe_migrate_pt_update_ops Matthew Brost
2026-09-04 21:16 ` [PATCH v6 15/24] drm/xe: Make bind queues operate cross-tile Matthew Brost
2026-09-04 21:16 ` [PATCH v6 16/24] drm/xe: Add CPU bind layer Matthew Brost
2026-09-04 21:50 ` sashiko-bot
2026-09-04 21:16 ` [PATCH v6 17/24] drm/xe: Add device flag to enable PT mirroring across tiles Matthew Brost
2026-09-04 21:40 ` sashiko-bot
2026-09-04 21:16 ` [PATCH v6 18/24] drm/xe: Add ULLS support to LRC Matthew Brost
2026-09-04 21:16 ` [PATCH v6 19/24] drm/xe: Add ULLS migration job support to migration layer Matthew Brost
2026-09-04 21:40 ` sashiko-bot
2026-09-04 21:16 ` [PATCH v6 20/24] drm/xe: Add ULLS migration job support to ring ops Matthew Brost
2026-09-04 21:16 ` [PATCH v6 21/24] drm/xe: Add ULLS migration job support to GuC submission Matthew Brost
2026-09-04 21:16 ` [PATCH v6 22/24] drm/xe: Enter ULLS for migration jobs upon page fault or SVM prefetch Matthew Brost
2026-09-04 21:16 ` [PATCH v6 23/24] drm/xe: Add modparam to enable / disable ULLS on migrate queue Matthew Brost
2026-09-09 8:03 ` Thomas Hellström
2026-09-09 18:11 ` Matthew Brost
2026-09-04 21:16 ` [PATCH v6 24/24] drm/xe: Document ULLS for migration jobs Matthew Brost
2026-09-09 9:01 ` Thomas Hellström
2026-09-09 17:53 ` Matthew Brost
2026-09-04 21:24 ` ✗ CI.checkpatch: warning for CPU binds and ULLS on migration queue (rev8) Patchwork
2026-09-04 21:26 ` ✓ CI.KUnit: success " Patchwork
2026-09-04 22:16 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-05 3:34 ` ✗ Xe.CI.FULL: failure " Patchwork
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=20260904213700.8D5B31F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.