Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Harrison <john.c.harrison@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
	<intel-xe@lists.freedesktop.org>
Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Subject: Re: [PATCH 1/2] drm/xe: Introduce flag to indicate possible fault injection
Date: Mon, 12 May 2025 11:36:53 -0700	[thread overview]
Message-ID: <d03eda9b-d090-4ebc-901b-31916df24fbb@intel.com> (raw)
In-Reply-To: <20250512161947.128-2-michal.wajdeczko@intel.com>

On 5/12/2025 9:19 AM, Michal Wajdeczko wrote:
> When running some fault injection tests the driver might generate
> a lot of error logs which might unnecessary stress our CI systems.
>
> Introduce a flag exposed in debugfs that can be used by the fault
> injection tests to give the driver a hint to suppress non-essential
> error logs or dumps that might be otherwise generated.
Why use debugfs? The whole point of the fault injection test is that it 
replaces an existing function with something that just returns an error 
code. Seems the perfect way to have a function which is simply "return 
0;" in normal usage but modified by the injection test to return an 
error code when a test is running. Which is what the original patch was 
doing. That way everything is self contained, there are no extraneous 
interfaces in unrelated subsystems.

Unless you are wanting a more generic 'test_in_progress' function that 
is not specific to fault injection, then using debugfs seems like an 
unnecessary complication.

John.

>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: John Harrison <john.c.harrison@intel.com>
> ---
>   drivers/gpu/drm/xe/xe_debugfs.c      |  5 +++++
>   drivers/gpu/drm/xe/xe_device.h       | 12 ++++++++++++
>   drivers/gpu/drm/xe/xe_device_types.h |  9 +++++++++
>   3 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_debugfs.c b/drivers/gpu/drm/xe/xe_debugfs.c
> index d0503959a8ed..0567a57597d3 100644
> --- a/drivers/gpu/drm/xe/xe_debugfs.c
> +++ b/drivers/gpu/drm/xe/xe_debugfs.c
> @@ -235,4 +235,9 @@ void xe_debugfs_register(struct xe_device *xe)
>   	xe_pxp_debugfs_register(xe->pxp);
>   
>   	fault_create_debugfs_attr("fail_gt_reset", root, &gt_reset_failure);
> +
> +#if IS_ENABLED(CONFIG_FAULT_INJECTION)
> +	debugfs_create_bool("fault_injection_in_progress", 0600, root,
> +			    &xe->fault_injection_in_progress);
> +#endif
>   }
> diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
> index 0bc3bc8e6803..ea25d8161050 100644
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -209,4 +209,16 @@ void xe_file_put(struct xe_file *xef);
>   #define LNL_FLUSH_WORK(wrk__) \
>   	flush_work(wrk__)
>   
> +#if IS_ENABLED(CONFIG_FAULT_INJECTION)
> +static inline bool xe_fault_injection_in_progress(struct xe_device *xe)
> +{
> +	return xe->fault_injection_in_progress;
> +}
> +#else
> +static inline bool xe_fault_injection_in_progress(struct xe_device *xe)
> +{
> +	return false;
> +}
> +#endif
> +
>   #endif
> diff --git a/drivers/gpu/drm/xe/xe_device_types.h b/drivers/gpu/drm/xe/xe_device_types.h
> index 06c65dace026..513a811a3121 100644
> --- a/drivers/gpu/drm/xe/xe_device_types.h
> +++ b/drivers/gpu/drm/xe/xe_device_types.h
> @@ -578,6 +578,15 @@ struct xe_device {
>   	u8 vm_inject_error_position;
>   #endif
>   
> +#if IS_ENABLED(CONFIG_FAULT_INJECTION)
> +	/**
> +	 * @fault_injection_in_progress: flag used by the fault injection
> +	 * tests to allow the driver to suppress non-essential error dumps
> +	 * that might be otherwise generated due to an injected fault.
> +	 */
> +	bool fault_injection_in_progress;
> +#endif
> +
>   	/* private: */
>   
>   #if IS_ENABLED(CONFIG_DRM_XE_DISPLAY)


  reply	other threads:[~2025-05-12 18:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-12 16:19 [PATCH 0/2] Suppress some dumps during fault injection tests Michal Wajdeczko
2025-05-12 16:19 ` [PATCH 1/2] drm/xe: Introduce flag to indicate possible fault injection Michal Wajdeczko
2025-05-12 18:36   ` John Harrison [this message]
2025-05-12 20:20     ` Michal Wajdeczko
2025-05-14 21:05       ` John Harrison
2025-05-15 10:25         ` Michal Wajdeczko
2025-05-21 21:15           ` John Harrison
2025-05-12 16:19 ` [PATCH 2/2] drm/xe/guc: Suppress Dead CTB Dump during fault injection tests Michal Wajdeczko
2025-05-12 16:44 ` ✓ CI.Patch_applied: success for Suppress some dumps " Patchwork
2025-05-12 16:44 ` ✓ CI.checkpatch: " Patchwork
2025-05-12 16:45 ` ✓ CI.KUnit: " Patchwork
2025-05-12 16:55 ` ✗ CI.Build: failure " Patchwork
2025-05-13 11:09 ` ✓ CI.Patch_applied: success " Patchwork
2025-05-13 11:09 ` ✓ CI.checkpatch: " Patchwork
2025-05-13 11:10 ` ✓ CI.KUnit: " Patchwork
2025-05-13 11:18 ` ✓ CI.Build: " Patchwork
2025-05-13 11:21 ` ✓ CI.Hooks: " Patchwork
2025-05-13 11:22 ` ✓ CI.checksparse: " Patchwork
2025-05-13 12:01 ` ✓ Xe.CI.BAT: " Patchwork
2025-05-13 13:38 ` ✓ Xe.CI.Full: " Patchwork
2025-05-26 22:04 ` ✓ CI.Patch_applied: " Patchwork
2025-05-26 22:04 ` ✓ CI.checkpatch: " Patchwork
2025-05-26 22:05 ` ✓ CI.KUnit: " Patchwork
2025-05-26 22:15 ` ✓ CI.Build: " 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=d03eda9b-d090-4ebc-901b-31916df24fbb@intel.com \
    --to=john.c.harrison@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michal.wajdeczko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox