public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Piotr Piórkowski" <piotr.piorkowski@intel.com>
To: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com>
Cc: <igt-dev@lists.freedesktop.org>, <lukasz.laguna@intel.com>
Subject: Re: [PATCH i-g-t 1/2] tests/intel/xe_sriov_flr: Add reset-only FLR subtest
Date: Fri, 27 Feb 2026 09:58:09 +0100	[thread overview]
Message-ID: <20260227085809.dehznq3jz735x3rm@intel.com> (raw)
In-Reply-To: <20260226173137.3221419-2-marcin.bernatowicz@linux.intel.com>

Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com> wrote on czw [2026-lut-26 18:31:36 +0100]:
> Add flr-reset-only subtest intended as a minimal smoke test
> for the VF reset sysfs write path while still using the xe-vfio-pci
> based synchronization: the test skips if xe-vfio-pci binding is disabled,
> if the xe_vfio_pci module is not loaded, or if any VF under test is
> not bound to xe-vfio-pci.
> 
> Signed-off-by: Marcin Bernatowicz <marcin.bernatowicz@linux.intel.com>
> Cc: Lukasz Laguna <lukasz.laguna@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
>  tests/intel/xe_sriov_flr.c | 65 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
> 
> diff --git a/tests/intel/xe_sriov_flr.c b/tests/intel/xe_sriov_flr.c
> index b73727787..846731697 100644
> --- a/tests/intel/xe_sriov_flr.c
> +++ b/tests/intel/xe_sriov_flr.c
> @@ -29,6 +29,12 @@
>   * Functionality: FLR
>   * Description: Examine behavior of SR-IOV VF FLR
>   *
> + * SUBTEST: flr-reset-only

Or maybe just flr-basic?

> + * Run type: BAT
> + * Description:
> + *   Initiates FLR without any additional state checks.
> + *   Useful as a basic smoke test of the reset sysfs write path.
> + *
>   * SUBTEST: flr-vf1-clear
>   * Run type: BAT
>   * Description:
> @@ -1016,6 +1022,60 @@ static void regs_subcheck_cleanup(struct subcheck_data *data)
>  {
>  }
>  
> +static void reset_only_subcheck_init(struct subcheck_data *data)
> +{
> +	if (!g_use_xe_vfio_pci) {
> +		set_skip_reason(data, "xe-vfio-pci binding is disabled\n");
> +		return;
> +	}
> +
> +	if (!igt_kmod_is_loaded("xe_vfio_pci"))

Sometimes it is xe_vfio_pci, sometimes xe-vfio-pci
What is the reason for this difference? Shouldn't we keep it somewhere as a constant?
Or have helpers to handle this module at all?

> +		set_skip_reason(data, "xe_vfio_pci is not loaded\n");
> +}
> +
> +static void reset_only_subcheck_prepare_vf(int vf_id, struct subcheck_data *data)
> +{
> +	char *slot = igt_sriov_get_vf_pci_slot_alloc(data->pf_fd, vf_id);
> +	char bound[64];
> +	int bound_ret;
> +
> +	igt_assert(slot);
> +
> +	bound_ret = igt_pci_get_bound_driver_name(slot, bound, sizeof(bound));
> +	if (bound_ret <= 0 || strcmp(bound, "xe-vfio-pci") != 0)
> +		set_skip_reason(data, "VF%u not bound to xe-vfio-pci\n", vf_id);
> +
> +	free(slot);
> +}
> +
> +static void noop_subcheck_verify_vf(int vf_id, int flr_vf_id, struct subcheck_data *data)
> +{
> +}
> +
> +static void noop_subcheck_cleanup(struct subcheck_data *data)
> +{
> +}
> +
> +static void reset_only_test(int pf_fd, int num_vfs, flr_exec_strategy exec_strategy)
> +{
> +	struct subcheck_data base = {
> +		.pf_fd = pf_fd,
> +		.num_vfs = num_vfs,
> +		.tile = 0,
> +		.stop_reason = NULL,
> +	};
> +	struct subcheck check = {
> +		.data = &base,
> +		.name = "reset-only",
> +		.init = reset_only_subcheck_init,
> +		.prepare_vf = reset_only_subcheck_prepare_vf,
> +		.verify_vf = noop_subcheck_verify_vf,
> +		.cleanup = noop_subcheck_cleanup,
> +	};
> +
> +	verify_flr(pf_fd, num_vfs, &check, 1, exec_strategy);
> +}
> +
>  static void clear_tests(int pf_fd, int num_vfs, flr_exec_strategy exec_strategy)
>  {
>  	const uint8_t num_tiles = xe_tiles_count(pf_fd);
> @@ -1141,6 +1201,11 @@ int igt_main_args("vw:", long_options, help_str, opt_handler, NULL)
>  		autoprobe = igt_sriov_is_driver_autoprobe_enabled(pf_fd);
>  	}
>  
> +	igt_describe("Initiate FLR without any additional state checks.");
> +	igt_subtest("flr-reset-only") {
> +		reset_only_test(pf_fd, 1, execute_sequential_flr);

In this case, shouldn't we have dynamic subtests regarding the number of VFs?
I know that this will be expanded in the next patch, but maybe it should be the default.
Because if someone wants to run tests on only one Vf's, they can still use
the dynamic subtets filter.

Thanks,
Piotr

> +	}
> +
>  	igt_describe("Verify LMEM, GGTT, and SCRATCH_REGS are properly cleared after VF1 FLR");
>  	igt_subtest("flr-vf1-clear") {
>  		clear_tests(pf_fd, 1, execute_sequential_flr);
> -- 
> 2.43.0
> 

-- 

  reply	other threads:[~2026-02-27  8:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26 17:31 [PATCH i-g-t 0/2] xe_sriov_flr: reset-only FLR smoke test Marcin Bernatowicz
2026-02-26 17:31 ` [PATCH i-g-t 1/2] tests/intel/xe_sriov_flr: Add reset-only FLR subtest Marcin Bernatowicz
2026-02-27  8:58   ` Piotr Piórkowski [this message]
2026-02-27 10:07     ` Bernatowicz, Marcin
2026-02-26 17:31 ` [PATCH i-g-t 2/2] tests/intel/xe_sriov_flr: Add --extended for reset-only Marcin Bernatowicz
2026-02-27  1:09 ` ✓ i915.CI.BAT: success for xe_sriov_flr: reset-only FLR smoke test Patchwork
2026-02-27  1:17 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-27  8:39 ` ✗ 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=20260227085809.dehznq3jz735x3rm@intel.com \
    --to=piotr.piorkowski@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=lukasz.laguna@intel.com \
    --cc=marcin.bernatowicz@linux.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