Intel-XE Archive on lore.kernel.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/2] drm/xe/guc: Fix arguments passed to relay G2H handlers
Date: Thu, 11 Jan 2024 22:00:00 +0100	[thread overview]
Message-ID: <dbca358f-5cc9-46db-83d7-a813ad14d52c@intel.com> (raw)
In-Reply-To: <ZaBKptKN6xjIZ+ah@DUT025-TGLU.fm.intel.com>



On 11.01.2024 21:08, Matthew Brost wrote:
> On Thu, Jan 11, 2024 at 10:37:31AM +0100, Michal Wajdeczko wrote:
>>
>>
>> On 11.01.2024 00:07, Matthew Brost wrote:
>>> On Wed, Jan 10, 2024 at 08:59:51PM +0100, Michal Wajdeczko wrote:
>>>> By default CT code was passing just payload of the G2H event
>>>> message, while Relay code expects full G2H message including
>>>> HXG header which contains DATA0 field. Fix that.
>>>>
>>>> Fixes: 152577060697 ("drm/xe/guc: Start handling GuC Relay event messages")
>>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>>
>>> FWIW I do think the argument names in xe_guc_relay_process_* functions
>>> should be changed but not going to hold of this fix.
>>
>> I can rename message argument in relay g2h handlers to "hxg", but what
>> about the other g2h handlers, which (IMO wrongly) take just payload, not
>> a message, while still use "msg" as an argument name:
>>
>> int xe_guc_sched_done_handler(... u32 *msg, u32 len)
>> int xe_guc_deregister_done_handler(... u32 *msg, u32 len)
>> int xe_guc_exec_queue_reset_handler(... u32 *msg, u32 len)
>> int xe_guc_exec_queue_memory_cat_error_handler(... u32 *msg, u32 len)
>> int xe_guc_exec_queue_reset_failure_handler(... u32 *msg, u32 len)
>> int xe_guc_pagefault_handler(... u32 *msg, u32 len)
>> int xe_guc_tlb_invalidation_done_handler(... u32 *msg, u32 len)
>> int xe_guc_access_counter_notify_handler(... u32 *msg, u32 len)
>>
> 
> Good point I'd say lets clean all of this up.
> 
> msg -> entire G2H
> hxg -> HXG + payload
> payload -> payload

but maybe we can limit this notation only to CT code as only there this
different naming is needed - all CT users will be using just one kind of
the message and it will be HXG message (with payload) by design

also actual actions definitions [1] [2] don't use HXG tag while
describing full action/response message fields, while there is MSG tag

so IMO using "msg" in G2H handlers (code outside CT) seems to be fine

[1]
https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/abi/guc_actions_abi.h?ref_type=heads
[2]
https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/abi/guc_actions_sriov_abi.h?ref_type=heads

> 
> Ok with a follow up. We can chat off the list with who will post.

as stated above passing just payload to G2H handlers seems wrong as then
data0 is never passed on (well, it's MBZ for most actions now, but we
don't even check if this is the case and are unable to react if not)

so sooner or later, that "msg" which currently means "payload" will mean
"full hxg" - the only kind message of message used beyond CT layer - and
the "payload only" concept will fully disappear - so I'm not sure that
just renaming functions arguments and hide the problem is a way to go

> 
> Matt
> 
>>>
>>> With that:
>>> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
>>>
>>>> ---
>>>>  drivers/gpu/drm/xe/xe_guc_ct.c | 4 ++--
>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
>>>> index d6b7020a2d2f..4a0c9ce13bf8 100644
>>>> --- a/drivers/gpu/drm/xe/xe_guc_ct.c
>>>> +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
>>>> @@ -984,10 +984,10 @@ static int process_g2h_msg(struct xe_guc_ct *ct, u32 *msg, u32 len)
>>>>  							   adj_len);
>>>>  		break;
>>>>  	case XE_GUC_ACTION_GUC2PF_RELAY_FROM_VF:
>>>> -		ret = xe_guc_relay_process_guc2pf(&guc->relay, payload, adj_len);
>>>> +		ret = xe_guc_relay_process_guc2pf(&guc->relay, hxg, hxg_len);
>>>>  		break;
>>>>  	case XE_GUC_ACTION_GUC2VF_RELAY_FROM_PF:
>>>> -		ret = xe_guc_relay_process_guc2vf(&guc->relay, payload, adj_len);
>>>> +		ret = xe_guc_relay_process_guc2vf(&guc->relay, hxg, hxg_len);
>>>>  		break;
>>>>  	default:
>>>>  		drm_err(&xe->drm, "unexpected action 0x%04x\n", action);
>>>> -- 
>>>> 2.25.1
>>>>

  reply	other threads:[~2024-01-11 21:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-10 19:59 [PATCH 1/2] drm/xe/guc: Use HXG definitions on HXG messages Michal Wajdeczko
2024-01-10 19:59 ` [PATCH 2/2] drm/xe/guc: Fix arguments passed to relay G2H handlers Michal Wajdeczko
2024-01-10 23:07   ` Matthew Brost
2024-01-11  9:37     ` Michal Wajdeczko
2024-01-11 20:08       ` Matthew Brost
2024-01-11 21:00         ` Michal Wajdeczko [this message]
2024-01-10 23:06 ` [PATCH 1/2] drm/xe/guc: Use HXG definitions on HXG messages Matthew Brost
2024-01-11  9:44   ` Michal Wajdeczko
2024-01-11  1:01 ` ✓ CI.Patch_applied: success for series starting with [1/2] " Patchwork
2024-01-11  1:02 ` ✗ CI.checkpatch: warning " Patchwork
2024-01-11  1:02 ` ✓ CI.KUnit: success " Patchwork
2024-01-11  1:10 ` ✓ CI.Build: " Patchwork
2024-01-11  1:10 ` ✓ CI.Hooks: " Patchwork
2024-01-11  1:12 ` ✓ CI.checksparse: " Patchwork
2024-01-11  1:48 ` ✓ CI.BAT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2024-01-09 23:00 [PATCH 1/2] drm/xe/guc: Use proper definitions while processing G2H events Michal Wajdeczko
2024-01-09 23:00 ` [PATCH 2/2] drm/xe/guc: Fix arguments passed to relay G2H handlers Michal Wajdeczko
2024-01-10  0:47   ` Matthew Brost
2024-01-10 17:55     ` Michal Wajdeczko

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=dbca358f-5cc9-46db-83d7-a813ad14d52c@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