Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

8 participants
3221 discussions

Re: [PATCH v7 00/11] vfio/pci: Allow MMIO regions to be exported through dma-buf

by Jason Gunthorpe

On Mon, Nov 17, 2025 at 08:36:20AM -0700, Alex Williamson wrote: > On Tue, 11 Nov 2025 09:54:22 +0100 > Christian König <christian.koenig(a)amd.com> wrote: > > > On 11/10/25 21:42, Alex Williamson wrote: > > > On Thu, 6 Nov 2025 16:16:45 +0200 > > > Leon Romanovsky <leon(a)kernel.org> wrote: > > > > > >> Changelog: > > >> v7: > > >> * Dropped restore_revoke flag and added vfio_pci_dma_buf_move > > >> to reverse loop. > > >> * Fixed spelling errors in documentation patch. > > >> * Rebased on top of v6.18-rc3. > > >> * Added include to stddef.h to vfio.h, to keep uapi header file independent. > > > > > > I think we're winding down on review comments. It'd be great to get > > > p2pdma and dma-buf acks on this series. Otherwise it's been posted > > > enough that we'll assume no objections. Thanks, > > > > Already have it on my TODO list to take a closer look, but no idea when that will be. > > > > This patch set is on place 4 or 5 on a rather long list of stuff to review/finish. > > Hi Christian, > > Gentle nudge. Leon posted v8[1] last week, which is not drawing any > new comments. Do you foresee having time for review that I should > still hold off merging for v6.19 a bit longer? Thanks, I really want this merged this cycle, along with the iommufd part, which means it needs to go into your tree by very early next week on a shared branch so I can do the iommufd part on top. It is the last blocking kernel piece to conclude the viommu support roll out into qemu for iommufd which quite a lot of people have been working on for years now. IMHO there is nothing profound in the dmabuf patch, it was written by the expert in the new DMA API operation, and doesn't form any troublesome API contracts. It is also the same basic code as from the v1 in July just moved into dmabuf .c files instead of vfio .c files at Christoph's request. My hope is DRM folks will pick up the baton and continue to improve this to move other drivers away from dma_map_resource(). Simona told me people have wanted DMA API improvements for ages, now we have them, now is the time! Any remarks after the fact can be addressed incrementally. If there are no concrete technical remarks please take it. 6 months is long enough to wait for feedback. Thanks, Jason

2 weeks, 3 days

Re: [PATCH v8 11/11] vfio/nvgrace: Support get_dmabuf_phys

by Jason Gunthorpe

On Tue, Nov 18, 2025 at 07:59:20AM +0000, Ankit Agrawal wrote: > + if (nvdev->resmem.memlength && region_index == RESMEM_REGION_INDEX) { > + /* > + * The P2P properties of the non-BAR memory is the same as the > + * BAR memory, so just use the provider for index 0. Someday > + * when CXL gets P2P support we could create CXLish providers > + * for the non-BAR memory. > + */ > + mem_region = &nvdev->resmem; > + } else if (region_index == USEMEM_REGION_INDEX) { > + /* > + * This is actually cachable memory and isn't treated as P2P in > + * the chip. For now we have no way to push cachable memory > + * through everything and the Grace HW doesn't care what caching > + * attribute is programmed into the SMMU. So use BAR 0. > + */ > + mem_region = &nvdev->usemem; > + } > + > > Can we replace this with nvgrace_gpu_memregion()? Yes, looks like But we need to preserve the comments above as well somehow. Jason

2 weeks, 3 days

Re: [PATCH 02/18] dma-buf: protected fence ops by RCU v3

by Christian König

