Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

14 participants
2937 discussions

Re: [RFC PATCH 00/12] Private MMIO support for private assigned dev

by Jason Gunthorpe

On Mon, May 12, 2025 at 07:30:21PM +1000, Alexey Kardashevskiy wrote: > > > I'm surprised by this.. iommufd shouldn't be doing PCI stuff, it is > > > just about managing the translation control of the device. > > > > I have a little difficulty to understand. Is TSM bind PCI stuff? To me > > it is. Host sends PCI TDISP messages via PCI DOE to put the device in > > TDISP LOCKED state, so that device behaves differently from before. Then > > why put it in IOMMUFD? > > > "TSM bind" sets up the CPU side of it, it binds a VM to a piece of > IOMMU on the host CPU. The device does not know about the VM, it > just enables/disables encryption by a request from the CPU (those > start/stop interface commands). And IOMMUFD won't be doing DOE, the > platform driver (such as AMD CCP) will. Nothing to do for VFIO here. > > We probably should notify VFIO about the state transition but I do > not know VFIO would want to do in response. We have an awkward fit for what CCA people are doing to the various Linux APIs. Looking somewhat maximally across all the arches a "bind" for a CC vPCI device creation operation does: - Setup the CPU page tables for the VM to have access to the MMIO - Revoke hypervisor access to the MMIO - Setup the vIOMMU to understand the vPCI device - Take over control of some of the IOVA translation, at least for T=1, and route to the the vIOMMU - Register the vPCI with any attestation functions the VM might use - Do some DOE stuff to manage/validate TDSIP/etc So we have interactions of things controlled by PCI, KVM, VFIO, and iommufd all mushed together. iommufd is the only area that already has a handle to all the required objects: - The physical PCI function - The CC vIOMMU object - The KVM FD - The CC vPCI object Which is why I have been thinking it is the right place to manage this. It doesn't mean that iommufd is suddenly doing PCI stuff, no, that stays in VFIO. > > > So your issue is you need to shoot down the dmabuf during vPCI device > > > destruction? > > > > I assume "vPCI device" refers to assigned device in both shared mode & > > prvate mode. So no, I need to shoot down the dmabuf during TSM unbind, > > a.k.a. when assigned device is converting from private to shared. > > Then recover the dmabuf after TSM unbind. The device could still work > > in VM in shared mode. What are you trying to protect with this? Is there some intelism where you can't have references to encrypted MMIO pages? > > What I really want is, one SW component to manage MMIO dmabuf, secure > > iommu & TSM bind/unbind. So easier coordinate these 3 operations cause > > these ops are interconnected according to secure firmware's requirement. > > This SW component is QEMU. It knows about FLRs and other config > space things, it can destroy all these IOMMUFD objects and talk to > VFIO too, I've tried, so far it is looking easier to manage. Thanks, Yes, qemu should be sequencing this. The kernel only needs to enforce any rules required to keep the system from crashing. Jason

1 month, 4 weeks

Re: [PATCH] dma-buf: insert memory barrier before updating num_fences

by Christian König

