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>,
"Satyanarayana K V P" <satyanarayana.k.v.p@intel.com>
Subject: [PATCH v4 2/8] drm/xe/vf: Finish RESFIX by reset if CTB not enabled
Date: Fri, 6 Jun 2025 02:18:17 +0200 [thread overview]
Message-ID: <20250606001823.1010994-3-tomasz.lis@intel.com> (raw)
In-Reply-To: <20250606001823.1010994-1-tomasz.lis@intel.com>
The RESFIX state should be achievable only when CTB communication is
enabled. If CTB was disabled and we still got it, then either we're
dealing with unclean initial state, or the driver is not currently
functional. In these cases, exit the RESFIX state by reset.
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: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
---
drivers/gpu/drm/xe/xe_gt_sriov_vf.c | 11 +++++++++++
drivers/gpu/drm/xe/xe_sriov_vf.c | 16 ++++++++++++++++
drivers/gpu/drm/xe/xe_sriov_vf.h | 1 +
3 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
index 792523cfa6e6..8fa210c0ef1a 100644
--- a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
+++ b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
@@ -23,6 +23,7 @@
#include "xe_gt_sriov_vf.h"
#include "xe_gt_sriov_vf_types.h"
#include "xe_guc.h"
+#include "xe_guc_ct.h"
#include "xe_guc_hxg_helpers.h"
#include "xe_guc_relay.h"
#include "xe_mmio.h"
@@ -721,6 +722,16 @@ void xe_gt_sriov_vf_migrated_event_handler(struct xe_gt *gt)
xe_gt_assert(gt, IS_SRIOV_VF(xe));
+ if (!xe_guc_ct_enabled(>->uc.guc.ct)) {
+ /*
+ * If driver initialization is running in parallel to this handler,
+ * ignore the migration which happened before the driver was loaded.
+ * Force GuC to take the VF out of RESFIX state without any fixups.
+ */
+ xe_sriov_vf_post_migration_reset_guc_state(xe);
+ return;
+ }
+
set_bit(gt->info.id, &xe->sriov.vf.migration.gt_flags);
/*
* We need to be certain that if all flags were set, at least one
diff --git a/drivers/gpu/drm/xe/xe_sriov_vf.c b/drivers/gpu/drm/xe/xe_sriov_vf.c
index 6526fe450e55..eff6c7b96f25 100644
--- a/drivers/gpu/drm/xe/xe_sriov_vf.c
+++ b/drivers/gpu/drm/xe/xe_sriov_vf.c
@@ -147,6 +147,22 @@ void xe_sriov_vf_init_early(struct xe_device *xe)
xe_sriov_info(xe, "migration not supported by this module version\n");
}
+/**
+ * xe_sriov_vf_post_migration_reset_guc_state - Reset VF state in all GuCs.
+ * @xe: the &xe_device struct instance
+ *
+ * This function sends VF state reset to GuC, as a way of exiting RESFIX
+ * state if a proper post-migration recovery procedure has failed.
+ */
+void xe_sriov_vf_post_migration_reset_guc_state(struct xe_device *xe)
+{
+ struct xe_gt *gt;
+ unsigned int id;
+
+ for_each_gt(gt, xe, id)
+ xe_gt_reset_async(gt);
+}
+
/**
* vf_post_migration_requery_guc - Re-query GuC for current VF provisioning.
* @xe: the &xe_device struct instance
diff --git a/drivers/gpu/drm/xe/xe_sriov_vf.h b/drivers/gpu/drm/xe/xe_sriov_vf.h
index 7b8622cff2b7..ba846af34a13 100644
--- a/drivers/gpu/drm/xe/xe_sriov_vf.h
+++ b/drivers/gpu/drm/xe/xe_sriov_vf.h
@@ -10,5 +10,6 @@ struct xe_device;
void xe_sriov_vf_init_early(struct xe_device *xe);
void xe_sriov_vf_start_migration_recovery(struct xe_device *xe);
+void xe_sriov_vf_post_migration_reset_guc_state(struct xe_device *xe);
#endif
--
2.25.1
next prev parent reply other threads:[~2025-06-06 0:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-06 0:18 [PATCH v4 0/8] drm/xe/vf: Post-migration recovery of queues and jobs Tomasz Lis
2025-06-06 0:18 ` [PATCH v4 1/8] drm/xe/sa: Avoid caching GGTT address within the manager Tomasz Lis
2025-06-06 0:18 ` Tomasz Lis [this message]
2025-06-09 11:00 ` [PATCH v4 2/8] drm/xe/vf: Finish RESFIX by reset if CTB not enabled Michal Wajdeczko
2025-06-11 20:18 ` Lis, Tomasz
2025-06-06 0:18 ` [PATCH v4 3/8] drm/xe/vf: Pause submissions during RESFIX fixups Tomasz Lis
2025-06-06 0:18 ` [PATCH v4 4/8] drm/xe: Block reset while recovering from VF migration Tomasz Lis
2025-06-06 0:18 ` [PATCH v4 5/8] drm/xe/vf: Rebase HWSP of all contexts after migration Tomasz Lis
2025-06-09 11:03 ` Michal Wajdeczko
2025-06-11 20:18 ` Lis, Tomasz
2025-06-06 0:18 ` [PATCH v4 6/8] drm/xe/vf: Rebase MEMIRQ structures for " Tomasz Lis
2025-06-09 11:15 ` Michal Wajdeczko
2025-06-06 0:18 ` [PATCH v4 7/8] drm/xe/vf: Post migration, repopulate ring area for pending request Tomasz Lis
2025-06-06 0:18 ` [PATCH v4 8/8] drm/xe/vf: Refresh utilization buffer during migration recovery Tomasz Lis
2025-06-06 2:43 ` ✓ CI.Patch_applied: success for drm/xe/vf: Post-migration recovery of queues and jobs (rev4) Patchwork
2025-06-06 2:44 ` ✗ CI.checkpatch: warning " Patchwork
2025-06-06 2:45 ` ✓ CI.KUnit: success " Patchwork
2025-06-06 2:56 ` ✓ CI.Build: " Patchwork
2025-06-06 2:58 ` ✗ CI.Hooks: failure " Patchwork
2025-06-06 3:00 ` ✓ CI.checksparse: success " Patchwork
2025-06-06 3:46 ` ✓ Xe.CI.BAT: " Patchwork
2025-06-08 7:58 ` ✗ 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=20250606001823.1010994-3-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 \
--cc=satyanarayana.k.v.p@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.