Re: [PATCH] drm/xe/guc: Skip CLEANUP message when GuC is stopped

["Gupta, Varun" <varun.gupta@intel.com>]

On 19-Aug-26 6:47 AM, Matthew Brost wrote:
> On Tue, Aug 18, 2026 at 06:09:17PM -0700, Matthew Brost wrote:
>> On Tue, Aug 18, 2026 at 09:37:33AM +0530, Varun Gupta wrote:
>>> Attempting to enqueue a CLEANUP message while the GuC is stopped
>> I think we going in the opposit direction - always send a cleanup
>> message:
>>
>> https://patchwork.freedesktop.org/series/171989/

Thanks for the review, Matt. Yes, after sending this patch, got to know 
about
Nitin's series and it makes sense to go in that direction.

I have tested his series and it also resolves the issue I was debugging.
So this patch is no longer needed.

>>> (during a device reset or suspend) triggers a missing outer runtime
>>> PM protection warning in xe_pm_runtime_get_noresume().
>>>
>> Hmm, do you have stack trace? You shouldn't be possible to get to
>> CLEANUP code without a PM reference.
>>
>> Matt
Here's the trace:

[492170.003812] -----{}{}{}{}{}{}[ cut here ]{}{}{}{}{}{}-----
[492170.003815] pci 0000:63:00.0: [drm] Missing outer runtime PM protection
[492170.003840] WARNING: CPU: 85 PID: 2788391 at 
drivers/gpu/drm/xe/xe_pm.c:773
xe_pm_runtime_get_noresume+0x93/0xc0 [xe]
[492170.003985] RIP: 0010:xe_pm_runtime_get_noresume+0x93/0xc0 [xe]
[492170.004064] Call Trace:
[492170.004064] guc_exec_queue_add_msg+0x26/0xf0 [xe]
[492170.004133] guc_exec_queue_destroy+0x45/0x60 [xe]
[492170.004197] xe_exec_queue_destroy+0x159/0x200 [xe]
[492170.004255] xe_file_close+0xd0/0x1f0 [xe]
[492170.004318] drm_file_free+0x23d/0x2d0
[492170.004321] drm_release_noglobal+0x63/0xd0
[492170.004322] __fput+0xea/0x2d0
[492170.004325] ____fput+0x15/0x20
[492170.004326] task_work_run+0x5f/0xa0
[492170.004329] do_exit+0x1f4/0x460
[492170.004331] do_group_exit+0x2d/0xb0
[492170.004332] __x64_sys_exit_group+0x18/0x20
>>> Since the GuC cannot service Command Transport (CT) requests while
>>> stopped, skip the message and route directly to local teardown.
>>>
>>> Fixes: d930c19fdff3 ("drm/xe: Build PM into GuC CT layer")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Varun Gupta <varun.gupta@intel.com>
>>> ---
>>>   drivers/gpu/drm/xe/xe_guc_submit.c | 6 ++++--
>>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c
>>> index 9036f89dff7d..24f35b0179e1 100644
>>> --- a/drivers/gpu/drm/xe/xe_guc_submit.c
>>> +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
>>> @@ -2180,12 +2180,14 @@ static bool guc_exec_queue_try_add_msg(struct xe_exec_queue *q,
>>>   #define STATIC_MSG_CGP_SYNC	3
>>>   static void guc_exec_queue_destroy(struct xe_exec_queue *q)
>>>   {
>>> +	struct xe_guc *guc = exec_queue_to_guc(q);
>>>   	struct xe_sched_msg *msg = q->guc->static_msgs + STATIC_MSG_CLEANUP;
>>>   
>>> -	if (!(q->flags & EXEC_QUEUE_FLAG_PERMANENT) && !exec_queue_wedged(q))
>>> +	if (!(q->flags & EXEC_QUEUE_FLAG_PERMANENT) && !exec_queue_wedged(q) &&
>>> +	    !xe_guc_read_stopped(guc))
> This would break VF migration too as we do global stop / starts while
> the GuC is still holding a ref to the exec queue and do not both away
> the GuC state.
>
> Matt
Oh, thanks for this, good to know for future references
>>>   		guc_exec_queue_add_msg(q, msg, CLEANUP);
>>>   	else
>>> -		__guc_exec_queue_destroy(exec_queue_to_guc(q), q);
>>> +		__guc_exec_queue_destroy(guc, q);
>>>   }
>>>   
>>>   static int guc_exec_queue_set_priority(struct xe_exec_queue *q,
>>> -- 
>>> 2.43.0
>>>