On 5/12/25 13:12, Hyejeong Choi wrote: > smp_store_mb() inserts memory barrier after storing operation. > It is different with what the comment is originally aiming so Null > pointer dereference can be happened if memory update is reordered. > > Signed-off-by: Hyejeong Choi <hjeong.choi(a)samsung.com> > --- > drivers/dma-buf/dma-resv.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > index 5f8d010516f0..52af5c7430da 100644 > --- a/drivers/dma-buf/dma-resv.c > +++ b/drivers/dma-buf/dma-resv.c > @@ -320,8 +320,9 @@ void dma_resv_add_fence(struct dma_resv *obj, struct dma_fence *fence, > count++; > > dma_resv_list_set(fobj, i, fence, usage); > - /* pointer update must be visible before we extend the num_fences */ > - smp_store_mb(fobj->num_fences, count); > + /* fence update must be visible before we extend the num_fences */ > + smp_wmb(); > + WRITE_ONCE(fobj->num_fences, count); The WRITE_ONCE isn't necessary since smp_wmb() implies a compiler barrier, but apart from that really good catch. Can you modify the patch and re-send? I will be pushing it to -fixes ASAP. Regards, Christian. > } > EXPORT_SYMBOL(dma_resv_add_fence); > > >

1 month, 4 weeks

Re: [RFC v2 09/13] drm/i915: Use dma-fence driver and timeline name helpers

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > Access the dma-fence internals via the previously added helpers. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/gpu/drm/i915/gt/intel_gt_requests.c | 4 ++-- > drivers/gpu/drm/i915/i915_request.c | 2 +- > drivers/gpu/drm/i915/i915_sw_fence.c | 4 ++-- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/drm/i915/gt/intel_gt_requests.c > index d1a382dfaa1d..ae3557ed6c1e 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c > @@ -252,8 +252,8 @@ void intel_gt_watchdog_work(struct work_struct *work) > struct dma_fence *f = &rq->fence; > > pr_notice("Fence expiration time out i915-%s:%s:%llx!\n", > - f->ops->get_driver_name(f), > - f->ops->get_timeline_name(f), > + dma_fence_driver_name(f), > + dma_fence_timeline_name(f), > f->seqno); > i915_request_cancel(rq, -EINTR); > } > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c > index c3d27eadc0a7..4874c4f1e4ab 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -2184,7 +2184,7 @@ void i915_request_show(struct drm_printer *m, > const char *prefix, > int indent) > { > - const char *name = rq->fence.ops->get_timeline_name((struct dma_fence *)&rq->fence); > + const char *name = dma_fence_timeline_name((struct dma_fence *)&rq->fence); > char buf[80] = ""; > int x = 0; > > diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c > index 1d4cc91c0e40..e51ca7e50a4e 100644 > --- a/drivers/gpu/drm/i915/i915_sw_fence.c > +++ b/drivers/gpu/drm/i915/i915_sw_fence.c > @@ -435,8 +435,8 @@ static void timer_i915_sw_fence_wake(struct timer_list *t) > return; > > pr_notice("Asynchronous wait on fence %s:%s:%llx timed out (hint:%ps)\n", > - cb->dma->ops->get_driver_name(cb->dma), > - cb->dma->ops->get_timeline_name(cb->dma), > + dma_fence_driver_name(cb->dma), > + dma_fence_timeline_name(cb->dma), > cb->dma->seqno, > i915_sw_fence_debug_hint(fence)); >

1 month, 4 weeks

Re: [RFC v2 08/13] drm/amdgpu: Use dma-fence driver and timeline name helpers

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > Access the dma-fence internals via the previously added helpers. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > index 11dd2e0f7979..8e5bf179a6c8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h > @@ -33,7 +33,7 @@ > #define TRACE_INCLUDE_FILE amdgpu_trace > > #define AMDGPU_JOB_GET_TIMELINE_NAME(job) \ > - job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished) > + dma_fence_timeline_name(&job->base.s_fence->finished) I think you can nuke the macro now as well, the new function name is short enough. Christian. > > TRACE_EVENT(amdgpu_device_rreg, > TP_PROTO(unsigned did, uint32_t reg, uint32_t value),

1 month, 4 weeks

Re: [RFC v2 07/13] sync_file: Use dma-fence driver and timeline name helpers

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > Access the dma-fence internals via the previously added helpers. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/sync_file.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c > index d9b1c1b2a72b..212df4b849fe 100644 > --- a/drivers/dma-buf/sync_file.c > +++ b/drivers/dma-buf/sync_file.c > @@ -137,8 +137,8 @@ char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len) > struct dma_fence *fence = sync_file->fence; > > snprintf(buf, len, "%s-%s%llu-%lld", > - fence->ops->get_driver_name(fence), > - fence->ops->get_timeline_name(fence), > + dma_fence_driver_name(fence), > + dma_fence_timeline_name(fence), > fence->context, > fence->seqno); > } > @@ -262,9 +262,9 @@ static long sync_file_ioctl_merge(struct sync_file *sync_file, > static int sync_fill_fence_info(struct dma_fence *fence, > struct sync_fence_info *info) > { > - strscpy(info->obj_name, fence->ops->get_timeline_name(fence), > + strscpy(info->obj_name, dma_fence_timeline_name(fence), > sizeof(info->obj_name)); > - strscpy(info->driver_name, fence->ops->get_driver_name(fence), > + strscpy(info->driver_name, dma_fence_driver_name(fence), > sizeof(info->driver_name)); > > info->status = dma_fence_get_status(fence);

1 month, 4 weeks

Re: [RFC v2 06/13] dma-fence: Use driver and timeline name helpers internally

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > Make the implementation use the previously added helper for accessing the > driver and timeline name. This will enable more coverage later when > asserts will be added into them. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> I would squash that together with the previous patch. Since both patches are for the same component it doesn't make much sense to separate them. Anyway Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence.c | 9 +++++---- > include/trace/events/dma_fence.h | 4 ++-- > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 33661658f684..dc2456f68685 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -538,8 +538,8 @@ void dma_fence_release(struct kref *kref) > if (WARN(!list_empty(&fence->cb_list) && > !test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags), > "Fence %s:%s:%llx:%llx released with pending signals!\n", > - fence->ops->get_driver_name(fence), > - fence->ops->get_timeline_name(fence), > + dma_fence_driver_name(fence), > + dma_fence_timeline_name(fence), > fence->context, fence->seqno)) { > unsigned long flags; > > @@ -983,8 +983,9 @@ EXPORT_SYMBOL(dma_fence_set_deadline); > void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq) > { > seq_printf(seq, "%s %s seq %llu %ssignalled\n", > - fence->ops->get_driver_name(fence), > - fence->ops->get_timeline_name(fence), fence->seqno, > + dma_fence_driver_name(fence), > + dma_fence_timeline_name(fence), > + fence->seqno, > dma_fence_is_signaled(fence) ? "" : "un"); > } > EXPORT_SYMBOL(dma_fence_describe); > diff --git a/include/trace/events/dma_fence.h b/include/trace/events/dma_fence.h > index a4de3df8500b..84c83074ee81 100644 > --- a/include/trace/events/dma_fence.h > +++ b/include/trace/events/dma_fence.h > @@ -16,8 +16,8 @@ DECLARE_EVENT_CLASS(dma_fence, > TP_ARGS(fence), > > TP_STRUCT__entry( > - __string(driver, fence->ops->get_driver_name(fence)) > - __string(timeline, fence->ops->get_timeline_name(fence)) > + __string(driver, dma_fence_driver_name(fence)) > + __string(timeline, dma_fence_timeline_name(fence)) > __field(unsigned int, context) > __field(unsigned int, seqno) > ),

1 month, 4 weeks

Re: [RFC v2 05/13] dma-fence: Add helpers for accessing driver and timeline name

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > Add some helpers in order to enable preventing dma-fence users accessing > the implementation details directly. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > include/linux/dma-fence.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index 5bafd0a5f1f1..c814a86087f8 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -387,6 +387,16 @@ bool dma_fence_remove_callback(struct dma_fence *fence, > struct dma_fence_cb *cb); > void dma_fence_enable_sw_signaling(struct dma_fence *fence); > > +static inline const char *dma_fence_driver_name(struct dma_fence *fence) > +{ > + return fence->ops->get_driver_name(fence); > +} > + > +static inline const char *dma_fence_timeline_name(struct dma_fence *fence) > +{ > + return fence->ops->get_timeline_name(fence); > +} > + > /** > * dma_fence_is_signaled_locked - Return an indication if the fence > * is signaled yet.

1 month, 4 weeks

Re: [RFC v2 04/13] dma-fence: Move array and chain checks to flags

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > With the goal of reducing the need for drivers to touch fence->ops, we > add explicit flags for struct dma_fence_array and struct dma_fence_chain > and make the respective helpers (dma_fence_is_array() and > dma_fence_is_chain()) use them. > > This also allows us to remove the exported symbols for the respective > operation tables. That looks like overkill to me. We don't de-reference the ops for the check, instead just the values are compared. Since the array and chain are always build in that should be completely unproblematic for driver unload. Regards, Christian. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > --- > drivers/dma-buf/dma-fence-array.c | 2 +- > drivers/dma-buf/dma-fence-chain.c | 2 +- > include/linux/dma-fence.h | 9 ++++----- > 3 files changed, 6 insertions(+), 7 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c > index 6657d4b30af9..daf444f5d228 100644 > --- a/drivers/dma-buf/dma-fence-array.c > +++ b/drivers/dma-buf/dma-fence-array.c > @@ -167,7 +167,6 @@ const struct dma_fence_ops dma_fence_array_ops = { > .release = dma_fence_array_release, > .set_deadline = dma_fence_array_set_deadline, > }; > -EXPORT_SYMBOL(dma_fence_array_ops); > > /** > * dma_fence_array_alloc - Allocate a custom fence array > @@ -207,6 +206,7 @@ void dma_fence_array_init(struct dma_fence_array *array, > spin_lock_init(&array->lock); > dma_fence_init(&array->base, &dma_fence_array_ops, &array->lock, > context, seqno); > + __set_bit(DMA_FENCE_FLAG_ARRAY_BIT, &array->base.flags); > init_irq_work(&array->work, irq_dma_fence_array_work); > > atomic_set(&array->num_pending, signal_on_any ? 1 : num_fences); > diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c > index a8a90acf4f34..f4abe41fb092 100644 > --- a/drivers/dma-buf/dma-fence-chain.c > +++ b/drivers/dma-buf/dma-fence-chain.c > @@ -225,7 +225,6 @@ const struct dma_fence_ops dma_fence_chain_ops = { > .release = dma_fence_chain_release, > .set_deadline = dma_fence_chain_set_deadline, > }; > -EXPORT_SYMBOL(dma_fence_chain_ops); > > /** > * dma_fence_chain_init - initialize a fence chain > @@ -263,6 +262,7 @@ void dma_fence_chain_init(struct dma_fence_chain *chain, > > dma_fence_init64(&chain->base, &dma_fence_chain_ops, &chain->lock, > context, seqno); > + __set_bit(DMA_FENCE_FLAG_CHAIN_BIT, &chain->base.flags); > > /* > * Chaining dma_fence_chain container together is only allowed through > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index ac6535716dbe..5bafd0a5f1f1 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -98,6 +98,8 @@ struct dma_fence { > > enum dma_fence_flag_bits { > DMA_FENCE_FLAG_SEQNO64_BIT, > + DMA_FENCE_FLAG_ARRAY_BIT, > + DMA_FENCE_FLAG_CHAIN_BIT, > DMA_FENCE_FLAG_SIGNALED_BIT, > DMA_FENCE_FLAG_TIMESTAMP_BIT, > DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, > @@ -632,9 +634,6 @@ struct dma_fence *dma_fence_get_stub(void); > struct dma_fence *dma_fence_allocate_private_stub(ktime_t timestamp); > u64 dma_fence_context_alloc(unsigned num); > > -extern const struct dma_fence_ops dma_fence_array_ops; > -extern const struct dma_fence_ops dma_fence_chain_ops; > - > /** > * dma_fence_is_array - check if a fence is from the array subclass > * @fence: the fence to test > @@ -643,7 +642,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops; > */ > static inline bool dma_fence_is_array(struct dma_fence *fence) > { > - return fence->ops == &dma_fence_array_ops; > + return test_bit(DMA_FENCE_FLAG_ARRAY_BIT, &fence->flags); > } > > /** > @@ -654,7 +653,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence) > */ > static inline bool dma_fence_is_chain(struct dma_fence *fence) > { > - return fence->ops == &dma_fence_chain_ops; > + return test_bit(DMA_FENCE_FLAG_CHAIN_BIT, &fence->flags); > } > > /**

1 month, 4 weeks

Re: [RFC v2 03/13] dma-fence: Use a flag for 64-bit seqnos

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > With the goal of reducing the need for drivers to touch (and dereference) > fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to > the fence->flags. > > Drivers which were setting this flag are changed to use new > dma_fence_init64() instead of dma_fence_init(). > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> My idea was to copy the flag from the ops during init, but that should work as well. Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence-chain.c | 5 ++--- > drivers/dma-buf/dma-fence.c | 9 +++++++++ > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c | 5 ++--- > include/linux/dma-fence.h | 6 +++++- > 4 files changed, 18 insertions(+), 7 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c > index 90424f23fd73..a8a90acf4f34 100644 > --- a/drivers/dma-buf/dma-fence-chain.c > +++ b/drivers/dma-buf/dma-fence-chain.c > @@ -218,7 +218,6 @@ static void dma_fence_chain_set_deadline(struct dma_fence *fence, > } > > const struct dma_fence_ops dma_fence_chain_ops = { > - .use_64bit_seqno = true, > .get_driver_name = dma_fence_chain_get_driver_name, > .get_timeline_name = dma_fence_chain_get_timeline_name, > .enable_signaling = dma_fence_chain_enable_signaling, > @@ -262,8 +261,8 @@ void dma_fence_chain_init(struct dma_fence_chain *chain, > seqno = max(prev->seqno, seqno); > } > > - dma_fence_init(&chain->base, &dma_fence_chain_ops, > - &chain->lock, context, seqno); > + dma_fence_init64(&chain->base, &dma_fence_chain_ops, &chain->lock, > + context, seqno); > > /* > * Chaining dma_fence_chain container together is only allowed through > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index f0cdd3e99d36..33661658f684 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -1023,3 +1023,12 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, > trace_dma_fence_init(fence); > } > EXPORT_SYMBOL(dma_fence_init); > + > +void > +dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops, > + spinlock_t *lock, u64 context, u64 seqno) > +{ > + dma_fence_init(fence, ops, lock, context, seqno); > + __set_bit(DMA_FENCE_FLAG_SEQNO64_BIT, &fence->flags); > +} > +EXPORT_SYMBOL(dma_fence_init64); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c > index 51cddfa3f1e8..5d26797356a3 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c > @@ -71,7 +71,6 @@ static void amdgpu_tlb_fence_work(struct work_struct *work) > } > > static const struct dma_fence_ops amdgpu_tlb_fence_ops = { > - .use_64bit_seqno = true, > .get_driver_name = amdgpu_tlb_fence_get_driver_name, > .get_timeline_name = amdgpu_tlb_fence_get_timeline_name > }; > @@ -101,8 +100,8 @@ void amdgpu_vm_tlb_fence_create(struct amdgpu_device *adev, struct amdgpu_vm *vm > INIT_WORK(&f->work, amdgpu_tlb_fence_work); > spin_lock_init(&f->lock); > > - dma_fence_init(&f->base, &amdgpu_tlb_fence_ops, &f->lock, > - vm->tlb_fence_context, atomic64_read(&vm->tlb_seq)); > + dma_fence_init64(&f->base, &amdgpu_tlb_fence_ops, &f->lock, > + vm->tlb_fence_context, atomic64_read(&vm->tlb_seq)); > > /* TODO: We probably need a separate wq here */ > dma_fence_get(&f->base); > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index 48b5202c531d..ac6535716dbe 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -97,6 +97,7 @@ struct dma_fence { > }; > > enum dma_fence_flag_bits { > + DMA_FENCE_FLAG_SEQNO64_BIT, > DMA_FENCE_FLAG_SIGNALED_BIT, > DMA_FENCE_FLAG_TIMESTAMP_BIT, > DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, > @@ -262,6 +263,9 @@ struct dma_fence_ops { > void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops, > spinlock_t *lock, u64 context, u64 seqno); > > +void dma_fence_init64(struct dma_fence *fence, const struct dma_fence_ops *ops, > + spinlock_t *lock, u64 context, u64 seqno); > + > void dma_fence_release(struct kref *kref); > void dma_fence_free(struct dma_fence *fence); > void dma_fence_describe(struct dma_fence *fence, struct seq_file *seq); > @@ -454,7 +458,7 @@ static inline bool __dma_fence_is_later(struct dma_fence *fence, u64 f1, u64 f2) > * 32bit sequence numbers. Use a 64bit compare when the driver says to > * do so. > */ > - if (fence->ops->use_64bit_seqno) > + if (test_bit(DMA_FENCE_FLAG_SEQNO64_BIT, &fence->flags)) > return f1 > f2; > > return (int)(lower_32_bits(f1) - lower_32_bits(f2)) > 0;

1 month, 4 weeks

Re: [RFC v2 02/13] dma-fence: Change signature of __dma_fence_is_later

by Christian König

On 5/9/25 17:33, Tvrtko Ursulin wrote: > With the goal of reducing the need for drivers to touch (and dereference) > fence->ops, we change the prototype of __dma_fence_is_later() to take > fence instead of fence->ops. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence-chain.c | 2 +- > drivers/dma-buf/sw_sync.c | 2 +- > drivers/gpu/drm/xe/xe_hw_fence.c | 2 +- > drivers/gpu/drm/xe/xe_sched_job.c | 14 ++++++++------ > include/linux/dma-fence.h | 9 ++++----- > 5 files changed, 15 insertions(+), 14 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c > index 9663ba1bb6ac..90424f23fd73 100644 > --- a/drivers/dma-buf/dma-fence-chain.c > +++ b/drivers/dma-buf/dma-fence-chain.c > @@ -252,7 +252,7 @@ void dma_fence_chain_init(struct dma_fence_chain *chain, > chain->prev_seqno = 0; > > /* Try to reuse the context of the previous chain node. */ > - if (prev_chain && __dma_fence_is_later(seqno, prev->seqno, prev->ops)) { > + if (prev_chain && __dma_fence_is_later(prev, seqno, prev->seqno)) { > context = prev->context; > chain->prev_seqno = prev->seqno; > } else { > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c > index 4f27ee93a00c..3c20f1d31cf5 100644 > --- a/drivers/dma-buf/sw_sync.c > +++ b/drivers/dma-buf/sw_sync.c > @@ -170,7 +170,7 @@ static bool timeline_fence_signaled(struct dma_fence *fence) > { > struct sync_timeline *parent = dma_fence_parent(fence); > > - return !__dma_fence_is_later(fence->seqno, parent->value, fence->ops); > + return !__dma_fence_is_later(fence, fence->seqno, parent->value); > } > > static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) > diff --git a/drivers/gpu/drm/xe/xe_hw_fence.c b/drivers/gpu/drm/xe/xe_hw_fence.c > index 0b4f12be3692..03eb8c6d1616 100644 > --- a/drivers/gpu/drm/xe/xe_hw_fence.c > +++ b/drivers/gpu/drm/xe/xe_hw_fence.c > @@ -165,7 +165,7 @@ static bool xe_hw_fence_signaled(struct dma_fence *dma_fence) > u32 seqno = xe_map_rd(xe, &fence->seqno_map, 0, u32); > > return dma_fence->error || > - !__dma_fence_is_later(dma_fence->seqno, seqno, dma_fence->ops); > + !__dma_fence_is_later(dma_fence, dma_fence->seqno, seqno); > } > > static bool xe_hw_fence_enable_signaling(struct dma_fence *dma_fence) > diff --git a/drivers/gpu/drm/xe/xe_sched_job.c b/drivers/gpu/drm/xe/xe_sched_job.c > index 1905ca590965..f0a6ce610948 100644 > --- a/drivers/gpu/drm/xe/xe_sched_job.c > +++ b/drivers/gpu/drm/xe/xe_sched_job.c > @@ -216,15 +216,17 @@ void xe_sched_job_set_error(struct xe_sched_job *job, int error) > > bool xe_sched_job_started(struct xe_sched_job *job) > { > + struct dma_fence *fence = dma_fence_chain_contained(job->fence); > struct xe_lrc *lrc = job->q->lrc[0]; > > - return !__dma_fence_is_later(xe_sched_job_lrc_seqno(job), > - xe_lrc_start_seqno(lrc), > - dma_fence_chain_contained(job->fence)->ops); > + return !__dma_fence_is_later(fence, > + xe_sched_job_lrc_seqno(job), > + xe_lrc_start_seqno(lrc)); > } > > bool xe_sched_job_completed(struct xe_sched_job *job) > { > + struct dma_fence *fence = dma_fence_chain_contained(job->fence); > struct xe_lrc *lrc = job->q->lrc[0]; > > /* > @@ -232,9 +234,9 @@ bool xe_sched_job_completed(struct xe_sched_job *job) > * parallel handshake is done. > */ > > - return !__dma_fence_is_later(xe_sched_job_lrc_seqno(job), > - xe_lrc_seqno(lrc), > - dma_fence_chain_contained(job->fence)->ops); > + return !__dma_fence_is_later(fence, > + xe_sched_job_lrc_seqno(job), > + xe_lrc_seqno(lrc)); > } > > void xe_sched_job_arm(struct xe_sched_job *job) > diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h > index b12776883d14..48b5202c531d 100644 > --- a/include/linux/dma-fence.h > +++ b/include/linux/dma-fence.h > @@ -441,21 +441,20 @@ dma_fence_is_signaled(struct dma_fence *fence) > > /** > * __dma_fence_is_later - return if f1 is chronologically later than f2 > + * @fence: fence in whose context to do the comparison > * @f1: the first fence's seqno > * @f2: the second fence's seqno from the same context > - * @ops: dma_fence_ops associated with the seqno > * > * Returns true if f1 is chronologically later than f2. Both fences must be > * from the same context, since a seqno is not common across contexts. > */ > -static inline bool __dma_fence_is_later(u64 f1, u64 f2, > - const struct dma_fence_ops *ops) > +static inline bool __dma_fence_is_later(struct dma_fence *fence, u64 f1, u64 f2) > { > /* This is for backward compatibility with drivers which can only handle > * 32bit sequence numbers. Use a 64bit compare when the driver says to > * do so. > */ > - if (ops->use_64bit_seqno) > + if (fence->ops->use_64bit_seqno) > return f1 > f2; > > return (int)(lower_32_bits(f1) - lower_32_bits(f2)) > 0; > @@ -475,7 +474,7 @@ static inline bool dma_fence_is_later(struct dma_fence *f1, > if (WARN_ON(f1->context != f2->context)) > return false; > > - return __dma_fence_is_later(f1->seqno, f2->seqno, f1->ops); > + return __dma_fence_is_later(f1, f1->seqno, f2->seqno); > } > > /**

1 month, 4 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig