AMD General
Regards,
Prike
> -----Original Message-----
> From: Koenig, Christian <[email protected]>
> Sent: Wednesday, September 16, 2026 9:56 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/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?
When a user queue (userq) reset fails and falls back to a full device reset,
userspace needs to detect the invalid/dead queue state in order to recreate it.
Currently, userspace drivers (e.g., Mesa) can query reset status through either
amdgpu_ctx_query2() or amdgpu_userq_query_status(). However, amdgpu_ctx is not
directly involved in userq lifecycle management, and Mesa plans to decouple
legacy context dependencies from user queue handling.
To support standalone userq workflows, I plan to extend
amdgpu_userq_query_status() to report detailed reset status flags (analogous to
amdgpu_ctx_query2()), enabling userspace to identify reset fallout (e.g.,
guilty/innocent/unknown reset) and initiate queue recovery without relying on
amdgpu_ctx.
Thanks,
Prike
>
> 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.
