Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Piotr Piórkowski" <piotr.piorkowski@intel.com>
To: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	"Michał Wajdeczko" <michal.wajdeczko@intel.com>,
	"Michał Winiarski" <michal.winiarski@intel.com>
Subject: Re: [PATCH 2/2] drm/xe/vf: Retry sending MMIO request to GUC on timeout error
Date: Thu, 20 Feb 2025 12:53:03 +0100	[thread overview]
Message-ID: <20250220115303.ywzoaxc6w3aawszr@intel.com> (raw)
In-Reply-To: <20250220064119.26623-3-satyanarayana.k.v.p@intel.com>

Satyanarayana K V P <satyanarayana.k.v.p@intel.com> wrote on czw [2025-lut-20 12:11:19 +0530]:
> Add support to allow retrying the sending of MMIO requests
> from the VF to the GUC in the event of an error. During the
> suspend/resume process, VFs begin resuming only after the PF has
> resumed. Although the PF resumes, the GUC reset and provisioning
> occur later in a separate worker process.
> 
> When there are a large number of VFs, some may attempt to resume
> before the PF has completed its provisioning. Therefore, if a
> MMIO request from a VF fails during this period, we will retry
> sending the request up to GUC_RESET_VF_STATE_RETRY_MAX times,
> which is set to a maximum of 10 attempts.

Maybe I'm wrong, but shouldn't the previous patch have prevented this?
I understand that if PF and VF are on the same host, that prev patch will cause VF
to not start resuming until PF has finished resuming.
If the VF is passed on to the VM, then I don't think there should be a problem, because
userspace (and VM) will not start resuming until the kernel on the host is ready.

So it seems to me that a situation should not arise here when VF sends the reset
button actions and the config has not yet been sent by PF to GuC.

BTW: The title of the cover letter is a bit misleading because it only mentions the PF and VF link.

Thanks,
Piotr

> 
> Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
> Cc: Michał Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Michał Winiarski <michal.winiarski@intel.com>
> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_gt_sriov_vf.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> index 4831549da319..a439261bf4d7 100644
> --- a/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> +++ b/drivers/gpu/drm/xe/xe_gt_sriov_vf.c
> @@ -47,12 +47,19 @@ static int guc_action_vf_reset(struct xe_guc *guc)
>  	return ret > 0 ? -EPROTO : ret;
>  }
>  
> +#define GUC_RESET_VF_STATE_RETRY_MAX	10
>  static int vf_reset_guc_state(struct xe_gt *gt)
>  {
> +	unsigned int retry = GUC_RESET_VF_STATE_RETRY_MAX;
>  	struct xe_guc *guc = &gt->uc.guc;
>  	int err;
>  
> -	err = guc_action_vf_reset(guc);
> +	do {
> +		err = guc_action_vf_reset(guc);
> +		if (!err || err != -ETIMEDOUT)
> +			break;
> +	} while (--retry);
> +
>  	if (unlikely(err))
>  		xe_gt_sriov_err(gt, "Failed to reset GuC state (%pe)\n", ERR_PTR(err));
>  	return err;
> -- 
> 2.35.3
> 

-- 

  reply	other threads:[~2025-02-20 11:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-20  6:41 [PATCH 0/2] Create a link between PF and VF Satyanarayana K V P
2025-02-20  6:41 ` [PATCH 1/2] drm/xe/pf: Create a link between PF and VF devices Satyanarayana K V P
2025-02-20 11:33   ` Piotr Piórkowski
2025-02-20  6:41 ` [PATCH 2/2] drm/xe/vf: Retry sending MMIO request to GUC on timeout error Satyanarayana K V P
2025-02-20 11:53   ` Piotr Piórkowski [this message]
2025-02-20 15:18     ` K V P, Satyanarayana
2025-02-20  8:14 ` ✓ CI.Patch_applied: success for Create a link between PF and VF Patchwork
2025-02-20  8:14 ` ✓ CI.checkpatch: " Patchwork
2025-02-20  8:15 ` ✓ CI.KUnit: " Patchwork
2025-02-20  8:38 ` ✓ CI.Build: " Patchwork
2025-02-20  8:41 ` ✓ CI.Hooks: " Patchwork
2025-02-20  8:44 ` ✓ CI.checksparse: " Patchwork
2025-02-20  9:04 ` ✓ Xe.CI.BAT: " Patchwork
2025-02-21  2:44 ` ✗ 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=20250220115303.ywzoaxc6w3aawszr@intel.com \
    --to=piotr.piorkowski@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=michal.wajdeczko@intel.com \
    --cc=michal.winiarski@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