Regardless of SDMA userq support, this patch still looks reasonable to
me. The TLB fence doesn't make sense for NPA VMs. We handle TLB flushes
for NPA page table updates explicitly in the amdgpu_ualink code.
Feel free to submit this patch with
Reviewed-by: Felix Kuehling <[email protected]>
On 2026-09-20 10:41, Zhang, Hawking wrote:
AMD General
Hi @Zhang, Horatio <mailto:[email protected]>,
I think the issue is caused by the following code in
sdma_v7_1_sw_init, which incorrectly marks amdgpu user queues as
enabled for SDMA 7.1 as long as the CONFIG_DRM_AMDGPU_NAVI3X_USERQ is
enabled.
Since SDMA 7.1 does not amdgpu user queues (it only supports rocm user
queues), could you please remove this code and check whether the issue
still occurs?
#ifdef CONFIG_DRM_AMDGPU_NAVI3X_USERQ
adev->userq_funcs[AMDGPU_HW_IP_DMA] = &userq_mes_funcs;
#endif
Regards,
Hawking
-----Original Message-----
From: Zhang, Horatio <[email protected]>
Sent: Sunday, September 20, 2026 5:47 AM
To: [email protected]
Cc: Zhang, Hawking <[email protected]>; Ma, Le <[email protected]>;
Kuehling, Felix <[email protected]>; Joshi, Mukul
<[email protected]>; Deucher, Alexander <[email protected]>
Subject: RE: [PATCH] drm/amdgpu: skip the PASID TLB fence for the
UALink NPA VM
AMD General
Gentle Ping ...
Best regards,
Horatio
-----Original Message-----
From: Horatio Zhang <[email protected]>
Sent: Thursday, September 17, 2026 6:05 PM
To: [email protected]
Cc: Zhang, Hawking <[email protected]>; Ma, Le <[email protected]>;
Zhang, Horatio <[email protected]>
Subject: [PATCH] drm/amdgpu: skip the PASID TLB fence for the UALink
NPA VM
amdgpu_vm_make_npa() builds the UALink NPA VM on top of
amdgpu_vm_make_compute(), which unconditionally sets need_tlb_fence.
That flag makes amdgpu_vm_tlb_flush() queue an asynchronous PASID
based TLB invalidation after every page table update.
The NPA VM is created by the driver itself in
amdgpu_ualink_manager_start() and never gets a PASID assigned, so
vm->pasid stays 0, which MES cannot resolve on the MMHUB. The
vm->invalidation
never completes and MES stays unresponsive for the rest of the probe:
amdgpu: MES(0, 0) failed to respond to msg=INVALIDATE_TLBS
The invalidation is not needed in the first place. An NPA VM is bound
to the reserved NPA VMID and amdgpu_ualink_flush_tlb() already
invalidates that VMID on the MMHUB after every mapping change. Clear
need_tlb_fence for NPA VMs.
Fixes: aac13f6eded6 ("drm/amdgpu: Pin page tables in NPA VMs")
Signed-off-by: Horatio Zhang <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 68d668dfe4f8..e255b5100362 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2793,6 +2793,7 @@ int amdgpu_vm_make_npa(struct amdgpu_device
*adev, struct amdgpu_vm *vm)
return r;
vm->is_npa = true;
+ vm->need_tlb_fence = false;
return 0;
}
--
2.43.0