On 11/14/25 11:50, Tvrtko Ursulin wrote: >> @@ -569,12 +577,12 @@ void dma_fence_release(struct kref *kref) >> spin_unlock_irqrestore(fence->lock, flags); >> } >> - rcu_read_unlock(); >> - >> - if (fence->ops->release) >> - fence->ops->release(fence); >> + ops = rcu_dereference(fence->ops); >> + if (ops->release) >> + ops->release(fence); >> else >> dma_fence_free(fence); >> + rcu_read_unlock(); > > Risk being a spin lock in the release callback will trigger a warning on PREEMPT_RT. But at least the current code base does not have anything like that AFAICS so I guess it is okay. I don't think that this is a problem. When PREEMPT_RT is enabled both RCU and spinlocks become preemptible. So as far as I know it is perfectly valid to grab a spinlock under an rcu read side critical section. >> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h >> index 64639e104110..77f07735f556 100644 >> --- a/include/linux/dma-fence.h >> +++ b/include/linux/dma-fence.h >> @@ -66,7 +66,7 @@ struct seq_file; >> */ >> struct dma_fence { >> spinlock_t *lock; >> - const struct dma_fence_ops *ops; >> + const struct dma_fence_ops __rcu *ops; >> /* >> * We clear the callback list on kref_put so that by the time we >> * release the fence it is unused. No one should be adding to the >> @@ -218,6 +218,10 @@ struct dma_fence_ops { >> * timed out. Can also return other error values on custom implementations, >> * which should be treated as if the fence is signaled. For example a hardware >> * lockup could be reported like that. >> + * >> + * Implementing this callback prevents the BO from detaching after > > s/BO/fence/ > >> + * signaling and so it is mandatory for the module providing the >> + * dma_fence_ops to stay loaded as long as the dma_fence exists. >> */ >> signed long (*wait)(struct dma_fence *fence, >> bool intr, signed long timeout); >> @@ -229,6 +233,13 @@ struct dma_fence_ops { >> * Can be called from irq context. This callback is optional. If it is >> * NULL, then dma_fence_free() is instead called as the default >> * implementation. >> + * >> + * Implementing this callback prevents the BO from detaching after > > Ditto. Both fixed, thanks. > >> + * signaling and so it is mandatory for the module providing the >> + * dma_fence_ops to stay loaded as long as the dma_fence exists. >> + * >> + * If the callback is implemented the memory backing the dma_fence >> + * object must be freed RCU safe. >> */ >> void (*release)(struct dma_fence *fence); >> @@ -418,13 +429,19 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence); >> static inline bool >> dma_fence_is_signaled_locked(struct dma_fence *fence) >> { >> + const struct dma_fence_ops *ops; >> + >> if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) >> return true; >> - if (fence->ops->signaled && fence->ops->signaled(fence)) { >> + rcu_read_lock(); >> + ops = rcu_dereference(fence->ops); >> + if (ops->signaled && ops->signaled(fence)) { >> + rcu_read_unlock(); >> dma_fence_signal_locked(fence); >> return true; >> } >> + rcu_read_unlock(); >> return false; >> } >> @@ -448,13 +465,19 @@ dma_fence_is_signaled_locked(struct dma_fence *fence) >> static inline bool >> dma_fence_is_signaled(struct dma_fence *fence) >> { >> + const struct dma_fence_ops *ops; >> + >> if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) >> return true; >> - if (fence->ops->signaled && fence->ops->signaled(fence)) { >> + rcu_read_lock(); >> + ops = rcu_dereference(fence->ops); >> + if (ops->signaled && ops->signaled(fence)) { >> + rcu_read_unlock(); > > With the unlocked version two threads could race and one could make the fence->lock go away just around here, before the dma_fence_signal below will take it. It seems it is only safe to rcu_read_unlock before signaling if using the embedded fence (later in the series). Can you think of a downside to holding the rcu read lock to after signaling? that would make it safe I think. Well it's good to talk about it but I think that it is not necessary to protect the lock in this particular case. See the RCU protection is only for the fence->ops pointer, but the lock can be taken way after the fence is already signaled. That's why I came up with the patch to move the lock into the fence in the first place. Regards, Christian. > > Regards, > > Tvrtko > >> dma_fence_signal(fence); >> return true; >> } >> + rcu_read_unlock(); >> return false; >> } >

2 weeks, 3 days

Re: [PATCH v8 10/11] vfio/pci: Add dma-buf export support for MMIO regions

by Jason Gunthorpe

