From: Raag Jadav <raag.jadav@intel.com>
To: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: intel-xe@lists.freedesktop.org, matthew.brost@intel.com,
rodrigo.vivi@intel.com, thomas.hellstrom@linux.intel.com,
riana.tauro@intel.com, michal.wajdeczko@intel.com,
matthew.d.roper@intel.com, michal.winiarski@intel.com,
matthew.auld@intel.com, dev@lankhorst.se, jani.nikula@intel.com,
lukasz.laguna@intel.com, zhanjun.dong@intel.com, lukas@wunner.de,
badal.nilawar@intel.com
Subject: Re: [PATCH v8 05/10] drm/xe/exec_queue: Introduce xe_exec_queue_reinit()
Date: Mon, 29 Jun 2026 14:23:55 +0200 [thread overview]
Message-ID: <akJj269We0sm6-Eg@black.igk.intel.com> (raw)
In-Reply-To: <997fcd13-eb94-4770-a3b2-4d2d633e2985@intel.com>
On Thu, Jun 25, 2026 at 05:06:12PM -0700, Daniele Ceraolo Spurio wrote:
> On 6/3/2026 3:17 AM, Raag Jadav wrote:
> > In preparation of usecases which require re-initializing exec queue
> > after PCIe FLR, introduce xe_exec_queue_reinit() helper. All the exec
> > queue LCRs already exist but the context is lost on PCIe FLR and needs
> > re-initialization.
> >
> > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> > Tested-by: Lukasz Laguna <lukasz.laguna@intel.com>
> > ---
> > v2: Re-initialize migrate context (Matthew Brost)
> > v6: Add IS_DGFX() and EXEC_QUEUE_FLAG_KERNEL asserts (Daniele)
> > ---
> > drivers/gpu/drm/xe/xe_exec_queue.c | 42 +++++++++++++++++++++++++++---
> > drivers/gpu/drm/xe/xe_exec_queue.h | 1 +
> > drivers/gpu/drm/xe/xe_lrc.c | 17 ++++++++++++
> > drivers/gpu/drm/xe/xe_lrc.h | 2 ++
> > 4 files changed, 58 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c
> > index 1b5ca3ce578a..91b241a7ab24 100644
> > --- a/drivers/gpu/drm/xe/xe_exec_queue.c
> > +++ b/drivers/gpu/drm/xe/xe_exec_queue.c
> > @@ -335,9 +335,8 @@ static void __xe_exec_queue_fini(struct xe_exec_queue *q)
> > xe_lrc_put(q->lrc[i]);
> > }
> > -static int __xe_exec_queue_init(struct xe_exec_queue *q, u32 exec_queue_flags)
> > +static u32 xe_lrc_init_flags(struct xe_exec_queue *q, u32 exec_queue_flags)
> > {
> > - int i, err;
> > u32 flags = 0;
> > /*
> > @@ -360,6 +359,13 @@ static int __xe_exec_queue_init(struct xe_exec_queue *q, u32 exec_queue_flags)
> > if (q->flags & EXEC_QUEUE_FLAG_DISABLE_STATE_CACHE_PERF_FIX)
> > flags |= XE_LRC_DISABLE_STATE_CACHE_PERF_FIX;
> > + return flags;
> > +}
> > +
> > +static int __xe_exec_queue_init(struct xe_exec_queue *q, u32 exec_queue_flags)
> > +{
> > + int i, err;
> > +
> > err = q->ops->init(q);
> > if (err)
> > return err;
> > @@ -383,8 +389,8 @@ static int __xe_exec_queue_init(struct xe_exec_queue *q, u32 exec_queue_flags)
> > marker = xe_gt_sriov_vf_wait_valid_ggtt(q->gt);
> > - lrc = xe_lrc_create(q->hwe, q->vm, q->replay_state,
> > - xe_lrc_ring_size(), q->msix_vec, flags);
> > + lrc = xe_lrc_create(q->hwe, q->vm, q->replay_state, xe_lrc_ring_size(),
> > + q->msix_vec, xe_lrc_init_flags(q, exec_queue_flags));
> > if (IS_ERR(lrc)) {
> > err = PTR_ERR(lrc);
> > goto err_lrc;
> > @@ -406,6 +412,34 @@ static int __xe_exec_queue_init(struct xe_exec_queue *q, u32 exec_queue_flags)
> > return err;
> > }
> > +/**
> > + * xe_exec_queue_reinit() - Re-initialize exec queue
> > + * @q: exec queue to re-initialize
> > + *
> > + * Returns: 0 on success, negative error code otherwise.
> > + */
> > +int xe_exec_queue_reinit(struct xe_exec_queue *q)
> > +{
> > + int i, err;
> > +
> > + /* TODO: Re-initialize GSC and PXP queues */
> > + xe_assert(gt_to_xe(q->gt), IS_DGFX(gt_to_xe(q->gt)));
> You can use xe_gt_assert here. Also, note that us not supporting GSC and PXP
> on discrete is a choice, not a generic requirement, so IMO for PXP/GSC
> checking it'd be better to add:
>
> xe_gt_assert(q->gt, !xe_uc_fw_is_loadable(>->uc.gsc.fw));
>
> xe_gt_assert(q->gt, !xe_pxp_is_enabled(gt_to_xe(q->gt)->pxp));
Sure.
> > + /* Re-initialization only allowed for kernel queues */
> > + xe_assert(gt_to_xe(q->gt), q->flags & EXEC_QUEUE_FLAG_KERNEL);
> > +
> > + /* Re-initialize submission backend */
> > + q->ops->reinit_kernel(q);
>
> Thinking about it, the xe_sched_reinit() call from patch 2 could be moved
> here since that's not back-end specific.
> I won't ask you to re-spin just for this, so I'm ok with it being considered
> as a follow-up, but if you need to do a re-spin anyway it might be worth
> doing it now.
We xe_sched_init() inside guc_exec_queue_init() which IIUC is ->init()
backend call, so I thought we should be following the same pattern here?
Or did I miss something?
> > +
> > + for (i = 0; i < q->width; i++) {
> > + err = xe_lrc_reinit(q->lrc[i], q->hwe, q->vm, q->replay_state,
> > + q->msix_vec, xe_lrc_init_flags(q, q->flags));
> > + if (err)
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > /**
> > * xe_exec_queue_create() - Create an exec queue
> > * @xe: Xe device
> > diff --git a/drivers/gpu/drm/xe/xe_exec_queue.h b/drivers/gpu/drm/xe/xe_exec_queue.h
> > index a82d99bd77bc..445867d4da26 100644
> > --- a/drivers/gpu/drm/xe/xe_exec_queue.h
> > +++ b/drivers/gpu/drm/xe/xe_exec_queue.h
> > @@ -34,6 +34,7 @@ struct xe_exec_queue *xe_exec_queue_create_bind(struct xe_device *xe,
> > void xe_exec_queue_fini(struct xe_exec_queue *q);
> > void xe_exec_queue_destroy(struct kref *ref);
> > void xe_exec_queue_assign_name(struct xe_exec_queue *q, u32 instance);
> > +int xe_exec_queue_reinit(struct xe_exec_queue *q);
> > static inline struct xe_exec_queue *
> > xe_exec_queue_get_unless_zero(struct xe_exec_queue *q)
> > diff --git a/drivers/gpu/drm/xe/xe_lrc.c b/drivers/gpu/drm/xe/xe_lrc.c
> > index a4292a11391d..c425269893fe 100644
> > --- a/drivers/gpu/drm/xe/xe_lrc.c
> > +++ b/drivers/gpu/drm/xe/xe_lrc.c
> > @@ -1629,6 +1629,23 @@ static int xe_lrc_ctx_init(struct xe_lrc *lrc, struct xe_hw_engine *hwe, struct
> > return err;
> > }
> > +/**
> > + * xe_lrc_reinit() - Re-initialize LRC
> > + * @lrc: Pointer to the LRC
> > + * @hwe: Hardware Engine
> > + * @vm: The VM (address space)
> > + * @replay_state: GPU hang replay state
> > + * @msix_vec: MSI-X interrupt vector (for platforms that support it)
> > + * @init_flags: LRC initialization flags
> > + *
> > + * Returns: 0 on success, negative error code otherwise.
> > + */
> > +int xe_lrc_reinit(struct xe_lrc *lrc, struct xe_hw_engine *hwe, struct xe_vm *vm,
> > + void *replay_state, u16 msix_vec, u32 init_flags)
> > +{
> > + return xe_lrc_ctx_init(lrc, hwe, vm, replay_state, msix_vec, init_flags);
>
> nit: I wonder if it 'd just be easier to just export xe_lrc_ctx_init instead
> of creating xe_lrc_reinit. Not a blocker, so with the asserts fixed:
Coming right up.
> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Awesome :)
Raag
> > +}
> > +
> > static int xe_lrc_init(struct xe_lrc *lrc, struct xe_hw_engine *hwe, struct xe_vm *vm,
> > void *replay_state, u32 ring_size, u16 msix_vec, u32 init_flags)
> > {
> > diff --git a/drivers/gpu/drm/xe/xe_lrc.h b/drivers/gpu/drm/xe/xe_lrc.h
> > index 0a3a611391ee..333b11f739ea 100644
> > --- a/drivers/gpu/drm/xe/xe_lrc.h
> > +++ b/drivers/gpu/drm/xe/xe_lrc.h
> > @@ -56,6 +56,8 @@ struct xe_lrc_snapshot {
> > struct xe_lrc *xe_lrc_create(struct xe_hw_engine *hwe, struct xe_vm *vm,
> > void *replay_state, u32 ring_size, u16 msix_vec, u32 flags);
> > +int xe_lrc_reinit(struct xe_lrc *lrc, struct xe_hw_engine *hwe, struct xe_vm *vm,
> > + void *replay_state, u16 msix_vec, u32 init_flags);
> > void xe_lrc_destroy(struct kref *ref);
> > /**
>
next prev parent reply other threads:[~2026-06-29 12:24 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 10:17 [PATCH v8 00/10] Introduce Xe PCIe FLR Raag Jadav
2026-06-03 10:17 ` [PATCH v8 01/10] drm/xe/uc_fw: Allow re-initializing firmware Raag Jadav
2026-06-25 23:40 ` Daniele Ceraolo Spurio
2026-06-03 10:17 ` [PATCH v8 02/10] drm/xe/guc_submit: Introduce guc_exec_queue_reinit_kernel() Raag Jadav
2026-06-25 23:46 ` Daniele Ceraolo Spurio
2026-06-03 10:17 ` [PATCH v8 03/10] drm/xe/gt: Introduce FLR helpers Raag Jadav
2026-06-03 10:17 ` [PATCH v8 04/10] drm/xe/bo_evict: Introduce xe_bo_restore_map() Raag Jadav
2026-07-01 5:21 ` Gupta, Varun
2026-06-03 10:17 ` [PATCH v8 05/10] drm/xe/exec_queue: Introduce xe_exec_queue_reinit() Raag Jadav
2026-06-26 0:06 ` Daniele Ceraolo Spurio
2026-06-29 12:23 ` Raag Jadav [this message]
2026-06-03 10:17 ` [PATCH v8 06/10] drm/xe/migrate: Introduce xe_migrate_reinit() Raag Jadav
2026-06-03 10:17 ` [PATCH v8 07/10] drm/xe/pm: Introduce xe_device_suspend/resume() Raag Jadav
2026-06-03 10:58 ` Rodrigo Vivi
2026-06-03 10:17 ` [PATCH v8 08/10] drm/xe: Improve wedged state management Raag Jadav
2026-06-03 10:56 ` Rodrigo Vivi
2026-06-04 6:52 ` Tauro, Riana
2026-06-04 8:39 ` Raag Jadav
2026-06-17 5:58 ` Tauro, Riana
2026-06-17 6:11 ` Matthew Brost
2026-06-03 10:17 ` [PATCH v8 09/10] drm/xe/pci: Introduce PCIe FLR Raag Jadav
2026-06-03 10:40 ` Rodrigo Vivi
2026-06-03 10:17 ` [PATCH v8 10/10] drm/xe/doc: Wire up PCI Error Handling Raag Jadav
2026-06-03 10:28 ` ✗ CI.checkpatch: warning for Introduce Xe PCIe FLR (rev8) Patchwork
2026-06-03 10:29 ` ✓ CI.KUnit: success " Patchwork
2026-06-03 11:11 ` ✓ Xe.CI.BAT: " Patchwork
2026-06-03 22:55 ` ✓ Xe.CI.FULL: " 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=akJj269We0sm6-Eg@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=badal.nilawar@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dev@lankhorst.se \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=lukas@wunner.de \
--cc=lukasz.laguna@intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=michal.winiarski@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
--cc=zhanjun.dong@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.