All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "Brost, Matthew" <matthew.brost@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>,
	"Yadav, Arvind" <arvind.yadav@intel.com>,
	"thomas.hellstrom@linux.intel.com"
	<thomas.hellstrom@linux.intel.com>,
	"Dugast, Francois" <francois.dugast@intel.com>
Subject: Re: [PATCH v3 10/25] drm/xe: Update GuC submission backend to run PT jobs
Date: Wed, 4 Mar 2026 20:43:27 +0000	[thread overview]
Message-ID: <934deb296f18f9147db2478f5d645249e3a6013e.camel@intel.com> (raw)
In-Reply-To: <aad8OjQWtbuk5FqN@lstrano-desk.jf.intel.com>

On Tue, 2026-03-03 at 16:26 -0800, Matthew Brost wrote:
> On Tue, Mar 03, 2026 at 04:28:50PM -0700, Summers, Stuart wrote:
> > On Fri, 2026-02-27 at 17:34 -0800, Matthew Brost wrote:
> > > PT jobs bypass GPU execution for the final step of a bind job,
> > > using
> > > the
> > > CPU to program the required page tables. Teach the GuC submission
> > > backend
> > > how to execute these jobs.
> > > 
> > > PT job submission is implemented in the GuC backend for
> > > simplicity. A
> > > follow-up patch could introduce a dedicated backend for PT jobs.
> > 
> > Still looking through the whole series, but standing alone, this
> > patch
> > doesn't feel right to me. I don't see why we'd want to hook
> > together
> > the PT update flow with the GuC backend...
> > 
> 
> I don't think it is either, which is why I called out a follow-up to
> implement the PT backend. It’s likely a bigger refactor than one
> would
> expect, though...
> 
> - Build the backend on top of xe_dep_scheduler
> - Introduce xe_pt_job that inherits from xe_dep_job
> - Ripple these changes through CPU bind, the PT layer, etc.
> 
> A lot of that is just shuffling code around across those three steps,
> but it’s not too bad and will likely give us some nice layering
> cleanups
> along the way.
> 
> The real tricky part is handling all the flows that stop/start the
> backends while various global events occur (e.g., PM enter/exit, GT
> resets, VF migration, FLR (WIP), etc.). All of those flows are
> currently
> GT → UC → GuC layered (or, for VF migration, direct to GuC). So we’d
> need a refactor there as well. It’s doable, but it will end up
> touching
> quite a few files. Again, once we do this, I suspect we’ll get
> additional layering cleanups along the way.
> 
> So for now, given the already large size of the series, I’d like to
> get
> the functionality in first and then tackle the layering refactors.

I get what you're saying here. Other than complexity, is there a reason
we can't do that work first though? Is there some critical reason we
need to get the CPU binding work in first, basically?

-Stuart

> 
> Matt
> 
> > Thanks,
> > Stuart
> > 
> > > 
> > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > ---
> > >  drivers/gpu/drm/xe/xe_guc_submit.c | 37
> > > ++++++++++++++++++++++++++--
> > > --
> > >  drivers/gpu/drm/xe/xe_migrate.c    | 13 ++++++++++-
> > >  drivers/gpu/drm/xe/xe_migrate.h    |  8 +++++++
> > >  3 files changed, 52 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > index 453af51fe87b..1d6ac7a6563b 100644
> > > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > > @@ -36,8 +36,10 @@
> > >  #include "xe_lrc.h"
> > >  #include "xe_macros.h"
> > >  #include "xe_map.h"
> > > +#include "xe_migrate.h"
> > >  #include "xe_mocs.h"
> > >  #include "xe_pm.h"
> > > +#include "xe_pt.h"
> > >  #include "xe_ring_ops_types.h"
> > >  #include "xe_sched_job.h"
> > >  #include "xe_sleep.h"
> > > @@ -1183,6 +1185,20 @@ static void submit_exec_queue(struct
> > > xe_exec_queue *q, struct xe_sched_job *job)
> > >         }
> > >  }
> > >  
> > > +static bool is_pt_job(struct xe_sched_job *job)
> > > +{
> > > +       return job->is_pt_job;
> > > +}
> > > +
> > > +static void run_pt_job(struct xe_sched_job *job)
> > > +{
> > > +       xe_migrate_update_pgtables_cpu_execute(job-
> > > >pt_update[0].vm,
> > > +                                              job-
> > > > pt_update[0].tile,
> > > +                                              job-
> > > >pt_update[0].ops,
> > > +                                              job-
> > > > pt_update[0].pt_job_ops->ops,
> > > +                                              job-
> > > > pt_update[0].pt_job_ops->current_op);
> > > +}
> > > +
> > >  static struct dma_fence *
> > >  guc_exec_queue_run_job(struct drm_sched_job *drm_job)
> > >  {
> > > @@ -1210,14 +1226,25 @@ guc_exec_queue_run_job(struct
> > > drm_sched_job
> > > *drm_job)
> > >                                 register_exec_queue(primary,
> > > GUC_CONTEXT_NORMAL);
> > >                 }
> > >  
> > > -               if (!exec_queue_registered(q))
> > > -                       register_exec_queue(q,
> > > GUC_CONTEXT_NORMAL);
> > > -               if (!job->restore_replay)
> > > -                       q->ring_ops->emit_job(job);
> > > -               submit_exec_queue(q, job);
> > > +               if (is_pt_job(job)) {
> > > +                       xe_gt_assert(guc_to_gt(guc),
> > > !exec_queue_registered(q));
> > > +                       run_pt_job(job);
> > > +               } else {
> > > +                       if (!exec_queue_registered(q))
> > > +                               register_exec_queue(q,
> > > GUC_CONTEXT_NORMAL);
> > > +                       if (!job->restore_replay)
> > > +                               q->ring_ops->emit_job(job);
> > > +                       submit_exec_queue(q, job);
> > > +               }
> > >                 job->restore_replay = false;
> > >         }
> > >  
> > > +       if (is_pt_job(job)) {
> > > +               xe_pt_job_ops_put(job->pt_update[0].pt_job_ops);
> > > +               dma_fence_put(job->fence);      /* Drop ref from
> > > xe_sched_job_arm */
> > > +               return NULL;
> > > +       }
> > > +
> > >  run_job_out:
> > >  
> > >         return job->fence;
> > > diff --git a/drivers/gpu/drm/xe/xe_migrate.c
> > > b/drivers/gpu/drm/xe/xe_migrate.c
> > > index cd6802642ef3..e9b9dfe19e48 100644
> > > --- a/drivers/gpu/drm/xe/xe_migrate.c
> > > +++ b/drivers/gpu/drm/xe/xe_migrate.c
> > > @@ -1715,7 +1715,18 @@ struct migrate_test_params {
> > >         container_of(_priv, struct migrate_test_params, base)
> > >  #endif
> > >  
> > > -static void
> > > +/**
> > > + * xe_migrate_update_pgtables_cpu_execute() - Update a VM's PTEs
> > > via
> > > the CPU
> > > + * @vm: The VM being updated
> > > + * @tile: The tile being updated
> > > + * @ops: The migrate PT update ops
> > > + * @pt_ops: The VM PT update ops
> > > + * @num_ops: The number of The VM PT update ops
> > > + *
> > > + * Execute the VM PT update ops array which results in a VM's
> > > PTEs
> > > being updated
> > > + * via the CPU.
> > > + */
> > > +void
> > >  xe_migrate_update_pgtables_cpu_execute(struct xe_vm *vm, struct
> > > xe_tile *tile,
> > >                                        const struct
> > > xe_migrate_pt_update_ops *ops,
> > >                                        struct
> > > xe_vm_pgtable_update_op
> > > *pt_op,
> > > diff --git a/drivers/gpu/drm/xe/xe_migrate.h
> > > b/drivers/gpu/drm/xe/xe_migrate.h
> > > index c3c0740f908d..30c9c990a8b1 100644
> > > --- a/drivers/gpu/drm/xe/xe_migrate.h
> > > +++ b/drivers/gpu/drm/xe/xe_migrate.h
> > > @@ -24,6 +24,7 @@ struct xe_pt;
> > >  struct xe_tile;
> > >  struct xe_vm;
> > >  struct xe_vm_pgtable_update;
> > > +struct xe_vm_pgtable_update_op;
> > >  struct xe_vma;
> > >  
> > >  enum xe_sriov_vf_ccs_rw_ctxs;
> > > @@ -157,6 +158,13 @@ struct dma_fence *xe_migrate_clear(struct
> > > xe_migrate *m,
> > >  
> > >  struct xe_vm *xe_migrate_get_vm(struct xe_migrate *m);
> > >  
> > > +
> > > +void
> > > +xe_migrate_update_pgtables_cpu_execute(struct xe_vm *vm, struct
> > > xe_tile *tile,
> > > +                                      const struct
> > > xe_migrate_pt_update_ops *ops,
> > > +                                      struct
> > > xe_vm_pgtable_update_op
> > > *pt_op,
> > > +                                      int num_ops);
> > > +
> > >  struct dma_fence *
> > >  xe_migrate_update_pgtables(struct xe_migrate *m,
> > >                            struct xe_migrate_pt_update
> > > *pt_update);
> > 


  reply	other threads:[~2026-03-04 20:43 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-28  1:34 [PATCH v3 00/25] CPU binds and ULLS on migration queue Matthew Brost
2026-02-28  1:34 ` [PATCH v3 01/25] drm/xe: Drop struct xe_migrate_pt_update argument from populate/clear vfuns Matthew Brost
2026-03-05 14:17   ` Francois Dugast
2026-02-28  1:34 ` [PATCH v3 02/25] drm/xe: Add xe_migrate_update_pgtables_cpu_execute helper Matthew Brost
2026-03-05 14:39   ` Francois Dugast
2026-02-28  1:34 ` [PATCH v3 03/25] drm/xe: Decouple exec queue idle check from LRC Matthew Brost
2026-03-02 20:50   ` Summers, Stuart
2026-03-02 21:02     ` Matthew Brost
2026-03-03 21:26       ` Summers, Stuart
2026-03-03 22:42         ` Matthew Brost
2026-03-03 22:54           ` Summers, Stuart
2026-02-28  1:34 ` [PATCH v3 04/25] drm/xe: Add job count to GuC exec queue snapshot Matthew Brost
2026-03-02 20:50   ` Summers, Stuart
2026-02-28  1:34 ` [PATCH v3 05/25] drm/xe: Update xe_bo_put_deferred arguments to include writeback flag Matthew Brost
2026-04-01 12:20   ` Francois Dugast
2026-04-01 22:39     ` Matthew Brost
2026-02-28  1:34 ` [PATCH v3 06/25] drm/xe: Add XE_BO_FLAG_PUT_VM_ASYNC Matthew Brost
2026-04-01 12:22   ` Francois Dugast
2026-04-01 22:38     ` Matthew Brost
2026-02-28  1:34 ` [PATCH v3 07/25] drm/xe: Update scheduler job layer to support PT jobs Matthew Brost
2026-03-03 22:50   ` Summers, Stuart
2026-03-03 23:00     ` Matthew Brost
2026-02-28  1:34 ` [PATCH v3 08/25] drm/xe: Add helpers to access PT ops Matthew Brost
2026-04-07 15:22   ` Francois Dugast
2026-02-28  1:34 ` [PATCH v3 09/25] drm/xe: Add struct xe_pt_job_ops Matthew Brost
2026-03-03 23:26   ` Summers, Stuart
2026-03-03 23:28     ` Matthew Brost
2026-02-28  1:34 ` [PATCH v3 10/25] drm/xe: Update GuC submission backend to run PT jobs Matthew Brost
2026-03-03 23:28   ` Summers, Stuart
2026-03-04  0:26     ` Matthew Brost
2026-03-04 20:43       ` Summers, Stuart [this message]
2026-03-04 21:53         ` Matthew Brost
2026-03-05 20:24           ` Summers, Stuart
2026-02-28  1:34 ` [PATCH v3 11/25] drm/xe: Store level in struct xe_vm_pgtable_update Matthew Brost
2026-03-03 23:44   ` Summers, Stuart
2026-02-28  1:34 ` [PATCH v3 12/25] drm/xe: Don't use migrate exec queue for page fault binds Matthew Brost
2026-02-28  1:34 ` [PATCH v3 13/25] drm/xe: Enable CPU binds for jobs Matthew Brost
2026-02-28  1:34 ` [PATCH v3 14/25] drm/xe: Remove unused arguments from xe_migrate_pt_update_ops Matthew Brost
2026-02-28  1:34 ` [PATCH v3 15/25] drm/xe: Make bind queues operate cross-tile Matthew Brost
2026-02-28  1:34 ` [PATCH v3 16/25] drm/xe: Add CPU bind layer Matthew Brost
2026-02-28  1:34 ` [PATCH v3 17/25] drm/xe: Add device flag to enable PT mirroring across tiles Matthew Brost
2026-02-28  1:34 ` [PATCH v3 18/25] drm/xe: Add xe_hw_engine_write_ring_tail Matthew Brost
2026-02-28  1:34 ` [PATCH v3 19/25] drm/xe: Add ULLS support to LRC Matthew Brost
2026-03-05 20:21   ` Francois Dugast
2026-02-28  1:34 ` [PATCH v3 20/25] drm/xe: Add ULLS migration job support to migration layer Matthew Brost
2026-03-05 23:34   ` Summers, Stuart
2026-03-09 23:11     ` Matthew Brost
2026-02-28  1:34 ` [PATCH v3 21/25] drm/xe: Add MI_SEMAPHORE_WAIT instruction defs Matthew Brost
2026-02-28  1:34 ` [PATCH v3 22/25] drm/xe: Add ULLS migration job support to ring ops Matthew Brost
2026-02-28  1:34 ` [PATCH v3 23/25] drm/xe: Add ULLS migration job support to GuC submission Matthew Brost
2026-02-28  1:35 ` [PATCH v3 24/25] drm/xe: Enter ULLS for migration jobs upon page fault or SVM prefetch Matthew Brost
2026-02-28  1:35 ` [PATCH v3 25/25] drm/xe: Add modparam to enable / disable ULLS on migrate queue Matthew Brost
2026-03-05 22:59   ` Summers, Stuart
2026-04-01 22:44     ` Matthew Brost
2026-02-28  1:43 ` ✗ CI.checkpatch: warning for CPU binds and ULLS on migration queue (rev3) Patchwork
2026-02-28  1:44 ` ✓ CI.KUnit: success " Patchwork
2026-02-28  2:32 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-28 13:59 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-02 17:54   ` Summers, Stuart
2026-03-02 18:13     ` Matthew Brost
2026-03-05 22:56 ` [PATCH v3 00/25] CPU binds and ULLS on migration queue Summers, Stuart
2026-03-10 22:17   ` Matthew Brost
2026-03-20 15:31 ` Thomas Hellström

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=934deb296f18f9147db2478f5d645249e3a6013e.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=arvind.yadav@intel.com \
    --cc=francois.dugast@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --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 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.