On Tue, Nov 18, 2025 at 07:33:23AM +0000, Tian, Kevin wrote: > > From: Leon Romanovsky <leon(a)kernel.org> > > Sent: Tuesday, November 11, 2025 5:58 PM > > > > - if (!new_mem) > > + if (!new_mem) { > > vfio_pci_zap_and_down_write_memory_lock(vdev); > > - else > > + vfio_pci_dma_buf_move(vdev, true); > > + } else { > > down_write(&vdev->memory_lock); > > + } > > shouldn't we notify move before zapping the bars? otherwise there is > still a small window in between where the exporter already has the > mapping cleared while the importer still keeps it... zapping the VMA and moving/revoking the DMABUF are independent operations that can happen in any order. They effect different kinds of users. The VMA zap prevents CPU access from userspace, the DMABUF move prevents DMA access from devices. The order has to be like the above because vfio_pci_dma_buf_move() must be called under the memory lock and vfio_pci_zap_and_down_write_memory_lock() gets the memory lock.. > > +static void vfio_pci_dma_buf_release(struct dma_buf *dmabuf) > > +{ > > + struct vfio_pci_dma_buf *priv = dmabuf->priv; > > + > > + /* > > + * Either this or vfio_pci_dma_buf_cleanup() will remove from the list. > > + * The refcount prevents both. > > which refcount? I thought it's vdev->memory_lock preventing the race... Refcount on the dmabuf > > +int vfio_pci_core_fill_phys_vec(struct dma_buf_phys_vec *phys_vec, > > + struct vfio_region_dma_range *dma_ranges, > > + size_t nr_ranges, phys_addr_t start, > > + phys_addr_t len) > > +{ > > + phys_addr_t max_addr; > > + unsigned int i; > > + > > + max_addr = start + len; > > + for (i = 0; i < nr_ranges; i++) { > > + phys_addr_t end; > > + > > + if (!dma_ranges[i].length) > > + return -EINVAL; > > Looks redundant as there is already a check in validate_dmabuf_input(). Agree > > +int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 > > flags, > > + struct vfio_device_feature_dma_buf __user > > *arg, > > + size_t argsz) > > +{ > > + struct vfio_device_feature_dma_buf get_dma_buf = {}; > > + struct vfio_region_dma_range *dma_ranges; > > + DEFINE_DMA_BUF_EXPORT_INFO(exp_info); > > + struct vfio_pci_dma_buf *priv; > > + size_t length; > > + int ret; > > + > > + if (!vdev->pci_ops || !vdev->pci_ops->get_dmabuf_phys) > > + return -EOPNOTSUPP; > > + > > + ret = vfio_check_feature(flags, argsz, VFIO_DEVICE_FEATURE_GET, > > + sizeof(get_dma_buf)); > > + if (ret != 1) > > + return ret; > > + > > + if (copy_from_user(&get_dma_buf, arg, sizeof(get_dma_buf))) > > + return -EFAULT; > > + > > + if (!get_dma_buf.nr_ranges || get_dma_buf.flags) > > + return -EINVAL; > > unknown flag bits get -EOPNOTSUPP. Agree > > + > > +void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev) > > +{ > > + struct vfio_pci_dma_buf *priv; > > + struct vfio_pci_dma_buf *tmp; > > + > > + down_write(&vdev->memory_lock); > > + list_for_each_entry_safe(priv, tmp, &vdev->dmabufs, dmabufs_elm) > > { > > + if (!get_file_active(&priv->dmabuf->file)) > > + continue; > > + > > + dma_resv_lock(priv->dmabuf->resv, NULL); > > + list_del_init(&priv->dmabufs_elm); > > + priv->vdev = NULL; > > + priv->revoked = true; > > + dma_buf_move_notify(priv->dmabuf); > > + dma_resv_unlock(priv->dmabuf->resv); > > + vfio_device_put_registration(&vdev->vdev); > > + fput(priv->dmabuf->file); > > dma_buf_put(priv->dmabuf), consistent with other places. Someone else said this, I don't agree, the above got the get via get_file_active() instead of a dma_buf version.. So we should pair with get_file_active() vs fput(). Christian rejected the idea of adding a dmabuf wrapper for get_file_active(), oh well. > > +struct vfio_device_feature_dma_buf { > > + __u32 region_index; > > + __u32 open_flags; > > + __u32 flags; > > Usually the 'flags' field is put in the start (following argsz if existing). Yeah, but doesn't really matter. Thanks, Jason

2 weeks, 3 days

Re: [PATCH 0/9] Initial DMABUF support for iommufd

by Jason Gunthorpe

On Thu, Nov 13, 2025 at 11:37:12AM -0700, Alex Williamson wrote: > > The latest series for interconnect negotation to exchange a phys_addr is: > > https://lore.kernel.org/r/20251027044712.1676175-1-vivek.kasireddy@intel.com > > If this is in development, why are we pursuing a vfio specific > temporary "private interconnect" here rather than building on that > work? What are the gaps/barriers/timeline? I broadly don't expect to see an agreement on the above for probably half a year, and I see no reason to hold this up for it. Many people are asking for this P2P support to be completed in iommufd. Further, I think the above will be easier to work on when we have this merged as an example that can consume it in a different way. Right now it is too theoretical, IMHO. > I don't see any uAPI changes here, is there any visibility to userspace > whether IOMMUFD supports this feature or is it simply a try and fail > approach? So far we haven't done discoverably things beyond try and fail. I'd be happy if the userspace folks doing libvirt or whatever came with some requests/patches for discoverability. It is not just this feature, but things like nesting and IOMMU driver support and so on. > The latter makes it difficult for management tools to select > whether to choose a VM configuration based on IOMMUFD or legacy vfio if > p2p DMA is a requirement. Thanks, In alot of cases it isn't really a choice as you need iommufd to do an accelerated vIOMMU. But yes, it would be nice to eventually automatically use iommufd whenever possible. Thanks, Jason

2 weeks, 4 days

Re: [PATCH 08/18] drm/sched: use inline locks for the drm-sched-fence

by Christian König

On 11/13/25 17:23, Philipp Stanner wrote: > On Thu, 2025-11-13 at 15:51 +0100, Christian König wrote: >> Using the inline lock is now the recommended way for dma_fence implementations. >> >> So use this approach for the scheduler fences as well just in case if >> anybody uses this as blueprint for its own implementation. >> >> Also saves about 4 bytes for the external spinlock. > > So you changed your mind and want to keep this patch? Actually it was you who changed my mind. When we want to document that using the internal lock is now the norm and all implementations should switch to that if possible we should push as much as possible for using this in the driver common code as well. Regards, Christian. > > P. >

2 weeks, 4 days

Re: Independence for dma_fences! v3

by Christian König

On 11/13/25 17:20, Philipp Stanner wrote: > On Thu, 2025-11-13 at 15:51 +0100, Christian König wrote: >> Hi everyone, >> >> dma_fences have ever lived under the tyranny dictated by the module >> lifetime of their issuer, leading to crashes should anybody still holding >> a reference to a dma_fence when the module of the issuer was unloaded. >> >> The basic problem is that when buffer are shared between drivers >> dma_fence objects can leak into external drivers and stay there even >> after they are signaled. The dma_resv object for example only lazy releases >> dma_fences. >> >> So what happens is that when the module who originally created the dma_fence >> unloads the dma_fence_ops function table becomes unavailable as well and so >> any attempt to release the fence crashes the system. >> >> Previously various approaches have been discussed, including changing the >> locking semantics of the dma_fence callbacks (by me) as well as using the >> drm scheduler as intermediate layer (by Sima) to disconnect dma_fences >> from their actual users, but none of them are actually solving all problems. >> >> Tvrtko did some really nice prerequisite work by protecting the returned >> strings of the dma_fence_ops by RCU. This way dma_fence creators where >> able to just wait for an RCU grace period after fence signaling before >> they could be save to free those data structures. >> >> Now this patch set here goes a step further and protects the whole >> dma_fence_ops structure by RCU, so that after the fence signals the >> pointer to the dma_fence_ops is set to NULL when there is no wait nor >> release callback given. All functionality which use the dma_fence_ops >> reference are put inside an RCU critical section, except for the >> deprecated issuer specific wait and of course the optional release >> callback. >> >> Additional to the RCU changes the lock protecting the dma_fence state >> previously had to be allocated external. This set here now changes the >> functionality to make that external lock optional and allows dma_fences >> to use an inline lock and be self contained. >> >> This patch set addressed all previous code review comments and is based >> on drm-tip, includes my changes for amdgpu as well as Mathew's patches for XE. >> >> Going to push the core DMA-buf changes to drm-misc-next as soon as I get >> the appropriate rb. The driver specific changes can go upstream through >> the driver channels as necessary. > > No changelog? :( On the cover letter? For dma-buf patches we usually do that on the individual patches. Christian. > > P. > >> >> Please review and comment, >> Christian. >> >> >

2 weeks, 4 days

Re: [PATCH v2 18/20] drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_ttm_clear_buffer

by Christian König

On 11/13/25 17:05, Pierre-Eric Pelloux-Prayer wrote: > This is the only use case for this function. > > --- > v2: amdgpu_ttm_clear_buffer instead of amdgpu_clear_buffer > --- > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +++---- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 26 ++++++++++------------ > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 15 ++++++------- > 3 files changed, 23 insertions(+), 26 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index 4490b19752b8..4b9518097899 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -725,8 +725,8 @@ int amdgpu_bo_create(struct amdgpu_device *adev, > bo->tbo.resource->mem_type == TTM_PL_VRAM) { > struct dma_fence *fence; > > - r = amdgpu_fill_buffer(NULL, bo, 0, NULL, &fence, NULL, > - true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > + r = amdgpu_ttm_clear_buffer(NULL, bo, NULL, &fence, NULL, > + true, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > if (unlikely(r)) > goto fail_unreserve; > > @@ -1324,8 +1324,8 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) > if (r) > goto out; > > - r = amdgpu_fill_buffer(NULL, abo, 0, &bo->base._resv, &fence, NULL, > - false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); > + r = amdgpu_ttm_clear_buffer(NULL, abo, &bo->base._resv, &fence, NULL, > + false, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); > if (WARN_ON(r)) > goto out; > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index df05768c3817..0a55bc4ea91f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -433,9 +433,9 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, > (abo->flags & AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE)) { > struct dma_fence *wipe_fence = NULL; > > - r = amdgpu_fill_buffer(entity, > - abo, 0, NULL, &wipe_fence, fence, > - false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); > + r = amdgpu_ttm_clear_buffer(entity, > + abo, NULL, &wipe_fence, fence, > + false, AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); > if (r) { > goto error; > } else if (wipe_fence) { > @@ -2418,11 +2418,10 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_ring *ring, > } > > /** > - * amdgpu_fill_buffer - fill a buffer with a given value > + * amdgpu_ttm_clear_buffer - fill a buffer with 0 > * @entity: optional entity to use. If NULL, the clearing entities will be > * used to load-balance the partial clears > * @bo: the bo to fill > - * @src_data: the value to set > * @resv: fences contained in this reservation will be used as dependencies. > * @out_fence: the fence from the last clear will be stored here. It might be > * NULL if no job was run. > @@ -2432,14 +2431,13 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_ring *ring, > * @k_job_id: trace id > * > */ > -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > - struct amdgpu_bo *bo, > - uint32_t src_data, > - struct dma_resv *resv, > - struct dma_fence **out_fence, > - struct dma_fence *dependency, > - bool consider_clear_status, > - u64 k_job_id) > +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, > + struct amdgpu_bo *bo, > + struct dma_resv *resv, > + struct dma_fence **out_fence, > + struct dma_fence *dependency, > + bool consider_clear_status, > + u64 k_job_id) > { > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > struct dma_fence *fence = NULL; > @@ -2486,7 +2484,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > goto error; > > r = amdgpu_ttm_fill_mem(ring, &entity->base, > - src_data, to, cur_size, resv, > + 0, to, cur_size, resv, > &next, true, k_job_id); > if (r) > goto error; > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > index e01c2173d79f..585aee9a173b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -181,14 +181,13 @@ int amdgpu_copy_buffer(struct amdgpu_ring *ring, > struct dma_resv *resv, > struct dma_fence **fence, > bool vm_needs_flush, uint32_t copy_flags); > -int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > - struct amdgpu_bo *bo, > - uint32_t src_data, > - struct dma_resv *resv, > - struct dma_fence **out_fence, > - struct dma_fence *dependency, > - bool consider_clear_status, > - u64 k_job_id); > +int amdgpu_ttm_clear_buffer(struct amdgpu_ttm_buffer_entity *entity, > + struct amdgpu_bo *bo, > + struct dma_resv *resv, > + struct dma_fence **out_fence, > + struct dma_fence *dependency, > + bool consider_clear_status, > + u64 k_job_id); > > int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); > void amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo);

2 weeks, 4 days

Re: [PATCH v2 10/20] drm/admgpu: handle resv dependencies in amdgpu_ttm_map_buffer

by Christian König

On 11/13/25 17:05, Pierre-Eric Pelloux-Prayer wrote: > If a resv object is passed, its fences are treated as a dependency > for the amdgpu_ttm_map_buffer operation. > > This will be used by amdgpu_bo_release_notify through > amdgpu_fill_buffer. Why should updating the GART window depend on fences in a resv object? Regards, Christian. > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 16 +++++++++++----- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index b13f0993dbf1..411997db70eb 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -184,7 +184,8 @@ static int amdgpu_ttm_map_buffer(struct drm_sched_entity *entity, > struct amdgpu_res_cursor *mm_cur, > unsigned int window, struct amdgpu_ring *ring, > bool tmz, uint64_t *size, uint64_t *addr, > - struct dma_fence *dep) > + struct dma_fence *dep, > + struct dma_resv *resv) > { > struct amdgpu_device *adev = ring->adev; > unsigned int offset, num_pages, num_dw, num_bytes; > @@ -239,6 +240,10 @@ static int amdgpu_ttm_map_buffer(struct drm_sched_entity *entity, > if (dep) > drm_sched_job_add_dependency(&job->base, dma_fence_get(dep)); > > + if (resv) > + drm_sched_job_add_resv_dependencies(&job->base, resv, > + DMA_RESV_USAGE_BOOKKEEP); > + > src_addr = num_dw * 4; > src_addr += job->ibs[0].gpu_addr; > > @@ -332,14 +337,14 @@ static int amdgpu_ttm_copy_mem_to_mem(struct amdgpu_device *adev, > r = amdgpu_ttm_map_buffer(&entity->base, > src->bo, src->mem, &src_mm, > entity->gart_window_id0, ring, tmz, &cur_size, &from, > - NULL); > + NULL, NULL); > if (r) > goto error; > > r = amdgpu_ttm_map_buffer(&entity->base, > dst->bo, dst->mem, &dst_mm, > entity->gart_window_id1, ring, tmz, &cur_size, &to, > - NULL); > + NULL, NULL); > if (r) > goto error; > > @@ -2451,7 +2456,7 @@ int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, > r = amdgpu_ttm_map_buffer(&entity->base, > &bo->tbo, bo->tbo.resource, &cursor, > entity->gart_window_id1, ring, false, &size, &addr, > - NULL); > + NULL, NULL); > if (r) > goto err; > > @@ -2506,7 +2511,8 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > &bo->tbo, bo->tbo.resource, &dst, > entity->gart_window_id1, ring, false, > &cur_size, &to, > - dependency); > + dependency, > + resv); > if (r) > goto error; >

2 weeks, 4 days

Re: [PATCH v2 09/20] drm/amdgpu: pass optional dependency to amdgpu_fill_buffer

by Christian König

On 11/13/25 17:05, Pierre-Eric Pelloux-Prayer wrote: > In case the fill job depends on a previous fence, the caller can > now pass it to make sure the ordering of the jobs is correct. I don't think you need that patch any more. > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 22 ++++++++++++++++------ > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + > 3 files changed, 18 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index e7b2cae031b3..be3532134e46 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -1322,7 +1322,7 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) > goto out; > > r = amdgpu_fill_buffer(&adev->mman.clear_entities[0], abo, 0, &bo->base._resv, > - &fence, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); > + &fence, NULL, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); > if (WARN_ON(r)) > goto out; > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index e1f0567fd2d5..b13f0993dbf1 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -173,6 +173,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo, > * @tmz: if we should setup a TMZ enabled mapping > * @size: in number of bytes to map, out number of bytes mapped > * @addr: resulting address inside the MC address space > + * @dep: optional dependency > * > * Setup one of the GART windows to access a specific piece of memory or return > * the physical address for local memory. > @@ -182,7 +183,8 @@ static int amdgpu_ttm_map_buffer(struct drm_sched_entity *entity, > struct ttm_resource *mem, > struct amdgpu_res_cursor *mm_cur, > unsigned int window, struct amdgpu_ring *ring, > - bool tmz, uint64_t *size, uint64_t *addr) > + bool tmz, uint64_t *size, uint64_t *addr, > + struct dma_fence *dep) > { > struct amdgpu_device *adev = ring->adev; > unsigned int offset, num_pages, num_dw, num_bytes; > @@ -234,6 +236,9 @@ static int amdgpu_ttm_map_buffer(struct drm_sched_entity *entity, > if (r) > return r; > > + if (dep) > + drm_sched_job_add_dependency(&job->base, dma_fence_get(dep)); > + > src_addr = num_dw * 4; > src_addr += job->ibs[0].gpu_addr; > > @@ -326,13 +331,15 @@ static int amdgpu_ttm_copy_mem_to_mem(struct amdgpu_device *adev, > /* Map src to window 0 and dst to window 1. */ > r = amdgpu_ttm_map_buffer(&entity->base, > src->bo, src->mem, &src_mm, > - entity->gart_window_id0, ring, tmz, &cur_size, &from); > + entity->gart_window_id0, ring, tmz, &cur_size, &from, > + NULL); > if (r) > goto error; > > r = amdgpu_ttm_map_buffer(&entity->base, > dst->bo, dst->mem, &dst_mm, > - entity->gart_window_id1, ring, tmz, &cur_size, &to); > + entity->gart_window_id1, ring, tmz, &cur_size, &to, > + NULL); > if (r) > goto error; > > @@ -415,7 +422,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo, > struct dma_fence *wipe_fence = NULL; > > r = amdgpu_fill_buffer(&adev->mman.move_entities[0], > - abo, 0, NULL, &wipe_fence, > + abo, 0, NULL, &wipe_fence, fence, > AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); > if (r) { > goto error; > @@ -2443,7 +2450,8 @@ int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, > > r = amdgpu_ttm_map_buffer(&entity->base, > &bo->tbo, bo->tbo.resource, &cursor, > - entity->gart_window_id1, ring, false, &size, &addr); > + entity->gart_window_id1, ring, false, &size, &addr, > + NULL); > if (r) > goto err; > > @@ -2469,6 +2477,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > uint32_t src_data, > struct dma_resv *resv, > struct dma_fence **f, > + struct dma_fence *dependency, > u64 k_job_id) > { > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > @@ -2496,7 +2505,8 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > r = amdgpu_ttm_map_buffer(&entity->base, > &bo->tbo, bo->tbo.resource, &dst, > entity->gart_window_id1, ring, false, > - &cur_size, &to); > + &cur_size, &to, > + dependency); > if (r) > goto error; > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > index 9d4891e86675..e8f8165f5bcf 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -186,6 +186,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_buffer_entity *entity, > uint32_t src_data, > struct dma_resv *resv, > struct dma_fence **f, > + struct dma_fence *dependency, > u64 k_job_id); > > int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo);

2 weeks, 4 days

← Newer
1
...
5
6
7
8
9
10
11
...
323
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig