public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] drm/xe/guc: Wait before retrying sending H2G
Date: Tue, 20 Jan 2026 22:36:49 +0100	[thread overview]
Message-ID: <efaf7eea-987b-44f0-a3f0-1b0c73f2f1ea@intel.com> (raw)
In-Reply-To: <aW/tdSZ3HAjTjDDA@lstrano-desk.jf.intel.com>



On 1/20/2026 10:02 PM, Matthew Brost wrote:
> On Tue, Jan 20, 2026 at 07:50:46PM +0100, Michal Wajdeczko wrote:
>> We shall resend H2G message after receiving NO_RESPONSE_RETRY reply,
>> but since GuC dropped that H2G due to some interim state, we should
>> give it a little time to stabilize. Wait before sending the same H2G
>> again, start with 1ms delay, then increasing it up to 1s.
>>
>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> 
> Should we model the sleep after the wq_wait_for_space algorithm?

while we can change the sleep pattern, this sleep here is not strictly
related to the VF recovery with 100ms expectation, but it is trying to
cover some generic HXG situations, where we don't really know for sure
what was the reason for H2G being dropped; and while as of today GuC
uses RETRY message only during VF being in MID-FLR state, we still 
can't tell how long this will take

> 
> Tomasz change that function here:
> git format-patch -1 a00e305fba02a
> 
> Likewise should we update the CT sleep algorithm too?

if we want to be sure that our reaction time is always < 100ms
then likely yes; but then we might also have to change logic
in xe_mmio_wait32, where we also have simple wait <<= 1

> 
> Matt
> 
>> ---
>>  drivers/gpu/drm/xe/xe_guc.c | 9 +++++++--
>>  1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
>> index 2a3b057fc828..3ba0ea015611 100644
>> --- a/drivers/gpu/drm/xe/xe_guc.c
>> +++ b/drivers/gpu/drm/xe/xe_guc.c
>> @@ -1397,6 +1397,7 @@ int xe_guc_mmio_send_recv(struct xe_guc *guc, const u32 *request,
>>  	struct xe_reg reply_reg = xe_gt_is_media_type(gt) ?
>>  		MED_VF_SW_FLAG(0) : VF_SW_FLAG(0);
>>  	const u32 LAST_INDEX = VF_SW_FLAG_COUNT - 1;
>> +	unsigned int sleep_period_ms = 1;
>>  	bool lost = false;
>>  	u32 header;
>>  	int ret;
>> @@ -1477,8 +1478,12 @@ int xe_guc_mmio_send_recv(struct xe_guc *guc, const u32 *request,
>>  	    GUC_HXG_TYPE_NO_RESPONSE_RETRY) {
>>  		u32 reason = FIELD_GET(GUC_HXG_RETRY_MSG_0_REASON, header);
>>  
>> -		xe_gt_dbg(gt, "GuC mmio request %#x: retrying, reason %#x\n",
>> -			  request[0], reason);
>> +		xe_gt_dbg(gt, "GuC mmio request %#x: retrying after %u ms, reason %#x\n",
>> +			  request[0], sleep_period_ms, reason);
>> +
>> +		msleep(sleep_period_ms);
>> +		if (sleep_period_ms < 1024)
>> +			sleep_period_ms <<= 1;
>>  		goto retry;
>>  	}
>>  
>> -- 
>> 2.47.1
>>


  reply	other threads:[~2026-01-20 21:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 18:50 [PATCH 0/3] drm/xe/guc: Make MMIO communication more robust Michal Wajdeczko
2026-01-20 18:50 ` [PATCH 1/3] drm/xe/guc: Drop redundant register read Michal Wajdeczko
2026-01-20 20:57   ` Matthew Brost
2026-01-20 18:50 ` [PATCH 2/3] drm/xe/guc: Wait before retrying sending H2G Michal Wajdeczko
2026-01-20 21:02   ` Matthew Brost
2026-01-20 21:36     ` Michal Wajdeczko [this message]
2026-01-20 18:50 ` [PATCH 3/3] drm/xe/guc: Allow second H2G retry on FLR Michal Wajdeczko
2026-01-20 19:29 ` ✓ CI.KUnit: success for drm/xe/guc: Make MMIO communication more robust Patchwork
2026-01-20 20:04 ` ✓ Xe.CI.BAT: " Patchwork
2026-01-21  2:42 ` ✗ 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=efaf7eea-987b-44f0-a3f0-1b0c73f2f1ea@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@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