On 9/16/26 05:38, Liang, Prike wrote:
> AMD General
>
> Regards,
> Prike
>
>> -----Original Message-----
>> From: Koenig, Christian <[email protected]>
>> Sent: Tuesday, September 15, 2026 10:03 PM
>> To: Liang, Prike <[email protected]>; [email protected]
>> Cc: Deucher, Alexander <[email protected]>; Pelloux-Prayer, Pierre-
>> Eric <[email protected]>
>> Subject: Re: [PATCH v2 5/5] drm/amdgpu: mark queue and process as guilty for
>> hung user queue
>>
>> On 9/15/26 09:19, Prike Liang wrote:
>> ...
>>> @@ -132,7 +134,8 @@ struct amdgpu_userq_mgr {
>>> struct drm_file *file;
>>> struct mutex proc_ctx_lock;
>>> struct amdgpu_userq_obj proc_ctx_obj;
>>> -
>>> + /* Set when any queue owned by this process is reset guilty */
>>> + bool guilty;
>>> bool proc_ctx_allocated;
>>> uint32_t proc_ctx_array_index;
>>> /**
>>
>> Again, clear NAK to having a flag in the queue manager as well.
>>
>> We should not track that here, especially since there is no way to reset it
>> as far as I
>> can see.
>
> The userq_mgr->guilty was originally added to track VRAM-lost resets through
> amdgpu_ctx_query2() so userspace could reuse its
> EGL_EXT_create_context_robustness handling.
Hui? I don't understand what you mean.
amdgpu_ctx_query2() does the VRAM lost tracking through a VM generation check.
See this line here:
if (ctx->generation != amdgpu_vm_generation(adev, &fpriv->vm))
out->state.flags |= AMDGPU_CTX_QUERY2_FLAGS_VRAMLOST;
Why would we need an userq guilty flag for that?
Regards,
Christian.
> If userspace switches to querying user queue status via
> amdgpu_userq_query_status(), we can drop userq_mgr->guilty and rely directly
> on AMDGPU_USERQ_QUERY_STATUS_FLAGS_VRAMLOST for identifying the case of userq
> vram lost.
>
> Thanks,
> Prike
>
>> Regards,
>> Christian.
