RE: [PATCH v3 2/2] drm/amdgpu: Add TLB flush after MES user queue unmap

AMD General

Hi all,

Thanks for the feedback and for testing this during suspend — since it doesn't resolve the TLB invalidation issue there either, this clearly needs deeper analysis. For now, I'll pick patch 1 (the KFD-related fix) only and drop patch 2 (this amdgpu_userq.c TLB flush).

Thanks,
Priya

-----Original Message-----
From: Khatri, Sunil <[email protected]>
Sent: Tuesday, August 25, 2026 12:17 PM
To: Koenig, Christian <[email protected]>; Hosur, Priya <[email protected]>; [email protected]; Deucher, Alexander <[email protected]>; Kuehling, Felix <[email protected]>; Liu, Shaoyun <[email protected]>; Lazar, Lijo <[email protected]>; Limonciello, Mario <[email protected]>
Cc: Vishwakarma, Pratik <[email protected]>; Gopalakrishnan, Veerabadhran (Veera) <[email protected]>
Subject: RE: [PATCH v3 2/2] drm/amdgpu: Add TLB flush after MES user queue unmap

AMD General

-----Original Message-----
From: Koenig, Christian <[email protected]>
Sent: Monday, August 24, 2026 1:09 PM
To: Hosur, Priya <[email protected]>; [email protected]; Deucher, Alexander <[email protected]>; Khatri, Sunil <[email protected]>; Kuehling, Felix <[email protected]>; Liu, Shaoyun <[email protected]>; Lazar, Lijo <[email protected]>; Limonciello, Mario <[email protected]>
Cc: Vishwakarma, Pratik <[email protected]>; Gopalakrishnan, Veerabadhran (Veera) <[email protected]>
Subject: Re: [PATCH v3 2/2] drm/amdgpu: Add TLB flush after MES user queue unmap

On 8/14/26 18:18, Priya Hosur wrote:
> Similar to the KFD fix, MES does not perform heavy-weight TLB
> invalidation after unmapping user queues. Add
> amdgpu_gmc_flush_gpu_tlb_pasid() after MES unmap succeeds in
> amdgpu_userq_unmap_helper() to ensure in-flight memory accesses
> complete before memory is freed or migrated.
>
> Change-Id: I94fe2c84547723b6b73816ce8d727a54bd773a6a
> Signed-off-by: Priya Hosur <[email protected]>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 6d3ed55e9ab4..9fcf15d69b7b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -375,6 +375,12 @@ static int amdgpu_userq_unmap_helper(struct amdgpu_usermode_queue *queue)
>               } else {
>                       trace_amdgpu_userq_state_changed(queue, AMDGPU_USERQ_STATE_UNMAPPED);
>                       queue->state = AMDGPU_USERQ_STATE_UNMAPPED;
> +                     /*
> +                      * Heavy-weight TLB flush after MES unmaps queue to ensure
> +                      * in-flight memory accesses complete before memory is freed/migrated.
> +                      * MES does not do this automatically unlike HWS.
> +                      */
> +                     amdgpu_gmc_flush_gpu_tlb_pasid(adev,
> +queue->vm->pasid, 2, true, 0);

Absolutely clear NAK to this.

The MES *must* guarantee that in flight memory accesses are completed before it unmaps the queue or otherwise we run into massive problems.

Flushing out any VM changes by invalidating the TLB doesn't change anything on that.

I tried this change during suspend but it dint help the case of tlb invalidation issues that we are facing.

regards
Sunil Khatri

Regards,
Christian.

>               }
>       }
>