From: Tomasz Lis <tomasz.lis@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Michał Winiarski" <michal.winiarski@intel.com>,
"Michał Wajdeczko" <michal.wajdeczko@intel.com>,
"Piotr Piórkowski" <piotr.piorkowski@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>
Subject: [PATCH v8 3/8] drm/xe: Block reset while recovering from VF migration
Date: Fri, 1 Aug 2025 03:50:40 +0200 [thread overview]
Message-ID: <20250801015045.957609-4-tomasz.lis@intel.com> (raw)
In-Reply-To: <20250801015045.957609-1-tomasz.lis@intel.com>
Resetting GuC during recovery could interfere with the recovery
process. Such reset might be also triggered without justification,
due to migration taking time, rather than due to the workload not
progressing.
Doing GuC reset during the recovery would cause exit of RESFIX state,
and therefore continuation of GuC work while fixups are still being
applied. To avoid that, reset needs to be blocked during the recovery.
This patch blocks the reset during recovery. Reset request in that
time range will be stalled, and unblocked only after GuC goes out
of RESFIX state.
In case a reset procedure already started while the recovery is
triggered, there isn't much we can do - we cannot wait for it to
finish as it involves waiting for hardware, and we can't be sure
at which exact point of the reset procedure the GPU got switched.
Therefore, the rare cases where migration happens while reset is
in progress, are still dangerous. Resets are not a part of the
standard flow, and cause unfinished workloads - that will happen
during the reset interrupted by migration as well, so it doesn't
diverge that much from what normally happens during such resets.
v2: Introduce a new atomic for reset blocking, as we cannot reuse
`stopped` atomic (that could lead to losing a workload).
v3: Switched atomic functs to ones which include proper barriers
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Reviewed-by: Michal Winiarski <michal.winiarski@intel.com>
---
drivers/gpu/drm/xe/xe_gt.c | 10 ++++++++
drivers/gpu/drm/xe/xe_guc_submit.c | 37 ++++++++++++++++++++++++++++++
drivers/gpu/drm/xe/xe_guc_submit.h | 3 +++
drivers/gpu/drm/xe/xe_guc_types.h | 6 +++++
drivers/gpu/drm/xe/xe_sriov_vf.c | 12 ++++++++--
5 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_gt.c b/drivers/gpu/drm/xe/xe_gt.c
index 5a79c6e3208b..390394bbaadc 100644
--- a/drivers/gpu/drm/xe/xe_gt.c
+++ b/drivers/gpu/drm/xe/xe_gt.c
@@ -41,6 +41,7 @@
#include "xe_gt_topology.h"
#include "xe_guc_exec_queue_types.h"
#include "xe_guc_pc.h"
+#include "xe_guc_submit.h"
#include "xe_hw_fence.h"
#include "xe_hw_engine_class_sysfs.h"
#include "xe_irq.h"
@@ -802,6 +803,11 @@ static int do_gt_restart(struct xe_gt *gt)
return 0;
}
+static int gt_wait_reset_unblock(struct xe_gt *gt)
+{
+ return xe_guc_wait_reset_unblock(>->uc.guc);
+}
+
static int gt_reset(struct xe_gt *gt)
{
unsigned int fw_ref;
@@ -816,6 +822,10 @@ static int gt_reset(struct xe_gt *gt)
xe_gt_info(gt, "reset started\n");
+ err = gt_wait_reset_unblock(gt);
+ if (!err)
+ xe_gt_warn(gt, "reset block failed to get lifted");
+
xe_pm_runtime_get(gt_to_xe(gt));
if (xe_fault_inject_gt_reset()) {
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
index fe132d9d3156..f72785c655f8 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.c
+++ b/drivers/gpu/drm/xe/xe_guc_submit.c
@@ -1777,6 +1777,43 @@ static void guc_exec_queue_stop(struct xe_guc *guc, struct xe_exec_queue *q)
}
}
+/**
+ * xe_guc_submit_reset_block - Disallow reset calls on given GuC.
+ * @guc: the &xe_guc struct instance
+ */
+int xe_guc_submit_reset_block(struct xe_guc *guc)
+{
+ return atomic_fetch_or(1, &guc->submission_state.reset_blocked);
+}
+
+/**
+ * xe_guc_submit_reset_unblock - Allow back reset calls on given GuC.
+ * @guc: the &xe_guc struct instance
+ */
+void xe_guc_submit_reset_unblock(struct xe_guc *guc)
+{
+ atomic_set_release(&guc->submission_state.reset_blocked, 0);
+ wake_up_all(&guc->ct.wq);
+}
+
+static int guc_submit_reset_is_blocked(struct xe_guc *guc)
+{
+ return atomic_read_acquire(&guc->submission_state.reset_blocked);
+}
+
+/* Maximum time of blocking reset */
+#define RESET_BLOCK_PERIOD_MAX (HZ * 5)
+
+/**
+ * xe_guc_wait_reset_unblock - Wait until reset blocking flag is lifted, or timeout.
+ * @guc: the &xe_guc struct instance
+ */
+int xe_guc_wait_reset_unblock(struct xe_guc *guc)
+{
+ return wait_event_timeout(guc->ct.wq,
+ !guc_submit_reset_is_blocked(guc), RESET_BLOCK_PERIOD_MAX);
+}
+
int xe_guc_submit_reset_prepare(struct xe_guc *guc)
{
int ret;
diff --git a/drivers/gpu/drm/xe/xe_guc_submit.h b/drivers/gpu/drm/xe/xe_guc_submit.h
index ff44500f3da2..4dd278f5f61b 100644
--- a/drivers/gpu/drm/xe/xe_guc_submit.h
+++ b/drivers/gpu/drm/xe/xe_guc_submit.h
@@ -20,6 +20,9 @@ void xe_guc_submit_stop(struct xe_guc *guc);
int xe_guc_submit_start(struct xe_guc *guc);
void xe_guc_submit_pause(struct xe_guc *guc);
void xe_guc_submit_unpause(struct xe_guc *guc);
+int xe_guc_submit_reset_block(struct xe_guc *guc);
+void xe_guc_submit_reset_unblock(struct xe_guc *guc);
+int xe_guc_wait_reset_unblock(struct xe_guc *guc);
void xe_guc_submit_wedge(struct xe_guc *guc);
int xe_guc_read_stopped(struct xe_guc *guc);
diff --git a/drivers/gpu/drm/xe/xe_guc_types.h b/drivers/gpu/drm/xe/xe_guc_types.h
index 1fde7614fcc5..c7b9642b41ba 100644
--- a/drivers/gpu/drm/xe/xe_guc_types.h
+++ b/drivers/gpu/drm/xe/xe_guc_types.h
@@ -85,6 +85,12 @@ struct xe_guc {
struct xarray exec_queue_lookup;
/** @submission_state.stopped: submissions are stopped */
atomic_t stopped;
+ /**
+ * @submission_state.reset_blocked: reset attempts are blocked;
+ * blocking reset in order to delay it may be required if running
+ * an operation which is sensitive to resets.
+ */
+ atomic_t reset_blocked;
/** @submission_state.lock: protects submission state */
struct mutex lock;
/** @submission_state.enabled: submission is enabled */
diff --git a/drivers/gpu/drm/xe/xe_sriov_vf.c b/drivers/gpu/drm/xe/xe_sriov_vf.c
index c66b17da1ce7..71d28b30de43 100644
--- a/drivers/gpu/drm/xe/xe_sriov_vf.c
+++ b/drivers/gpu/drm/xe/xe_sriov_vf.c
@@ -163,9 +163,15 @@ static void vf_post_migration_shutdown(struct xe_device *xe)
{
struct xe_gt *gt;
unsigned int id;
+ int ret = 0;
- for_each_gt(gt, xe, id)
+ for_each_gt(gt, xe, id) {
xe_guc_submit_pause(>->uc.guc);
+ ret |= xe_guc_submit_reset_block(>->uc.guc);
+ }
+
+ if (ret)
+ drm_info(&xe->drm, "migration recovery encountered ongoing reset\n");
}
/**
@@ -187,8 +193,10 @@ static void vf_post_migration_kickstart(struct xe_device *xe)
*/
xe_irq_resume(xe);
- for_each_gt(gt, xe, id)
+ for_each_gt(gt, xe, id) {
+ xe_guc_submit_reset_unblock(>->uc.guc);
xe_guc_submit_unpause(>->uc.guc);
+ }
}
static bool gt_vf_post_migration_needed(struct xe_gt *gt)
--
2.25.1
next prev parent reply other threads:[~2025-08-01 1:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-01 1:50 [PATCH v8 0/8] drm/xe/vf: Post-migration recovery of queues and jobs Tomasz Lis
2025-08-01 1:50 ` [PATCH v8 1/8] drm/xe/sa: Avoid caching GGTT address within the manager Tomasz Lis
2025-08-01 1:50 ` [PATCH v8 2/8] drm/xe/vf: Pause submissions during RESFIX fixups Tomasz Lis
2025-08-01 1:50 ` Tomasz Lis [this message]
2025-08-01 1:50 ` [PATCH v8 4/8] drm/xe/vf: Rebase HWSP of all contexts after migration Tomasz Lis
2025-08-01 1:50 ` [PATCH v8 5/8] drm/xe/vf: Rebase MEMIRQ structures for " Tomasz Lis
2025-08-01 1:50 ` [PATCH v8 6/8] drm/xe/vf: Post migration, repopulate ring area for pending request Tomasz Lis
2025-08-01 23:01 ` Cavitt, Jonathan
2025-08-01 1:50 ` [PATCH v8 7/8] drm/xe/vf: Refresh utilization buffer during migration recovery Tomasz Lis
2025-08-01 1:50 ` [PATCH v8 8/8] drm/xe/vf: Rebase exec queue parallel commands " Tomasz Lis
2025-08-01 20:57 ` Michał Winiarski
2025-08-01 3:07 ` ✓ CI.KUnit: success for drm/xe/vf: Post-migration recovery of queues and jobs (rev9) Patchwork
2025-08-01 3:41 ` ✓ Xe.CI.BAT: " Patchwork
2025-08-01 5:34 ` ✓ Xe.CI.Full: " Patchwork
2025-08-12 4:47 ` [PATCH v8 0/8] drm/xe/vf: Post-migration recovery of queues and jobs Matthew Brost
2025-08-12 15:55 ` Thomas Hellström
2025-08-12 16:38 ` Lis, Tomasz
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=20250801015045.957609-4-tomasz.lis@intel.com \
--to=tomasz.lis@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=michal.winiarski@intel.com \
--cc=piotr.piorkowski@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).