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. > } > } >
