RE: [PATCH v3] drm/amdgpu: bind imported BOs when they are opened

Public

Hi Christian,

I think that's because amdgpu_evf_mgr_init() installs the stub fence, which is permanently signaled, so the validation is skipped at open time - it only runs when the fence is unsignaled, which is not the case until amdgpu_evf_mgr_rearm() installs a real fence.

I've sent a v4 patch where the fix is moved into amdgpu_evf_mgr_attach_fence().

Best Regards,
Yifan

-----Original Message-----
From: Koenig, Christian <[email protected]>
Sent: Thursday, August 13, 2026 6:53 PM
To: Zhang, Yifan <[email protected]>; [email protected]
Cc: Deucher, Alexander <[email protected]>; Yuan, Perry <[email protected]>; Ghosh, Prerona <[email protected]>
Subject: Re: [PATCH v3] drm/amdgpu: bind imported BOs when they are opened



On 8/12/26 09:14, Yifan Zhang wrote:
> From: Prerona Ghosh <[email protected]>
>
> DMA-buf imports are created unbound and land on the VM idle list, so
> neither amdgpu_vm_validate() nor amdgpu_userq_bo_validate() ever binds
> them. Only the BO list of a command submission does, and a VM using
> user queues never runs amdgpu_cs. AMDGPU_GEM_VA then programs PTEs
> from a TTM_PL_SYSTEM resource, i.e. without AMDGPU_PTE_VALID, and the
> first GPU access faults.
>
> Validate imports in amdgpu_gem_object_open() instead, while the BO is
> already reserved by the drm_exec context. Graphics and compute VMs now
> follow the same rule, and a BO that cannot be bound fails the ioctl
> rather than handing out a handle that only maps to faulting PTEs.
>
> v3: validate inside amdgpu_gem_object_open (Christian)
>
> Signed-off-by: Prerona Ghosh <[email protected]>
> Signed-off-by: Yifan Zhang <[email protected]>
> Assisted-by: Claude:claude-opus-5.0
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index f754a4a3a1c2..261218cb57a6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -271,6 +271,20 @@ static int amdgpu_gem_object_open(struct drm_gem_object *obj,
>               ++bo_va->ref_count;
>       }
>
> +     /* Imports are created unbound and land on the VM idle list, so neither
> +      * amdgpu_vm_validate() nor an amdgpu_cs BO list ever binds them for a
> +      * VM that submits through user queues. AMDGPU_GEM_VA would then program
> +      * PTEs from a TTM_PL_SYSTEM resource, i.e. without AMDGPU_PTE_VALID.
> +      */
> +     if (drm_gem_is_imported(obj)) {
> +             struct ttm_operation_ctx ctx = { false, false };
> +
> +             amdgpu_bo_placement_from_domain(abo, abo->allowed_domains);
> +             r = ttm_bo_validate(&abo->tbo, &abo->placement, &ctx);
> +             if (r)
> +                     goto out_unlock;

Taking a look inside amdgpu_evf_mgr_attach_fence() we already have a validation there for the exact same reason:

        if (!dma_fence_is_signaled(ev_fence)) {

                amdgpu_bo_placement_from_domain(bo, bo->allowed_domains);
                ret = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
                if (!ret)
                        dma_resv_add_fence(resv, ev_fence,
                                           DMA_RESV_USAGE_BOOKKEEP);
        } else {
                ret = 0;
        }

So something doesn't seem to work correctly here.

Can you keep investigating why that doesn't seem to work for imported DMA-bufs?

Thanks,
Christian.


> +     }
> +
>       drm_exec_fini(&exec);
>
>       /* Validate and add eviction fence to DMABuf imports with dynamic