On 9/30/26 11:08, Pavel Begunkov wrote:
On 9/30/26 04:00, Matthew Brost wrote:
On Mon, Sep 21, 2026 at 02:38:45PM +0100, Pavel Begunkov wrote:
...>> +struct dma_buf_io_map *dma_buf_io_create_map(struct dma_buf_io_ctx *ctx)
+{
+ struct dma_buf *dmabuf = ctx->dmabuf;
+ struct dma_buf_io_map *map;
+ long ret;
+
+ guard(mutex)(&ctx->map_create_mutex);
+
+ scoped_guard(mutex, &ctx->map_mutex) {
+ if (ctx->maps_killed)
+ return ERR_PTR(-ENOENT);
+ /* recheck under the lock in case it has already been re-created */
+ map = __dma_buf_io_get_map(ctx);
+ if (map)
+ return map;
+ }
+
+ dma_buf_io_wait_active_maps(ctx);
+
+ ret = dma_resv_lock_interruptible(dmabuf->resv, NULL);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = dma_resv_wait_timeout(dmabuf->resv, DMA_RESV_USAGE_KERNEL,
+ true, MAX_SCHEDULE_TIMEOUT);
+ if (ret <= 0) {
+ if (!ret)
+ ret = -EAGAIN;
+ dma_resv_unlock(dmabuf->resv);
+ return ERR_PTR(ret);
+ }
+
+ map = ctx->dev_ops->map(ctx);
I'm playing around this code now.
I think you need the dma_resv_wait_timeout after the 'map'?
If a device doesn't support p2p ->map() will typically trigger an async
migrate to system memory and data will be moving but the map is valid -
Xe 100% does this, I checked AMDGPU and fairly confident it has the same
async behavior.
There is a wait right before because I read somewhere in dma-buf
comments that I need to do that, sounds a bit odd if I need to
wait on fences before and after. I can add it, just curious how
come that other dma_buf_map_attachment() callers don't need to do
that. Or maybe they wait somewhere else?
I can't find it, so maybe it was the comment below and I mixed
sth up back then. I'll move it after ->map().
* Note that for non-dynamic exporters the driver must guarantee that
* that the memory is available for use and cleared of any old data by
* the time this function returns. Drivers which pipeline their buffer
* moves internally must wait for all moves and clears to complete.
* Dynamic exporters do not need to follow this rule: For non-dynamic
* importers the buffer is already pinned through @pin, which has the
* same requirements. Dynamic importers otoh are required to obey the
* dma_resv fences.
*
--
Pavel Begunkov
