Re: [PATCH v4 3/3] drm/xe/vf: Add debugfs entries to test VF double migration

[Michal Wajdeczko <michal.wajdeczko@intel.com>]

On 11/18/2025 12:41 PM, Satyanarayana K V P wrote:
> VF migration sends a marker to the GUC before resource fixups begin,
> and repeats the marker with the RESFIX_DONE notification. This prevents
> the GUC from submitting jobs during double migration events.
> 
> To reliably test double migration, a second migration must be triggered
> while fixups from the first migration are still in progress. Since fixups
> complete quickly, reproducing this scenario is difficult. Introduce
> debugfs controls to add delays in the post-fixup phase, creating a
> deterministic window for subsequent migrations.

how will we know which delay value gives "deterministic" result?

on some setups, delay like 10s could be too small, and maybe for
others will be just a waste of time?

maybe instead of looking for some best finite delay, we should just
introduce some other mechanism that would block next 'recovery' step
by explicit action from the test?

maybe this debugfs entry should be like:

	resfix_stoppers: ulong
		0 = no stops/no waits/no delays
		BIT(0) = stop before sending RESFIX START
		BIT(1) = stop before querying
		BIT(2) = stop before restarting
		BIT(3) = stop before sending RESFIX DONE

then the test can setup stop points before starting migration

and then driver will enter a loop until given stop bit is cleared
by the test?

> 
> New debugfs entries:
> 	/sys/kernel/debug/dri/<card>/
> 	├── gt0
> 	│   ├── vf
> 	│   │   ├── resfix_delay_ms
> 
> - resfix_delay_ms: delay after sending RESFIX_START marker
> 
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Tomasz Lis <tomasz.lis@intel.com>
> 
> ---
> V3 -> V4:
> - New commit
> 
> V2 -> V3:
> - None.
> 
> V1 -> V2:
> - None.
> ---
>  drivers/gpu/drm/xe/xe_gt_sriov_vf.c         | 13 +++++++++++++
>  drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.c |  5 +++++
>  drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h   |  8 ++++++++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> index 08c00b773a13..13ae71dca208 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> @@ -5,6 +5,7 @@
>  
>  #include <linux/bitfield.h>
>  #include <linux/bsearch.h>
> +#include <linux/delay.h>
>  
>  #include <drm/drm_managed.h>
>  #include <drm/drm_print.h>
> @@ -1234,6 +1235,16 @@ static int vf_post_migration_notify_resfix_done(struct xe_gt *gt, u16 marker)
>  	return vf_notify_resfix_done(gt, marker);
>  }
>  
> +static inline void vf_post_migration_inject_delay(struct xe_gt *gt)
> +{
> +	ulong delay_ms = gt->sriov.vf.migration.debug.resfix_delay_ms;
> +
> +	if (delay_ms) {
> +		xe_gt_dbg(gt, "*TESTING* injecting %lu ms delay ...\n", delay_ms);
> +		msleep(delay_ms);
> +	}
> +}
> +
>  static u16 vf_post_migration_resfix_start_marker(struct xe_gt *gt)
>  {
>  	xe_gt_assert(gt, IS_SRIOV_VF(gt_to_xe(gt)));
> @@ -1275,6 +1286,8 @@ static void vf_post_migration_recovery(struct xe_gt *gt)
>  	if (err)
>  		goto fail;
>  
> +	vf_post_migration_inject_delay(gt);

shouldn't we wait right after sending RESFIX_START,
ie. before calling vf_post_migration_fixups() ?

or have few wait/stop points to allow testing more scenarios?

> +
>  	vf_post_migration_rearm(gt);
>  
>  	err = vf_post_migration_notify_resfix_done(gt, marker);
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.c b/drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.c
> index 2ed5b6780d30..33d6f37d8dd6 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_vf_debugfs.c
> @@ -69,4 +69,9 @@ void xe_gt_sriov_vf_debugfs_register(struct xe_gt *gt, struct dentry *root)
>  	vfdentry->d_inode->i_private = gt;
>  
>  	drm_debugfs_create_files(vf_info, ARRAY_SIZE(vf_info), vfdentry, minor);
> +
> +	if (IS_ENABLED(CONFIG_DRM_XE_DEBUG)) {
> +		debugfs_create_ulong("resfix_delay_ms", 0600, vfdentry,
> +				     &gt->sriov.vf.migration.debug.resfix_delay_ms);
> +	}
>  }
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h b/drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h
> index 66c0062a42c6..e7244e9fd406 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_vf_types.h
> @@ -52,6 +52,14 @@ struct xe_gt_sriov_vf_migration {
>  	wait_queue_head_t wq;
>  	/** @scratch: Scratch memory for VF recovery */
>  	void *scratch;
> +	/** @debug: Debug hooks for delaying migration */
> +	struct {
> +		/**
> +		 * @debug.resfix_delay_ms: Delay in msec after RESFIX_START
> +		 * marker is sent to GUC.
> +		 */
> +		ulong resfix_delay_ms;
> +	} debug;
>  	/**
>  	 * @resfix_marker: Marker sent on start and on end of post-migration
>  	 * steps.