- Linaro-mm-sig - lists.linaro.org

Re: [PATCH v2 02/20] drm/ttm: rework pipelined eviction fence handling

by Christian König

On 11/13/25 17:05, Pierre-Eric Pelloux-Prayer wrote: > Until now ttm stored a single pipelined eviction fence which means > drivers had to use a single entity for these evictions. > > To lift this requirement, this commit allows up to 8 entities to > be used. > > Ideally a dma_resv object would have been used as a container of > the eviction fences, but the locking rules makes it complex. > dma_resv all have the same ww_class, which means "Attempting to > lock more mutexes after ww_acquire_done." is an error. > > One alternative considered was to introduced a 2nd ww_class for > specific resv to hold a single "transient" lock (= the resv lock > would only be held for a short period, without taking any other > locks). > > The other option, is to statically reserve a fence array, and > extend the existing code to deal with N fences, instead of 1. > > The driver is still responsible to reserve the correct number > of fence slots. > > --- > v2: > - simplified code > - dropped n_fences > - name changes > --- > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 ++-- > .../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 11 +++-- > drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 5 +- > drivers/gpu/drm/ttm/ttm_bo.c | 47 ++++++++++--------- > drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ++++++++++++--- > drivers/gpu/drm/ttm/ttm_resource.c | 31 +++++++----- > include/drm/ttm/ttm_resource.h | 29 ++++++++---- > 7 files changed, 109 insertions(+), 60 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index 326476089db3..3b46a24a8c48 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -2156,7 +2156,7 @@ void amdgpu_ttm_set_buffer_funcs_status(struct amdgpu_device *adev, bool enable) > { > struct ttm_resource_manager *man = ttm_manager_type(&adev->mman.bdev, TTM_PL_VRAM); > uint64_t size; > - int r; > + int r, i; > > if (!adev->mman.initialized || amdgpu_in_reset(adev) || > adev->mman.buffer_funcs_enabled == enable || adev->gmc.is_app_apu) > @@ -2190,8 +2190,10 @@ void amdgpu_ttm_set_buffer_funcs_status(struct amdgpu_device *adev, bool enable) > } else { > drm_sched_entity_destroy(&adev->mman.high_pr); > drm_sched_entity_destroy(&adev->mman.low_pr); > - dma_fence_put(man->move); > - man->move = NULL; > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) { > + dma_fence_put(man->eviction_fences[i]); > + man->eviction_fences[i] = NULL; > + } That code should have been a TTM function in the first place. I suggest to just call ttm_resource_manager_cleanup() here instead and add this as comment: /* Drop all the old fences since re-creating the scheduler entities will allocate next contexts */ Apart from that looks good to me. Regards, Christian. > } > > /* this just adjusts TTM size idea, which sets lpfn to the correct value */ > diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c > index 3148f5d3dbd6..8f71906c4238 100644 > --- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c > +++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c > @@ -651,7 +651,7 @@ static void ttm_bo_validate_move_fence_signaled(struct kunit *test) > int err; > > man = ttm_manager_type(priv->ttm_dev, mem_type); > - man->move = dma_fence_get_stub(); > + man->eviction_fences[0] = dma_fence_get_stub(); > > bo = ttm_bo_kunit_init(test, test->priv, size, NULL); > bo->type = bo_type; > @@ -668,7 +668,7 @@ static void ttm_bo_validate_move_fence_signaled(struct kunit *test) > KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size); > > ttm_bo_put(bo); > - dma_fence_put(man->move); > + dma_fence_put(man->eviction_fences[0]); > } > > static const struct ttm_bo_validate_test_case ttm_bo_validate_wait_cases[] = { > @@ -732,9 +732,9 @@ static void ttm_bo_validate_move_fence_not_signaled(struct kunit *test) > > spin_lock_init(&fence_lock); > man = ttm_manager_type(priv->ttm_dev, fst_mem); > - man->move = alloc_mock_fence(test); > + man->eviction_fences[0] = alloc_mock_fence(test); > > - task = kthread_create(threaded_fence_signal, man->move, "move-fence-signal"); > + task = kthread_create(threaded_fence_signal, man->eviction_fences[0], "move-fence-signal"); > if (IS_ERR(task)) > KUNIT_FAIL(test, "Couldn't create move fence signal task\n"); > > @@ -742,7 +742,8 @@ static void ttm_bo_validate_move_fence_not_signaled(struct kunit *test) > err = ttm_bo_validate(bo, placement_val, &ctx_val); > dma_resv_unlock(bo->base.resv); > > - dma_fence_wait_timeout(man->move, false, MAX_SCHEDULE_TIMEOUT); > + dma_fence_wait_timeout(man->eviction_fences[0], false, MAX_SCHEDULE_TIMEOUT); > + man->eviction_fences[0] = NULL; > > KUNIT_EXPECT_EQ(test, err, 0); > KUNIT_EXPECT_EQ(test, ctx_val.bytes_moved, size); > diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c > index e6ea2bd01f07..c0e4e35e0442 100644 > --- a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c > +++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c > @@ -207,6 +207,7 @@ static void ttm_resource_manager_init_basic(struct kunit *test) > struct ttm_resource_test_priv *priv = test->priv; > struct ttm_resource_manager *man; > size_t size = SZ_16K; > + int i; > > man = kunit_kzalloc(test, sizeof(*man), GFP_KERNEL); > KUNIT_ASSERT_NOT_NULL(test, man); > @@ -216,8 +217,8 @@ static void ttm_resource_manager_init_basic(struct kunit *test) > KUNIT_ASSERT_PTR_EQ(test, man->bdev, priv->devs->ttm_dev); > KUNIT_ASSERT_EQ(test, man->size, size); > KUNIT_ASSERT_EQ(test, man->usage, 0); > - KUNIT_ASSERT_NULL(test, man->move); > - KUNIT_ASSERT_NOT_NULL(test, &man->move_lock); > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) > + KUNIT_ASSERT_NULL(test, man->eviction_fences[i]); > > for (int i = 0; i < TTM_MAX_BO_PRIORITY; ++i) > KUNIT_ASSERT_TRUE(test, list_empty(&man->lru[i])); > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index f4d9e68b21e7..0b3732ed6f6c 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -658,34 +658,35 @@ void ttm_bo_unpin(struct ttm_buffer_object *bo) > EXPORT_SYMBOL(ttm_bo_unpin); > > /* > - * Add the last move fence to the BO as kernel dependency and reserve a new > - * fence slot. > + * Add the pipelined eviction fencesto the BO as kernel dependency and reserve new > + * fence slots. > */ > -static int ttm_bo_add_move_fence(struct ttm_buffer_object *bo, > - struct ttm_resource_manager *man, > - bool no_wait_gpu) > +static int ttm_bo_add_pipelined_eviction_fences(struct ttm_buffer_object *bo, > + struct ttm_resource_manager *man, > + bool no_wait_gpu) > { > struct dma_fence *fence; > - int ret; > + int i; > > - spin_lock(&man->move_lock); > - fence = dma_fence_get(man->move); > - spin_unlock(&man->move_lock); > + spin_lock(&man->eviction_lock); > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) { > + fence = man->eviction_fences[i]; > + if (!fence) > + continue; > > - if (!fence) > - return 0; > - > - if (no_wait_gpu) { > - ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY; > - dma_fence_put(fence); > - return ret; > + if (no_wait_gpu) { > + if (!dma_fence_is_signaled(fence)) { > + spin_unlock(&man->eviction_lock); > + return -EBUSY; > + } > + } else { > + dma_resv_add_fence(bo->base.resv, fence, DMA_RESV_USAGE_KERNEL); > + } > } > + spin_unlock(&man->eviction_lock); > > - dma_resv_add_fence(bo->base.resv, fence, DMA_RESV_USAGE_KERNEL); > - > - ret = dma_resv_reserve_fences(bo->base.resv, 1); > - dma_fence_put(fence); > - return ret; > + /* TODO: this call should be removed. */ > + return dma_resv_reserve_fences(bo->base.resv, 1); > } > > /** > @@ -718,7 +719,7 @@ static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo, > int i, ret; > > ticket = dma_resv_locking_ctx(bo->base.resv); > - ret = dma_resv_reserve_fences(bo->base.resv, 1); > + ret = dma_resv_reserve_fences(bo->base.resv, TTM_NUM_MOVE_FENCES); > if (unlikely(ret)) > return ret; > > @@ -757,7 +758,7 @@ static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo, > return ret; > } > > - ret = ttm_bo_add_move_fence(bo, man, ctx->no_wait_gpu); > + ret = ttm_bo_add_pipelined_eviction_fences(bo, man, ctx->no_wait_gpu); > if (unlikely(ret)) { > ttm_resource_free(bo, res); > if (ret == -EBUSY) > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c > index acbbca9d5c92..2ff35d55e462 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > @@ -258,7 +258,7 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, > ret = dma_resv_trylock(&fbo->base.base._resv); > WARN_ON(!ret); > > - ret = dma_resv_reserve_fences(&fbo->base.base._resv, 1); > + ret = dma_resv_reserve_fences(&fbo->base.base._resv, TTM_NUM_MOVE_FENCES); > if (ret) { > dma_resv_unlock(&fbo->base.base._resv); > kfree(fbo); > @@ -646,20 +646,44 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, > { > struct ttm_device *bdev = bo->bdev; > struct ttm_resource_manager *from; > + struct dma_fence *tmp; > + int i; > > from = ttm_manager_type(bdev, bo->resource->mem_type); > > /** > * BO doesn't have a TTM we need to bind/unbind. Just remember > - * this eviction and free up the allocation > + * this eviction and free up the allocation. > + * The fence will be saved in the first free slot or in the slot > + * already used to store a fence from the same context. Since > + * drivers can't use more than TTM_NUM_MOVE_FENCES contexts for > + * evictions we should always find a slot to use. > */ > - spin_lock(&from->move_lock); > - if (!from->move || dma_fence_is_later(fence, from->move)) { > - dma_fence_put(from->move); > - from->move = dma_fence_get(fence); > + spin_lock(&from->eviction_lock); > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) { > + tmp = from->eviction_fences[i]; > + if (!tmp) > + break; > + if (fence->context != tmp->context) > + continue; > + if (dma_fence_is_later(fence, tmp)) { > + dma_fence_put(tmp); > + break; > + } > + goto unlock; > + } > + if (i < TTM_NUM_MOVE_FENCES) { > + from->eviction_fences[i] = dma_fence_get(fence); > + } else { > + WARN(1, "not enough fence slots for all fence contexts"); > + spin_unlock(&from->eviction_lock); > + dma_fence_wait(fence, false); > + goto end; > } > - spin_unlock(&from->move_lock); > > +unlock: > + spin_unlock(&from->eviction_lock); > +end: > ttm_resource_free(bo, &bo->resource); > } > > diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c > index e2c82ad07eb4..62c34cafa387 100644 > --- a/drivers/gpu/drm/ttm/ttm_resource.c > +++ b/drivers/gpu/drm/ttm/ttm_resource.c > @@ -523,14 +523,15 @@ void ttm_resource_manager_init(struct ttm_resource_manager *man, > { > unsigned i; > > - spin_lock_init(&man->move_lock); > man->bdev = bdev; > man->size = size; > man->usage = 0; > > for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) > INIT_LIST_HEAD(&man->lru[i]); > - man->move = NULL; > + spin_lock_init(&man->eviction_lock); > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) > + man->eviction_fences[i] = NULL; > } > EXPORT_SYMBOL(ttm_resource_manager_init); > > @@ -551,7 +552,7 @@ int ttm_resource_manager_evict_all(struct ttm_device *bdev, > .no_wait_gpu = false, > }; > struct dma_fence *fence; > - int ret; > + int ret, i; > > do { > ret = ttm_bo_evict_first(bdev, man, &ctx); > @@ -561,18 +562,24 @@ int ttm_resource_manager_evict_all(struct ttm_device *bdev, > if (ret && ret != -ENOENT) > return ret; > > - spin_lock(&man->move_lock); > - fence = dma_fence_get(man->move); > - spin_unlock(&man->move_lock); > + ret = 0; > > - if (fence) { > - ret = dma_fence_wait(fence, false); > - dma_fence_put(fence); > - if (ret) > - return ret; > + spin_lock(&man->eviction_lock); > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) { > + fence = man->eviction_fences[i]; > + if (fence && !dma_fence_is_signaled(fence)) { > + dma_fence_get(fence); > + spin_unlock(&man->eviction_lock); > + ret = dma_fence_wait(fence, false); > + dma_fence_put(fence); > + if (ret) > + return ret; > + spin_lock(&man->eviction_lock); > + } > } > + spin_unlock(&man->eviction_lock); > > - return 0; > + return ret; > } > EXPORT_SYMBOL(ttm_resource_manager_evict_all); > > diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h > index f49daa504c36..50e6added509 100644 > --- a/include/drm/ttm/ttm_resource.h > +++ b/include/drm/ttm/ttm_resource.h > @@ -50,6 +50,15 @@ struct io_mapping; > struct sg_table; > struct scatterlist; > > +/** > + * define TTM_NUM_MOVE_FENCES - How many entities can be used for evictions > + * > + * Pipelined evictions can be spread on multiple entities. This > + * is the max number of entities that can be used by the driver > + * for that purpose. > + */ > +#define TTM_NUM_MOVE_FENCES 8 > + > /** > * enum ttm_lru_item_type - enumerate ttm_lru_item subclasses > */ > @@ -180,8 +189,8 @@ struct ttm_resource_manager_func { > * @size: Size of the managed region. > * @bdev: ttm device this manager belongs to > * @func: structure pointer implementing the range manager. See above > - * @move_lock: lock for move fence > - * @move: The fence of the last pipelined move operation. > + * @eviction_lock: lock for eviction fences > + * @eviction_fences: The fences of the last pipelined move operation. > * @lru: The lru list for this memory type. > * > * This structure is used to identify and manage memory types for a device. > @@ -195,12 +204,12 @@ struct ttm_resource_manager { > struct ttm_device *bdev; > uint64_t size; > const struct ttm_resource_manager_func *func; > - spinlock_t move_lock; > > - /* > - * Protected by @move_lock. > + /* This is very similar to a dma_resv object, but locking rules make > + * it difficult to use one in this context. > */ > - struct dma_fence *move; > + spinlock_t eviction_lock; > + struct dma_fence *eviction_fences[TTM_NUM_MOVE_FENCES]; > > /* > * Protected by the bdev->lru_lock. > @@ -421,8 +430,12 @@ static inline bool ttm_resource_manager_used(struct ttm_resource_manager *man) > static inline void > ttm_resource_manager_cleanup(struct ttm_resource_manager *man) > { > - dma_fence_put(man->move); > - man->move = NULL; > + int i; > + > + for (i = 0; i < TTM_NUM_MOVE_FENCES; i++) { > + dma_fence_put(man->eviction_fences[i]); > + man->eviction_fences[i] = NULL; > + } > } > > void ttm_lru_bulk_move_init(struct ttm_lru_bulk_move *bulk);

1 month

1
0
0 0

Independence for dma_fences! v3

by Christian König

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. Please review and comment, Christian.

1 month

2
21
0 0

Re: [PATCH v2 19/21] scsi: fnic: Switch to use %ptS

by kernel test robot

Hi Andy, kernel test robot noticed the following build errors: [auto build test ERROR on ceph-client/testing] [also build test ERROR on ceph-client/for-linus cminyard-ipmi/for-next mkp-scsi/for-next jejb-scsi/for-next linus/master v6.18-rc5 next-20251112] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/lib-vsprintf… base: https://github.com/ceph/ceph-client.git testing patch link: https://lore.kernel.org/r/20251111122735.880607-20-andriy.shevchenko%40linu… patch subject: [PATCH v2 19/21] scsi: fnic: Switch to use %ptS config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251113/202511130449.Q1mCZRpT-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251113/202511130449.Q1mCZRpT-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202511130449.Q1mCZRpT-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/scsi/fnic/fnic_trace.c:234:2: error: cannot take the address of an rvalue of type 'struct timespec64' 234 | &timespec64_sub(val1, stats->stats_timestamps.last_reset_time), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/scsi/fnic/fnic_trace.c:235:2: error: cannot take the address of an rvalue of type 'struct timespec64' 235 | &timespec64_sub(val1, stats->stats_timestamps.last_read_time)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. vim +234 drivers/scsi/fnic/fnic_trace.c 198 199 /* 200 * fnic_get_stats_data - Copy fnic stats buffer to a memory file 201 * @fnic_dbgfs_t: pointer to debugfs fnic stats buffer 202 * 203 * Description: 204 * This routine gathers the fnic stats debugfs data from the fnic_stats struct 205 * and dumps it to stats_debug_info. 206 * 207 * Return Value: 208 * This routine returns the amount of bytes that were dumped into 209 * stats_debug_info 210 */ 211 int fnic_get_stats_data(struct stats_debug_info *debug, 212 struct fnic_stats *stats) 213 { 214 int len = 0; 215 int buf_size = debug->buf_size; 216 struct timespec64 val1, val2; 217 int i = 0; 218 219 ktime_get_real_ts64(&val1); 220 len = scnprintf(debug->debug_buffer + len, buf_size - len, 221 "------------------------------------------\n" 222 "\t\tTime\n" 223 "------------------------------------------\n"); 224 225 len += scnprintf(debug->debug_buffer + len, buf_size - len, 226 "Current time : [%ptSp]\n" 227 "Last stats reset time: [%ptSp]\n" 228 "Last stats read time: [%ptSp]\n" 229 "delta since last reset: [%ptSp]\n" 230 "delta since last read: [%ptSp]\n", 231 &val1, 232 &stats->stats_timestamps.last_reset_time, 233 &stats->stats_timestamps.last_read_time, > 234 &timespec64_sub(val1, stats->stats_timestamps.last_reset_time), 235 &timespec64_sub(val1, stats->stats_timestamps.last_read_time)); 236 237 stats->stats_timestamps.last_read_time = val1; 238 239 len += scnprintf(debug->debug_buffer + len, buf_size - len, 240 "------------------------------------------\n" 241 "\t\tIO Statistics\n" 242 "------------------------------------------\n"); 243 len += scnprintf(debug->debug_buffer + len, buf_size - len, 244 "Number of Active IOs: %lld\nMaximum Active IOs: %lld\n" 245 "Number of IOs: %lld\nNumber of IO Completions: %lld\n" 246 "Number of IO Failures: %lld\nNumber of IO NOT Found: %lld\n" 247 "Number of Memory alloc Failures: %lld\n" 248 "Number of IOREQ Null: %lld\n" 249 "Number of SCSI cmd pointer Null: %lld\n" 250 251 "\nIO completion times: \n" 252 " < 10 ms : %lld\n" 253 " 10 ms - 100 ms : %lld\n" 254 " 100 ms - 500 ms : %lld\n" 255 " 500 ms - 5 sec: %lld\n" 256 " 5 sec - 10 sec: %lld\n" 257 " 10 sec - 30 sec: %lld\n" 258 " > 30 sec: %lld\n", 259 (u64)atomic64_read(&stats->io_stats.active_ios), 260 (u64)atomic64_read(&stats->io_stats.max_active_ios), 261 (u64)atomic64_read(&stats->io_stats.num_ios), 262 (u64)atomic64_read(&stats->io_stats.io_completions), 263 (u64)atomic64_read(&stats->io_stats.io_failures), 264 (u64)atomic64_read(&stats->io_stats.io_not_found), 265 (u64)atomic64_read(&stats->io_stats.alloc_failures), 266 (u64)atomic64_read(&stats->io_stats.ioreq_null), 267 (u64)atomic64_read(&stats->io_stats.sc_null), 268 (u64)atomic64_read(&stats->io_stats.io_btw_0_to_10_msec), 269 (u64)atomic64_read(&stats->io_stats.io_btw_10_to_100_msec), 270 (u64)atomic64_read(&stats->io_stats.io_btw_100_to_500_msec), 271 (u64)atomic64_read(&stats->io_stats.io_btw_500_to_5000_msec), 272 (u64)atomic64_read(&stats->io_stats.io_btw_5000_to_10000_msec), 273 (u64)atomic64_read(&stats->io_stats.io_btw_10000_to_30000_msec), 274 (u64)atomic64_read(&stats->io_stats.io_greater_than_30000_msec)); 275 276 len += scnprintf(debug->debug_buffer + len, buf_size - len, 277 "------------------------------------------\n" 278 "\t\tIO Queues and cumulative IOs\n" 279 "------------------------------------------\n"); 280 281 for (i = 0; i < FNIC_MQ_MAX_QUEUES; i++) { 282 len += scnprintf(debug->debug_buffer + len, buf_size - len, 283 "Q:%d -> %lld\n", i, (u64)atomic64_read(&stats->io_stats.ios[i])); 284 } 285 286 len += scnprintf(debug->debug_buffer + len, buf_size - len, 287 "\nCurrent Max IO time : %lld\n", 288 (u64)atomic64_read(&stats->io_stats.current_max_io_time)); 289 290 len += scnprintf(debug->debug_buffer + len, buf_size - len, 291 "\n------------------------------------------\n" 292 "\t\tAbort Statistics\n" 293 "------------------------------------------\n"); 294 295 len += scnprintf(debug->debug_buffer + len, buf_size - len, 296 "Number of Aborts: %lld\n" 297 "Number of Abort Failures: %lld\n" 298 "Number of Abort Driver Timeouts: %lld\n" 299 "Number of Abort FW Timeouts: %lld\n" 300 "Number of Abort IO NOT Found: %lld\n" 301 302 "Abort issued times: \n" 303 " < 6 sec : %lld\n" 304 " 6 sec - 20 sec : %lld\n" 305 " 20 sec - 30 sec : %lld\n" 306 " 30 sec - 40 sec : %lld\n" 307 " 40 sec - 50 sec : %lld\n" 308 " 50 sec - 60 sec : %lld\n" 309 " > 60 sec: %lld\n", 310 311 (u64)atomic64_read(&stats->abts_stats.aborts), 312 (u64)atomic64_read(&stats->abts_stats.abort_failures), 313 (u64)atomic64_read(&stats->abts_stats.abort_drv_timeouts), 314 (u64)atomic64_read(&stats->abts_stats.abort_fw_timeouts), 315 (u64)atomic64_read(&stats->abts_stats.abort_io_not_found), 316 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_0_to_6_sec), 317 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_6_to_20_sec), 318 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_20_to_30_sec), 319 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_30_to_40_sec), 320 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_40_to_50_sec), 321 (u64)atomic64_read(&stats->abts_stats.abort_issued_btw_50_to_60_sec), 322 (u64)atomic64_read(&stats->abts_stats.abort_issued_greater_than_60_sec)); 323 324 len += scnprintf(debug->debug_buffer + len, buf_size - len, 325 "\n------------------------------------------\n" 326 "\t\tTerminate Statistics\n" 327 "------------------------------------------\n"); 328 329 len += scnprintf(debug->debug_buffer + len, buf_size - len, 330 "Number of Terminates: %lld\n" 331 "Maximum Terminates: %lld\n" 332 "Number of Terminate Driver Timeouts: %lld\n" 333 "Number of Terminate FW Timeouts: %lld\n" 334 "Number of Terminate IO NOT Found: %lld\n" 335 "Number of Terminate Failures: %lld\n", 336 (u64)atomic64_read(&stats->term_stats.terminates), 337 (u64)atomic64_read(&stats->term_stats.max_terminates), 338 (u64)atomic64_read(&stats->term_stats.terminate_drv_timeouts), 339 (u64)atomic64_read(&stats->term_stats.terminate_fw_timeouts), 340 (u64)atomic64_read(&stats->term_stats.terminate_io_not_found), 341 (u64)atomic64_read(&stats->term_stats.terminate_failures)); 342 343 len += scnprintf(debug->debug_buffer + len, buf_size - len, 344 "\n------------------------------------------\n" 345 "\t\tReset Statistics\n" 346 "------------------------------------------\n"); 347 348 len += scnprintf(debug->debug_buffer + len, buf_size - len, 349 "Number of Device Resets: %lld\n" 350 "Number of Device Reset Failures: %lld\n" 351 "Number of Device Reset Aborts: %lld\n" 352 "Number of Device Reset Timeouts: %lld\n" 353 "Number of Device Reset Terminates: %lld\n" 354 "Number of FW Resets: %lld\n" 355 "Number of FW Reset Completions: %lld\n" 356 "Number of FW Reset Failures: %lld\n" 357 "Number of Fnic Reset: %lld\n" 358 "Number of Fnic Reset Completions: %lld\n" 359 "Number of Fnic Reset Failures: %lld\n", 360 (u64)atomic64_read(&stats->reset_stats.device_resets), 361 (u64)atomic64_read(&stats->reset_stats.device_reset_failures), 362 (u64)atomic64_read(&stats->reset_stats.device_reset_aborts), 363 (u64)atomic64_read(&stats->reset_stats.device_reset_timeouts), 364 (u64)atomic64_read( 365 &stats->reset_stats.device_reset_terminates), 366 (u64)atomic64_read(&stats->reset_stats.fw_resets), 367 (u64)atomic64_read(&stats->reset_stats.fw_reset_completions), 368 (u64)atomic64_read(&stats->reset_stats.fw_reset_failures), 369 (u64)atomic64_read(&stats->reset_stats.fnic_resets), 370 (u64)atomic64_read( 371 &stats->reset_stats.fnic_reset_completions), 372 (u64)atomic64_read(&stats->reset_stats.fnic_reset_failures)); 373 374 len += scnprintf(debug->debug_buffer + len, buf_size - len, 375 "\n------------------------------------------\n" 376 "\t\tFirmware Statistics\n" 377 "------------------------------------------\n"); 378 379 len += scnprintf(debug->debug_buffer + len, buf_size - len, 380 "Number of Active FW Requests %lld\n" 381 "Maximum FW Requests: %lld\n" 382 "Number of FW out of resources: %lld\n" 383 "Number of FW IO errors: %lld\n", 384 (u64)atomic64_read(&stats->fw_stats.active_fw_reqs), 385 (u64)atomic64_read(&stats->fw_stats.max_fw_reqs), 386 (u64)atomic64_read(&stats->fw_stats.fw_out_of_resources), 387 (u64)atomic64_read(&stats->fw_stats.io_fw_errs)); 388 389 len += scnprintf(debug->debug_buffer + len, buf_size - len, 390 "\n------------------------------------------\n" 391 "\t\tVlan Discovery Statistics\n" 392 "------------------------------------------\n"); 393 394 len += scnprintf(debug->debug_buffer + len, buf_size - len, 395 "Number of Vlan Discovery Requests Sent %lld\n" 396 "Vlan Response Received with no FCF VLAN ID: %lld\n" 397 "No solicitations recvd after vlan set, expiry count: %lld\n" 398 "Flogi rejects count: %lld\n", 399 (u64)atomic64_read(&stats->vlan_stats.vlan_disc_reqs), 400 (u64)atomic64_read(&stats->vlan_stats.resp_withno_vlanID), 401 (u64)atomic64_read(&stats->vlan_stats.sol_expiry_count), 402 (u64)atomic64_read(&stats->vlan_stats.flogi_rejects)); 403 404 len += scnprintf(debug->debug_buffer + len, buf_size - len, 405 "\n------------------------------------------\n" 406 "\t\tOther Important Statistics\n" 407 "------------------------------------------\n"); 408 409 jiffies_to_timespec64(stats->misc_stats.last_isr_time, &val1); 410 jiffies_to_timespec64(stats->misc_stats.last_ack_time, &val2); 411 412 len += scnprintf(debug->debug_buffer + len, buf_size - len, 413 "Last ISR time: %llu (%ptSp)\n" 414 "Last ACK time: %llu (%ptSp)\n" 415 "Max ISR jiffies: %llu\n" 416 "Max ISR time (ms) (0 denotes < 1 ms): %llu\n" 417 "Corr. work done: %llu\n" 418 "Number of ISRs: %lld\n" 419 "Maximum CQ Entries: %lld\n" 420 "Number of ACK index out of range: %lld\n" 421 "Number of data count mismatch: %lld\n" 422 "Number of FCPIO Timeouts: %lld\n" 423 "Number of FCPIO Aborted: %lld\n" 424 "Number of SGL Invalid: %lld\n" 425 "Number of Copy WQ Alloc Failures for ABTs: %lld\n" 426 "Number of Copy WQ Alloc Failures for Device Reset: %lld\n" 427 "Number of Copy WQ Alloc Failures for IOs: %lld\n" 428 "Number of no icmnd itmf Completions: %lld\n" 429 "Number of Check Conditions encountered: %lld\n" 430 "Number of QUEUE Fulls: %lld\n" 431 "Number of rport not ready: %lld\n" 432 "Number of receive frame errors: %lld\n" 433 "Port speed (in Mbps): %lld\n", 434 (u64)stats->misc_stats.last_isr_time, 435 &val1, 436 (u64)stats->misc_stats.last_ack_time, 437 &val2, 438 (u64)atomic64_read(&stats->misc_stats.max_isr_jiffies), 439 (u64)atomic64_read(&stats->misc_stats.max_isr_time_ms), 440 (u64)atomic64_read(&stats->misc_stats.corr_work_done), 441 (u64)atomic64_read(&stats->misc_stats.isr_count), 442 (u64)atomic64_read(&stats->misc_stats.max_cq_entries), 443 (u64)atomic64_read(&stats->misc_stats.ack_index_out_of_range), 444 (u64)atomic64_read(&stats->misc_stats.data_count_mismatch), 445 (u64)atomic64_read(&stats->misc_stats.fcpio_timeout), 446 (u64)atomic64_read(&stats->misc_stats.fcpio_aborted), 447 (u64)atomic64_read(&stats->misc_stats.sgl_invalid), 448 (u64)atomic64_read( 449 &stats->misc_stats.abts_cpwq_alloc_failures), 450 (u64)atomic64_read( 451 &stats->misc_stats.devrst_cpwq_alloc_failures), 452 (u64)atomic64_read(&stats->misc_stats.io_cpwq_alloc_failures), 453 (u64)atomic64_read(&stats->misc_stats.no_icmnd_itmf_cmpls), 454 (u64)atomic64_read(&stats->misc_stats.check_condition), 455 (u64)atomic64_read(&stats->misc_stats.queue_fulls), 456 (u64)atomic64_read(&stats->misc_stats.tport_not_ready), 457 (u64)atomic64_read(&stats->misc_stats.frame_errors), 458 (u64)atomic64_read(&stats->misc_stats.port_speed_in_mbps)); 459 460 return len; 461 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 month

1
0
0 0

Re: [PATCH v2 19/21] scsi: fnic: Switch to use %ptS

by Martin K. Petersen

Andy, > Use %ptS instead of open coded variants to print content of > struct timespec64 in human readable format. Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> -- Martin K. Petersen

1 month

1
0
0 0

Re: [PATCH v2 20/21] scsi: snic: Switch to use %ptSp

by Martin K. Petersen

Andy, > Use %ptSp instead of open coded variants to print content of > struct timespec64 in human readable format. Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> -- Martin K. Petersen

1 month

1
0
0 0

Re: [PATCH net-next v2 4/7] net: ethernet: ti: am65-cpsw: Add AF_XDP zero copy for RX

by Jakub Kicinski

On Sun, 09 Nov 2025 23:37:54 +0200 Roger Quadros wrote: > + ndev->stats.rx_dropped++; AFAIU the device is multi-queue so using per-device stats looks racy. Please create your own per queue stats.

1 month

1
0
0 0

Re: [PATCH net-next v2 7/7] net: ethernet: ti: am65-cpsw: Fix clearing of irq_disabled flag in rx_poll

by Jakub Kicinski

On Sun, 09 Nov 2025 23:37:57 +0200 Roger Quadros wrote: > In am65_cpsw_nuss_rx_poll() there is a possibility that irq_disabled flag > is cleared but the IRQ is not enabled. > > This patch fixes by that by clearing irq_disabled flag right when enabling > the irq. > > Fixes: da70d184a8c3 ("net: ethernet: ti: am65-cpsw: Introduce multi queue Rx") > Signed-off-by: Roger Quadros <rogerq(a)kernel.org> This looks independent from the series, it needs to go to net. -- pw-bot: cr

1 month

1
0
0 0

Re: [PATCH net-next v2 0/7] net: ethernet: ti: am65-cpsw: add AF_XDP zero copy support

by Jakub Kicinski

On Sun, 09 Nov 2025 23:37:50 +0200 Roger Quadros wrote: > This series adds AF_XDP zero coppy support to am65-cpsw driver. > > Tests were performed on AM62x-sk with xdpsock application [1]. > > A clear improvement is seen in 64 byte packets on Transmit (txonly) > and receive (rxdrop). > 1500 byte test seems to be limited by line rate (1G link) so no > improvement seen there in packet rate. A test on higher speed link > (or PHY-less setup) might be worthwile. > > There is some issue during l2fwd with 64 byte packets and benchmark > results show 0. This issue needs to be debugged further. > A 512 byte l2fwd test result has been added to compare instead. It appears that the drivers/net/ethernet/ti/am65-* files do not fall under any MAINTAINERS entry. Please add one or extend the existing CPSW entry as the first patch of the series.

1 month

1
0
0 0

Re: [PATCH v2 04/21] dma-buf: Switch to use %ptSp

by Sumit Semwal

Hello Andy, On Tue, 11 Nov 2025 at 17:57, Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> wrote: > > Use %ptSp instead of open coded variants to print content of > struct timespec64 in human readable format. > > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Thanks for the patch. FWIW, please feel free to add Acked-by: Sumit Semwal <sumit.semwal(a)linaro.org> Best, Sumit. > --- > drivers/dma-buf/sync_debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c > index 67cd69551e42..9e5d662cd4e8 100644 > --- a/drivers/dma-buf/sync_debug.c > +++ b/drivers/dma-buf/sync_debug.c > @@ -59,7 +59,7 @@ static void sync_print_fence(struct seq_file *s, > struct timespec64 ts64 = > ktime_to_timespec64(fence->timestamp); > > - seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec); > + seq_printf(s, "@%ptSp", &ts64); > } > > seq_printf(s, ": %lld", fence->seqno); > -- > 2.50.1 >

1 month

1
0
0 0

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

by Christian König

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. Christian. > > Alex

1 month

1
0
0 0

Re: [PATCH v1 12/23] ipmi: Switch to use %ptSp

by Sergey Senozhatsky

On (25/11/10 19:40), Andy Shevchenko wrote: [..] > + dev_dbg(smi_info->io.dev, "**%s: %ptSp\n", msg, &t); Strictly speaking, this is not exactly equivalent to %lld.%9.9ld or %lld.%6.6ld but I don't know if that's of any importance.

1 month

1
0
0 0

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

by Leon Romanovsky

On Mon, Nov 10, 2025 at 01:05:34PM -0700, Alex Williamson wrote: > On Thu, 6 Nov 2025 16:16:56 +0200 > Leon Romanovsky <leon(a)kernel.org> wrote: > > > From: Jason Gunthorpe <jgg(a)nvidia.com> > > > > Call vfio_pci_core_fill_phys_vec() with the proper physical ranges for the > > synthetic BAR 2 and BAR 4 regions. Otherwise use the normal flow based on > > the PCI bar. > > > > This demonstrates a DMABUF that follows the region info report to only > > allow mapping parts of the region that are mmapable. Since the BAR is > > power of two sized and the "CXL" region is just page aligned the there can > > be a padding region at the end that is not mmaped or passed into the > > DMABUF. > > > > The "CXL" ranges that are remapped into BAR 2 and BAR 4 areas are not PCI > > MMIO, they actually run over the CXL-like coherent interconnect and for > > the purposes of DMA behave identically to DRAM. We don't try to model this > > distinction between true PCI BAR memory that takes a real PCI path and the > > "CXL" memory that takes a different path in the p2p framework for now. > > > > Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> > > Tested-by: Alex Mastro <amastro(a)fb.com> > > Tested-by: Nicolin Chen <nicolinc(a)nvidia.com> > > Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> > > --- > > drivers/vfio/pci/nvgrace-gpu/main.c | 56 +++++++++++++++++++++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > > > diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c b/drivers/vfio/pci/nvgrace-gpu/main.c > > index e346392b72f6..7d7ab2c84018 100644 > > --- a/drivers/vfio/pci/nvgrace-gpu/main.c > > +++ b/drivers/vfio/pci/nvgrace-gpu/main.c > > @@ -7,6 +7,7 @@ > > #include <linux/vfio_pci_core.h> > > #include <linux/delay.h> > > #include <linux/jiffies.h> > > +#include <linux/pci-p2pdma.h> > > > > /* > > * The device memory usable to the workloads running in the VM is cached > > @@ -683,6 +684,54 @@ nvgrace_gpu_write(struct vfio_device *core_vdev, > > return vfio_pci_core_write(core_vdev, buf, count, ppos); > > } > > > > +static int nvgrace_get_dmabuf_phys(struct vfio_pci_core_device *core_vdev, > > + struct p2pdma_provider **provider, > > + unsigned int region_index, > > + struct dma_buf_phys_vec *phys_vec, > > + struct vfio_region_dma_range *dma_ranges, > > + size_t nr_ranges) > > +{ > > + struct nvgrace_gpu_pci_core_device *nvdev = container_of( > > + core_vdev, struct nvgrace_gpu_pci_core_device, core_device); > > + struct pci_dev *pdev = core_vdev->pdev; > > + > > + 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. > > + */ > > + *provider = pcim_p2pdma_provider(pdev, 0); > > + if (!*provider) > > + return -EINVAL; > > + return vfio_pci_core_fill_phys_vec(phys_vec, dma_ranges, > > + nr_ranges, > > + nvdev->resmem.memphys, > > + nvdev->resmem.memlength); > > + } 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. > > + */ > > + *provider = pcim_p2pdma_provider(pdev, 0); > > + if (!*provider) > > + return -EINVAL; > > + return vfio_pci_core_fill_phys_vec(phys_vec, dma_ranges, > > + nr_ranges, > > + nvdev->usemem.memphys, > > + nvdev->usemem.memlength); > > + } > > + return vfio_pci_core_get_dmabuf_phys(core_vdev, provider, region_index, > > + phys_vec, dma_ranges, nr_ranges); > > +} > > > Unless my eyes deceive, we could reduce the redundancy a bit: > > struct mem_region *mem_region = NULL; > > 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; > } > > if (mem_region) { > *provider = pcim_p2pdma_provider(pdev, 0); > if (!*provider) > return -EINVAL; > return vfio_pci_core_fill_phys_vec(phys_vec, dma_ranges, > nr_ranges, > mem_region->memphys, > mem_region->memlength); > } > > return vfio_pci_core_get_dmabuf_phys(core_vdev, provider, region_index, > phys_vec, dma_ranges, nr_ranges); Yes, this will work too. Thanks > > Thanks, > Alex

1 month

1
0
0 0

Re: [PATCH v1 23/23] tracing: Switch to use %ptSp

by Steven Rostedt

On Mon, 10 Nov 2025 19:40:42 +0100 Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> wrote: > Use %ptSp instead of open coded variants to print content of > struct timespec64 in human readable format. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > --- > kernel/trace/trace_output.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Acked-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> -- Steve

1 month

1
0
0 0

Re: [PATCH v1 05/23] dma-buf: Switch to use %ptSp

by Christian König

On 11/10/25 19:40, Andy Shevchenko wrote: > Use %ptSp instead of open coded variants to print content of > struct timespec64 in human readable format. > > Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/sync_debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c > index 67cd69551e42..9e5d662cd4e8 100644 > --- a/drivers/dma-buf/sync_debug.c > +++ b/drivers/dma-buf/sync_debug.c > @@ -59,7 +59,7 @@ static void sync_print_fence(struct seq_file *s, > struct timespec64 ts64 = > ktime_to_timespec64(fence->timestamp); > > - seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec); > + seq_printf(s, "@%ptSp", &ts64); > } > > seq_printf(s, ": %lld", fence->seqno);

1 month

1
0
0 0

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

by Leon Romanovsky

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. v6: https://patch.msgid.link/20251102-dmabuf-vfio-v6-0-d773cff0db9f@nvidia.com * Fixed wrong error check from pcim_p2pdma_init(). * Documented pcim_p2pdma_provider() function. * Improved commit messages. * Added VFIO DMA-BUF selftest, not sent yet. * Added __counted_by(nr_ranges) annotation to struct vfio_device_feature_dma_buf. * Fixed error unwind when dma_buf_fd() fails. * Document latest changes to p2pmem. * Removed EXPORT_SYMBOL_GPL from pci_p2pdma_map_type. * Moved DMA mapping logic to DMA-BUF. * Removed types patch to avoid dependencies between subsystems. * Moved vfio_pci_dma_buf_move() in err_undo block. * Added nvgrace patch. v5: https://lore.kernel.org/all/cover.1760368250.git.leon@kernel.org * Rebased on top of v6.18-rc1. * Added more validation logic to make sure that DMA-BUF length doesn't overflow in various scenarios. * Hide kernel config from the users. * Fixed type conversion issue. DMA ranges are exposed with u64 length, but DMA-BUF uses "unsigned int" as a length for SG entries. * Added check to prevent from VFIO drivers which reports BAR size different from PCI, do not use DMA-BUF functionality. v4: https://lore.kernel.org/all/cover.1759070796.git.leon@kernel.org * Split pcim_p2pdma_provider() to two functions, one that initializes array of providers and another to return right provider pointer. v3: https://lore.kernel.org/all/cover.1758804980.git.leon@kernel.org * Changed pcim_p2pdma_enable() to be pcim_p2pdma_provider(). * Cache provider in vfio_pci_dma_buf struct instead of BAR index. * Removed misleading comment from pcim_p2pdma_provider(). * Moved MMIO check to be in pcim_p2pdma_provider(). v2: https://lore.kernel.org/all/cover.1757589589.git.leon@kernel.org/ * Added extra patch which adds new CONFIG, so next patches can reuse * it. * Squashed "PCI/P2PDMA: Remove redundant bus_offset from map state" into the other patch. * Fixed revoke calls to be aligned with true->false semantics. * Extended p2pdma_providers to be per-BAR and not global to whole * device. * Fixed possible race between dmabuf states and revoke. * Moved revoke to PCI BAR zap block. v1: https://lore.kernel.org/all/cover.1754311439.git.leon@kernel.org * Changed commit messages. * Reused DMA_ATTR_MMIO attribute. * Returned support for multiple DMA ranges per-dMABUF. v0: https://lore.kernel.org/all/cover.1753274085.git.leonro@nvidia.com --------------------------------------------------------------------------- Based on "[PATCH v6 00/16] dma-mapping: migrate to physical address-based API" https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com/ series. --------------------------------------------------------------------------- This series extends the VFIO PCI subsystem to support exporting MMIO regions from PCI device BARs as dma-buf objects, enabling safe sharing of non-struct page memory with controlled lifetime management. This allows RDMA and other subsystems to import dma-buf FDs and build them into memory regions for PCI P2P operations. The series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. This dmabuf approach can be usable by iommufd as well for generic and safe P2P mappings. In addition to the SPDK use-case mentioned above, the capability added in this patch series can also be useful when a buffer (located in device memory such as VRAM) needs to be shared between any two dGPU devices or instances (assuming one of them is bound to VFIO PCI) as long as they are P2P DMA compatible. The implementation provides a revocable attachment mechanism using dma-buf move operations. MMIO regions are normally pinned as BARs don't change physical addresses, but access is revoked when the VFIO device is closed or a PCI reset is issued. This ensures kernel self-defense against potentially hostile userspace. The series includes significant refactoring of the PCI P2PDMA subsystem to separate core P2P functionality from memory allocation features, making it more modular and suitable for VFIO use cases that don't need struct page support. ----------------------------------------------------------------------- The series is based originally on https://lore.kernel.org/all/20250307052248.405803-1-vivek.kasireddy@intel.c… but heavily rewritten to be based on DMA physical API. ----------------------------------------------------------------------- The WIP branch can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=… Thanks --- Jason Gunthorpe (2): PCI/P2PDMA: Document DMABUF model vfio/nvgrace: Support get_dmabuf_phys Leon Romanovsky (7): PCI/P2PDMA: Separate the mmap() support from the core logic PCI/P2PDMA: Simplify bus address mapping API PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation PCI/P2PDMA: Provide an access to pci_p2pdma_map_type() function dma-buf: provide phys_vec to scatter-gather mapping routine vfio/pci: Enable peer-to-peer DMA transactions by default vfio/pci: Add dma-buf export support for MMIO regions Vivek Kasireddy (2): vfio: Export vfio device get and put registration helpers vfio/pci: Share the core device pointer while invoking feature functions Documentation/driver-api/pci/p2pdma.rst | 95 +++++++--- block/blk-mq-dma.c | 2 +- drivers/dma-buf/dma-buf.c | 235 ++++++++++++++++++++++++ drivers/iommu/dma-iommu.c | 4 +- drivers/pci/p2pdma.c | 182 +++++++++++++----- drivers/vfio/pci/Kconfig | 3 + drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/nvgrace-gpu/main.c | 56 ++++++ drivers/vfio/pci/vfio_pci.c | 5 + drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c | 53 ++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 315 ++++++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_priv.h | 23 +++ drivers/vfio/vfio_main.c | 2 + include/linux/dma-buf.h | 18 ++ include/linux/pci-p2pdma.h | 120 +++++++----- include/linux/vfio.h | 2 + include/linux/vfio_pci_core.h | 42 +++++ include/uapi/linux/vfio.h | 28 +++ kernel/dma/direct.c | 4 +- mm/hmm.c | 2 +- 21 files changed, 1074 insertions(+), 140 deletions(-) --- base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa change-id: 20251016-dmabuf-vfio-6cef732adf5a Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 month, 1 week

2
15
0 0

[PATCH 0/9] Initial DMABUF support for iommufd

by Jason Gunthorpe

This series is the start of adding full DMABUF support to iommufd. Currently it is limited to only work with VFIO's DMABUF exporter. It sits on top of Leon's series to add a DMABUF exporter to VFIO: https://lore.kernel.org/r/20251106-dmabuf-vfio-v7-0-2503bf390699@nvidia.com The existing IOMMU_IOAS_MAP_FILE is enhanced to detect DMABUF fd's, but otherwise works the same as it does today for a memfd. The user can select a slice of the FD to map into the ioas and if the underliyng alignment requirements are met it will be placed in the iommu_domain. Though limited, it is enough to allow a VMM like QEMU to connect MMIO BAR memory from VFIO to an iommu_domain controlled by iommufd. This is used for PCI Peer to Peer support in VMs, and is the last feature that the VFIO type 1 container has that iommufd couldn't do. The VFIO type1 version extracts raw PFNs from VMAs, which has no lifetime control and is a use-after-free security problem. Instead iommufd relies on revokable DMABUFs. Whenever VFIO thinks there should be no access to the MMIO it can shoot down the mapping in iommufd which will unmap it from the iommu_domain. There is no automatic remap, this is a safety protocol so the kernel doesn't get stuck. Userspace is expected to know it is doing something that will revoke the dmabuf and map/unmap it around the activity. Eg when QEMU goes to issue FLR it should do the map/unmap to iommufd. Since DMABUF is missing some key general features for this use case it relies on a "private interconnect" between VFIO and iommufd via the vfio_pci_dma_buf_iommufd_map() call. The call confirms the DMABUF has revoke semantics and delivers a phys_addr for the memory suitable for use with iommu_map(). Medium term there is a desire to expand the supported DMABUFs to include GPU drivers to support DPDK/SPDK type use cases so future series will work to add a general concept of revoke and a general negotiation of interconnect to remove vfio_pci_dma_buf_iommufd_map(). I also plan another series to modify iommufd's vfio_compat to transparently pull a dmabuf out of a VFIO VMA to emulate more of the uAPI of type1. The latest series for interconnect negotation to exchange a phys_addr is: https://lore.kernel.org/r/20251027044712.1676175-1-vivek.kasireddy@intel.com And the discussion for design of revoke is here: https://lore.kernel.org/dri-devel/20250114173103.GE5556@nvidia.com/ This is on github: https://github.com/jgunthorpe/linux/commits/iommufd_dmabuf v2: - Rebase on Leon's v7 - Fix mislocking in an iopt_fill_domain() error path v1: https://patch.msgid.link/r/0-v1-64bed2430cdb+31b-iommufd_dmabuf_jgg@nvidia.… Jason Gunthorpe (9): vfio/pci: Add vfio_pci_dma_buf_iommufd_map() iommufd: Add DMABUF to iopt_pages iommufd: Do not map/unmap revoked DMABUFs iommufd: Allow a DMABUF to be revoked iommufd: Allow MMIO pages in a batch iommufd: Have pfn_reader process DMABUF iopt_pages iommufd: Have iopt_map_file_pages convert the fd to a file iommufd: Accept a DMABUF through IOMMU_IOAS_MAP_FILE iommufd/selftest: Add some tests for the dmabuf flow drivers/iommu/iommufd/io_pagetable.c | 78 +++- drivers/iommu/iommufd/io_pagetable.h | 53 ++- drivers/iommu/iommufd/ioas.c | 8 +- drivers/iommu/iommufd/iommufd_private.h | 14 +- drivers/iommu/iommufd/iommufd_test.h | 10 + drivers/iommu/iommufd/main.c | 10 + drivers/iommu/iommufd/pages.c | 407 ++++++++++++++++-- drivers/iommu/iommufd/selftest.c | 142 ++++++ drivers/vfio/pci/vfio_pci_dmabuf.c | 34 ++ include/linux/vfio_pci_core.h | 4 + tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 44 ++ 12 files changed, 781 insertions(+), 66 deletions(-) base-commit: bb04e92c86b44b3e36532099b68de1e889acfee7 -- 2.43.0

1 month, 1 week

1
9
0 0

Re: [PATCH 3/8] iommufd: Allow a DMABUF to be revoked

by Jason Gunthorpe

On Tue, Nov 04, 2025 at 11:58:24PM -0800, Alex Mastro wrote: > On Mon, Oct 27, 2025 at 02:31:02PM -0300, Jason Gunthorpe wrote: > > @@ -1024,8 +1027,15 @@ static int iopt_fill_domain(struct io_pagetable *iopt, > > continue; > > > > mutex_lock(&pages->mutex); > > + if (iopt_is_dmabuf(pages)) { > > + rc = iopt_dmabuf_track_domain(pages, area, domain); > > + if (rc) > > + goto out_unfill; > > I think this error path results in locking pages->mutex recursively. Needs a > mutex_unlock(&pages->mutex)? Yes, let's use a guard then: --- a/drivers/iommu/iommufd/io_pagetable.c +++ b/drivers/iommu/iommufd/io_pagetable.c @@ -1056,7 +1056,7 @@ static int iopt_fill_domain(struct io_pagetable *iopt, if (!pages) continue; - mutex_lock(&pages->mutex); + guard(mutex)(&pages->mutex); if (iopt_is_dmabuf(pages)) { rc = iopt_dmabuf_track_domain(pages, area, domain); if (rc) @@ -1066,7 +1066,6 @@ static int iopt_fill_domain(struct io_pagetable *iopt, if (rc) { if (iopt_is_dmabuf(pages)) iopt_dmabuf_untrack_domain(pages, area, domain); - mutex_unlock(&pages->mutex); goto out_unfill; } if (!area->storage_domain) { Thanks, Jason

1 month, 1 week

1
0
0 0

Re: [PATCH v1 11/20] drm/amdgpu: use multiple entities in amdgpu_fill_buffer

by Christian König

On 11/5/25 11:39, Pierre-Eric Pelloux-Prayer wrote: > Le 04/11/2025 à 17:40, Christian König a écrit : >> On 11/4/25 09:35, Pierre-Eric Pelloux-Prayer wrote: >>> The benefits of using multiple entities is that multiple fill jobs >>> can run in parallel. Otherwise, even if the entity has access >>> to multiple engines, a burst of N independent jobs will all >>> run on the same engine because an entity guarantees the ordering >>> of execution matches the ordering of the submission. >>> >>> Callers can opt-out of this behavior by passing the entity they >>> want to use (see amdgpu_move_blit). >> >> That still sounds like a really bad idea to me. >> >> First of all we can't reserve so many fence slots in the release handler, previously we basically just relied on the fact that the BO will most likely be mostly idle. >> >> I think we should just use a single SDMA engine for each clear and distribute clearing different BOs over multiple engines. > > So N clear entities, each one having access to a single engine. And all jobs to clear a single BO go to the same entity? > > Is that what you mean? More or less. N clear entities, each one has access to all engines. When a BO needs to be cleared it picks the next best entity and submits the jobs. This way clear entities still load balance with moves and page table updates but we can keep the clearing logic simple. Christian. > > Pierre-Eric > >> >> Regards, >> Christian. >> >>> >>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 84 ++++++++++++++++++------- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + >>> 2 files changed, 64 insertions(+), 21 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> index c357a6d9763a..839ea8c7f6be 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> @@ -2224,6 +2224,7 @@ u32 amdgpu_ttm_set_buffer_funcs_status(struct amdgpu_device *adev, bool enable) >>> adev->mman.clear_entities = kcalloc(num_clear_entities, >>> sizeof(struct amdgpu_ttm_entity), >>> GFP_KERNEL); >>> + atomic_set(&adev->mman.next_clear_entity, 0); >>> if (!adev->mman.clear_entities) >>> goto error_free_entity; >>> @@ -2498,10 +2499,12 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> { >>> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >>> struct amdgpu_ring *ring = adev->mman.buffer_funcs_ring; >>> + struct dma_fence *fences[TTM_FENCES_MAX_SLOT_COUNT] = {}; >>> struct dma_fence *fence = NULL; >>> struct dma_resv *resv = NULL; >>> struct amdgpu_res_cursor dst; >>> - int r; >>> + uint64_t cur_size, to; >>> + int r, e, n_fences; >>> /* The fences will be either added to the resv object or the last fence >>> * will be returned to the caller. In the latter case, all fill jobs will >>> @@ -2515,53 +2518,92 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> } >>> if (!entity) { >>> - entity = &adev->mman.clear_entities[0]; >>> resv = &bo->tbo.base._resv; >>> - r = dma_resv_reserve_fences(resv, 1); >>> + >>> + /* Determine how much fences we're going to add to the >>> + * resv object. >>> + */ >>> + n_fences = 0; >>> + amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst); >>> + while (dst.remaining) { >>> + cur_size = min(dst.size, 256ULL << 20); >>> + >>> + n_fences += 1; >>> + amdgpu_res_next(&dst, cur_size); >>> + } >>> + if (n_fences == 0) >>> + return 0; >>> + >>> + /* One slot per entity at most. */ >>> + n_fences = MIN(n_fences, adev->mman.num_clear_entities); >>> + >>> + r = dma_resv_reserve_fences(resv, n_fences); >>> if (r) >>> return r; >>> + } else { >>> + mutex_lock(&entity->gart_window_lock); >>> } >>> amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst); >>> - mutex_lock(&entity->gart_window_lock); >>> while (dst.remaining) { >>> - struct dma_fence *next; >>> - uint64_t cur_size, to; >>> - >>> /* Never fill more than 256MiB at once to avoid timeouts */ >>> cur_size = min(dst.size, 256ULL << 20); >>> + if (resv) { >>> + /* Pick a new entity for each partial clear so they can >>> + * execute in parallel. >>> + */ >>> + e = atomic_inc_return(&adev->mman.next_clear_entity) % >>> + adev->mman.num_clear_entities; >>> + entity = &adev->mman.clear_entities[e]; >>> + mutex_lock(&entity->gart_window_lock); >>> + } >>> + >>> r = amdgpu_ttm_map_buffer(&entity->base, >>> &bo->tbo, bo->tbo.resource, &dst, >>> entity->gart_window_id1, ring, false, >>> &cur_size, &to, >>> dependency, >>> resv); >>> - if (r) >>> + if (r) { >>> + mutex_unlock(&entity->gart_window_lock); >>> goto error; >>> + } >>> r = amdgpu_ttm_fill_mem(ring, &entity->base, >>> src_data, to, cur_size, resv, >>> - &next, true, k_job_id); >>> - if (r) >>> + &fence, true, k_job_id); >>> + if (r) { >>> + mutex_unlock(&entity->gart_window_lock); >>> goto error; >>> - >>> - if (resv) { >>> - dma_resv_add_fence(resv, next, DMA_RESV_USAGE_KERNEL); >>> - dma_fence_put(next); >>> - } else { >>> - dma_fence_put(fence); >>> - fence = next; >>> } >>> amdgpu_res_next(&dst, cur_size); >>> + >>> + if (resv) { >>> + /* Delay the addition of the fences to resv, otherwise the next partial >>> + * clears will depend on this one. >>> + */ >>> + fences[e] = fence; >>> + mutex_unlock(&entity->gart_window_lock); >>> + } else { >>> + dma_fence_put(*f); >>> + *f = fence; >>> + } >>> } >>> error: >>> - mutex_unlock(&entity->gart_window_lock); >>> - if (f) >>> - *f = dma_fence_get(fence); >>> - dma_fence_put(fence); >>> + if (resv) { >>> + for (e = 0; e < adev->mman.num_clear_entities; e++) { >>> + if (fences[e]) { >>> + dma_resv_add_fence(resv, fences[e], DMA_RESV_USAGE_KERNEL); >>> + dma_fence_put(fences[e]); >>> + } >>> + } >>> + } else { >>> + mutex_unlock(&entity->gart_window_lock); >>> + } >>> + >>> return r; >>> } >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> index 38df2b5b4bc7..3fc31c7c6bfe 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> @@ -73,6 +73,7 @@ struct amdgpu_mman { >>> struct amdgpu_ttm_entity default_entity; /* has no gart windows */ >>> struct amdgpu_ttm_entity *clear_entities; >>> + atomic_t next_clear_entity; >>> u32 num_clear_entities; >>> struct amdgpu_ttm_entity move_entities[TTM_FENCES_MAX_SLOT_COUNT]; >>> u32 num_move_entities;

1 month, 1 week

1
0
0 0

Re: [PATCH v1 02/20] drm/ttm: rework pipelined eviction fence handling

by Christian König

On 11/5/25 11:34, Pierre-Eric Pelloux-Prayer wrote: >> >>> + } else { >>> + all_signaled = false; >>> + if (no_wait_gpu) { >>> + spin_unlock(&man->pipelined_eviction.lock); >>> + return -EBUSY; >>> + } >>> + fences_to_add[n++] = dma_fence_get(fence); >>> + } >>> + } >>> + spin_unlock(&man->pipelined_eviction.lock); >>> + >>> + if (all_signaled) >>> return 0; >>> - if (no_wait_gpu) { >>> - ret = dma_fence_is_signaled(fence) ? 0 : -EBUSY; >>> - dma_fence_put(fence); >>> - return ret; >>> + for (i = 0; i < n; i++) { >>> + dma_resv_add_fence(bo->base.resv, fences_to_add[i], DMA_RESV_USAGE_KERNEL); >>> + dma_fence_put(fences_to_add[i]); >>> } >>> - dma_resv_add_fence(bo->base.resv, fence, DMA_RESV_USAGE_KERNEL); >>> - >>> - ret = dma_resv_reserve_fences(bo->base.resv, 1); >>> - dma_fence_put(fence); >>> - return ret; >>> + return dma_resv_reserve_fences(bo->base.resv, TTM_FENCES_MAX_SLOT_COUNT); >> >> Please separate out a patch where the call to dma_resv_reserve_fences() is removed here. > > Can you remind me why it's not needed? Some years ago the dma_resv object had a fixed field for an exclusive fence. When we removed that we sprinkled calls like "dma_resv_reserve_fences(bo->base.resv, 1)" all over the place where we previously used this exclusive fence slot to prevent things from going boom! It could be that some old drivers like radeon or qxl still rely on that somewhere, but that would then clearly be a driver bug. What we could do is to either leave it alone or remove it, but changing it to reserving TTM_FENCES_MAX_SLOT_COUNT is clearly not correct. >> >>> } >>> /** >>> @@ -718,7 +732,7 @@ static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo, >>> int i, ret; >>> ticket = dma_resv_locking_ctx(bo->base.resv); >>> - ret = dma_resv_reserve_fences(bo->base.resv, 1); >>> + ret = dma_resv_reserve_fences(bo->base.resv, TTM_FENCES_MAX_SLOT_COUNT); >>> if (unlikely(ret)) >>> return ret; >>> @@ -757,7 +771,7 @@ static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo, >>> return ret; >>> } >>> - ret = ttm_bo_add_move_fence(bo, man, ctx->no_wait_gpu); >>> + ret = ttm_bo_add_pipelined_eviction_fences(bo, man, ctx->no_wait_gpu); >>> if (unlikely(ret)) { >>> ttm_resource_free(bo, res); >>> if (ret == -EBUSY) >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c >>> index acbbca9d5c92..ada8af965acf 100644 >>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c >>> @@ -258,7 +258,7 @@ static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo, >>> ret = dma_resv_trylock(&fbo->base.base._resv); >>> WARN_ON(!ret); >>> - ret = dma_resv_reserve_fences(&fbo->base.base._resv, 1); >>> + ret = dma_resv_reserve_fences(&fbo->base.base._resv, TTM_FENCES_MAX_SLOT_COUNT); >>> if (ret) { >>> dma_resv_unlock(&fbo->base.base._resv); >>> kfree(fbo); >>> @@ -646,6 +646,8 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, >>> { >>> struct ttm_device *bdev = bo->bdev; >>> struct ttm_resource_manager *from; >>> + struct dma_fence *tmp; >>> + int i, free_slot = -1; >>> from = ttm_manager_type(bdev, bo->resource->mem_type); >>> @@ -653,13 +655,35 @@ static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo, >>> * BO doesn't have a TTM we need to bind/unbind. Just remember >>> * this eviction and free up the allocation >>> */ >>> - spin_lock(&from->move_lock); >>> - if (!from->move || dma_fence_is_later(fence, from->move)) { >>> - dma_fence_put(from->move); >>> - from->move = dma_fence_get(fence); >>> + spin_lock(&from->pipelined_eviction.lock); >>> + for (i = 0; i < from->pipelined_eviction.n_fences; i++) { >>> + tmp = from->pipelined_eviction.fences[i]; >>> + if (!tmp) { >>> + if (free_slot < 0) >>> + free_slot = i; >>> + continue; >> >> Just break here. > > The logic here is to reuse context slots. Even if slot 0 is empty, I need to use slot 1 if slot 1's context is the same as fence->context. Good point, but slot 0 should never be empty. See we fill the slots starting from 0 and then incrementing you either have NULL or a slot which doesn't match. > This way, we're guaranteed to find a slot for all contexts used by the driver. > >> >>> + } >>> + if (fence->context != tmp->context) >>> + continue; >>> + if (dma_fence_is_later(fence, tmp)) { >>> + dma_fence_put(tmp); >>> + free_slot = i; >>> + break; >>> + } >>> + goto unlock; >>> + } >>> + if (free_slot >= 0) { >> >> Drop free_slot and check i here. >> >>> + from->pipelined_eviction.fences[free_slot] = dma_fence_get(fence); >>> + } else { >>> + WARN(1, "not enough fence slots for all fence contexts"); >>> + spin_unlock(&from->pipelined_eviction.lock); >>> + dma_fence_wait(fence, false); >>> + goto end; >>> } >>> - spin_unlock(&from->move_lock); >>> +unlock: >>> + spin_unlock(&from->pipelined_eviction.lock); >>> +end: >>> ttm_resource_free(bo, &bo->resource); >>> } >>> diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c >>> index e2c82ad07eb4..ae0d4621cc55 100644 >>> --- a/drivers/gpu/drm/ttm/ttm_resource.c >>> +++ b/drivers/gpu/drm/ttm/ttm_resource.c >>> @@ -523,14 +523,19 @@ void ttm_resource_manager_init(struct ttm_resource_manager *man, >>> { >>> unsigned i; >>> - spin_lock_init(&man->move_lock); >>> man->bdev = bdev; >>> man->size = size; >>> man->usage = 0; >>> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) >>> INIT_LIST_HEAD(&man->lru[i]); >>> - man->move = NULL; >>> + spin_lock_init(&man->pipelined_eviction.lock); >>> + for (i = 0; i < TTM_FENCES_MAX_SLOT_COUNT; i++) >>> + man->pipelined_eviction.fences[i] = NULL; >>> + /* Can be overridden by drivers that wants to use more than 1 entity >>> + * for moves and evictions (limited to TTM_FENCES_MAX_SLOT_COUNT). >>> + */ >>> + man->pipelined_eviction.n_fences = 1; >>> } >>> EXPORT_SYMBOL(ttm_resource_manager_init); >>> @@ -551,7 +556,7 @@ int ttm_resource_manager_evict_all(struct ttm_device *bdev, >>> .no_wait_gpu = false, >>> }; >>> struct dma_fence *fence; >>> - int ret; >>> + int ret, i; >>> do { >>> ret = ttm_bo_evict_first(bdev, man, &ctx); >>> @@ -561,18 +566,32 @@ int ttm_resource_manager_evict_all(struct ttm_device *bdev, >>> if (ret && ret != -ENOENT) >>> return ret; >>> - spin_lock(&man->move_lock); >>> - fence = dma_fence_get(man->move); >>> - spin_unlock(&man->move_lock); >>> + ret = 0; >>> - if (fence) { >>> - ret = dma_fence_wait(fence, false); >>> - dma_fence_put(fence); >>> - if (ret) >>> - return ret; >>> - } >>> + do { >>> + fence = NULL; >>> - return 0; >>> + spin_lock(&man->pipelined_eviction.lock); >>> + for (i = 0; i < man->pipelined_eviction.n_fences; i++) { >>> + fence = man->pipelined_eviction.fences[i]; >> >>> + man->pipelined_eviction.fences[i] = NULL; >> >> Drop that. We should never set man->pipelined_eviction.fences to NULL. > > Why? To simplify the logic while filling the slots. dma_fences are made to be keept around for long. >> >>> + >>> /** >>> * enum ttm_lru_item_type - enumerate ttm_lru_item subclasses >>> */ >>> @@ -180,8 +189,10 @@ struct ttm_resource_manager_func { >>> * @size: Size of the managed region. >>> * @bdev: ttm device this manager belongs to >>> * @func: structure pointer implementing the range manager. See above >>> - * @move_lock: lock for move fence >>> - * @move: The fence of the last pipelined move operation. >>> + * @pipelined_eviction.lock: lock for eviction fences >>> + * @pipelined_eviction.n_fences: The number of fences allowed in the array. If >>> + * 0, pipelined evictions aren't used. >>> + * @pipelined_eviction.fences: The fences of the last pipelined move operation. >>> * @lru: The lru list for this memory type. >>> * >>> * This structure is used to identify and manage memory types for a device. >>> @@ -195,12 +206,15 @@ struct ttm_resource_manager { >>> struct ttm_device *bdev; >>> uint64_t size; >>> const struct ttm_resource_manager_func *func; >>> - spinlock_t move_lock; >>> - /* >>> - * Protected by @move_lock. >>> + /* This is very similar to a dma_resv object, but locking rules make >>> + * it difficult to use a it in this context. >>> */ >>> - struct dma_fence *move; >>> + struct { >>> + spinlock_t lock; >>> + int n_fences; >>> + struct dma_fence *fences[TTM_FENCES_MAX_SLOT_COUNT]; >>> + } pipelined_eviction; >> >> Drop the separate structure, just make move an array instead. > > IMO pipelined_eviction.fences and pipelined_eviction.lock is clearer when reading the code than moves and move_lock but if you prefer I'll switch back to the old names. The name "pipelined_eviction" is just a bit to long. Maybe just eviction_fences and eviction_fences_lock? Regards, Christian. >> >> And also drop n_fences. Just always take a look at all fences. > > OK. > > Thanks, > Pierre-Eric > >> >> Regards, >> Christian. >> >>> /* >>> * Protected by the bdev->lru_lock. >>> @@ -421,8 +435,12 @@ static inline bool ttm_resource_manager_used(struct ttm_resource_manager *man) >>> static inline void >>> ttm_resource_manager_cleanup(struct ttm_resource_manager *man) >>> { >>> - dma_fence_put(man->move); >>> - man->move = NULL; >>> + int i; >>> + >>> + for (i = 0; i < TTM_FENCES_MAX_SLOT_COUNT; i++) { >>> + dma_fence_put(man->pipelined_eviction.fences[i]); >>> + man->pipelined_eviction.fences[i] = NULL; >>> + } >>> } >>> void ttm_lru_bulk_move_init(struct ttm_lru_bulk_move *bulk);

1 month, 1 week

1
0
0 0

Re: [PATCH v1 17/20] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer

by Christian König

On 11/5/25 10:30, Pierre-Eric Pelloux-Prayer wrote: > > > Le 05/11/2025 à 09:46, Christian König a écrit : >> >> >> On 11/4/25 09:35, Pierre-Eric Pelloux-Prayer wrote: >>> It's doing the same thing as amdgpu_fill_buffer(src_data=0), so drop it. >>> >>> The only caveat is that amdgpu_res_cleared() return value is only valid >>> right after allocation. >>> >>> Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +-- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 86 ++++------------------ >>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 - >>> 3 files changed, 18 insertions(+), 80 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >>> index 4a69324bb730..410e9b68ff81 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c >>> @@ -723,15 +723,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev, >>> if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED && >>> bo->tbo.resource->mem_type == TTM_PL_VRAM) { >>> - struct dma_fence *fence; >>> - >>> - r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence); >>> + r = amdgpu_fill_buffer(NULL, bo, 0, NULL, >>> + NULL, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); >>> if (unlikely(r)) >>> goto fail_unreserve; >>> - >>> - dma_resv_add_fence(bo->tbo.base.resv, fence, >>> - DMA_RESV_USAGE_KERNEL); >>> - dma_fence_put(fence); >>> } >>> if (!bp->resv) >>> amdgpu_bo_unreserve(bo); >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> index d88bdb2ac083..1f553c56f31d 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >>> @@ -2412,75 +2412,6 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_ring *ring, >>> return 0; >>> } >>> -/** >>> - * amdgpu_ttm_clear_buffer - clear memory buffers >>> - * @bo: amdgpu buffer object >>> - * @resv: reservation object >>> - * @fence: dma_fence associated with the operation >>> - * >>> - * Clear the memory buffer resource. >>> - * >>> - * Returns: >>> - * 0 for success or a negative error code on failure. >>> - */ >>> -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, >>> - struct dma_resv *resv, >>> - struct dma_fence **fence) >>> -{ >>> - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); >>> - struct amdgpu_ring *ring = adev->mman.buffer_funcs_rings[0]; >>> - struct amdgpu_ttm_entity *entity; >>> - struct amdgpu_res_cursor cursor; >>> - u64 addr; >>> - int r = 0; >>> - >>> - if (!adev->mman.buffer_funcs_enabled) >>> - return -EINVAL; >>> - >>> - if (!fence) >>> - return -EINVAL; >>> - entity = &adev->mman.clear_entities[0]; >>> - *fence = dma_fence_get_stub(); >>> - >>> - amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor); >>> - >>> - mutex_lock(&entity->gart_window_lock); >>> - while (cursor.remaining) { >>> - struct dma_fence *next = NULL; >>> - u64 size; >>> - >>> - if (amdgpu_res_cleared(&cursor)) { >>> - amdgpu_res_next(&cursor, cursor.size); >>> - continue; >>> - } >>> - >>> - /* Never clear more than 256MiB at once to avoid timeouts */ >>> - size = min(cursor.size, 256ULL << 20); >>> - >>> - r = amdgpu_ttm_map_buffer(&entity->base, >>> - &bo->tbo, bo->tbo.resource, &cursor, >>> - entity->gart_window_id1, ring, false, &size, &addr, >>> - NULL, NULL); >>> - if (r) >>> - goto err; >>> - >>> - r = amdgpu_ttm_fill_mem(ring, &entity->base, 0, addr, size, resv, >>> - &next, true, >>> - AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); >>> - if (r) >>> - goto err; >>> - >>> - dma_fence_put(*fence); >>> - *fence = next; >>> - >>> - amdgpu_res_next(&cursor, size); >>> - } >>> -err: >>> - mutex_unlock(&entity->gart_window_lock); >>> - >>> - return r; >>> -} >>> - >>> /** >>> * amdgpu_fill_buffer - fill a buffer with a given value >>> * @entity: optional entity to use. If NULL, the clearing entities will be >>> @@ -2508,6 +2439,9 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> struct amdgpu_res_cursor dst; >>> uint64_t cur_size, to; >>> int r, e, n_fences; >> >>> + /* The clear flag is only valid directly after allocation. */ >>> + bool consider_clear_flag = >>> + src_data == 0 && k_job_id == AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER; >> >> Absolutely clear NAK to that. > > I suppose the NAK applies to the check, not the general idea of the patch? Correct. > In that case, would passing "bool consider_clear_flag" as a parameter be ok ? And then determining the k_job_id based on this new flag? Yeah, that sounds much cleaner. Christian. > > Pierre-Eric > >> >> Christian. >> >>> /* The fences will be either added to the resv object or the last fence >>> * will be returned to the caller. In the latter case, all fill jobs will >>> @@ -2531,6 +2465,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> while (dst.remaining) { >>> cur_size = min(dst.size, 256ULL << 20); >>> + if (consider_clear_flag && amdgpu_res_cleared(&dst)) { >>> + amdgpu_res_next(&dst, dst.size); >>> + continue; >>> + } >>> + >>> n_fences += 1; >>> amdgpu_res_next(&dst, cur_size); >>> } >>> @@ -2550,6 +2489,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst); >>> while (dst.remaining) { >>> + if (consider_clear_flag && amdgpu_res_cleared(&dst)) { >>> + amdgpu_res_next(&dst, dst.size); >>> + continue; >>> + } >>> + >>> /* Never fill more than 256MiB at once to avoid timeouts */ >>> cur_size = min(dst.size, 256ULL << 20); >>> @@ -2574,8 +2518,10 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> goto error; >>> } >>> + >>> r = amdgpu_ttm_fill_mem(ring, &entity->base, >>> - src_data, to, cur_size, resv, >>> + src_data, to, cur_size, >>> + resv, >>> &fence, true, k_job_id); >>> if (r) { >>> mutex_unlock(&entity->gart_window_lock); >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> index c059a3d52b57..97e73919cb0c 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h >>> @@ -182,9 +182,6 @@ 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_ttm_clear_buffer(struct amdgpu_bo *bo, >>> - struct dma_resv *resv, >>> - struct dma_fence **fence); >>> int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, >>> struct amdgpu_bo *bo, >>> uint32_t src_data,

1 month, 1 week

1
0
0 0

Re: [PATCH v1 18/20] drm/amdgpu: rename amdgpu_fill_buffer as amdgpu_clear_buffer

by Christian König

On 11/4/25 09:35, Pierre-Eric Pelloux-Prayer wrote: > This is the only use case for this function. amdgpu_ttm_clear_buffer please, but apart from that looks good to me. Regards, Christian. > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +++---- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 25 ++++++++++------------ > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 11 +++++----- > 3 files changed, 20 insertions(+), 24 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index 410e9b68ff81..9dc262cac39f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -723,8 +723,8 @@ int amdgpu_bo_create(struct amdgpu_device *adev, > > if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED && > bo->tbo.resource->mem_type == TTM_PL_VRAM) { > - r = amdgpu_fill_buffer(NULL, bo, 0, NULL, > - NULL, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > + r = amdgpu_clear_buffer(NULL, bo, NULL, > + NULL, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > if (unlikely(r)) > goto fail_unreserve; > } > @@ -1311,8 +1311,8 @@ void amdgpu_bo_release_notify(struct ttm_buffer_object *bo) > adev->in_suspend || drm_dev_is_unplugged(adev_to_drm(adev))) > goto out; > > - r = amdgpu_fill_buffer(NULL, abo, 0, NULL, > - NULL, AMDGPU_KERNEL_JOB_ID_CLEAR_ON_RELEASE); > + r = amdgpu_clear_buffer(NULL, abo, NULL, > + 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 1f553c56f31d..ac2857314d68 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -431,9 +431,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, &wipe_fence, fence, > - AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); > + r = amdgpu_clear_buffer(entity, > + abo, &wipe_fence, fence, > + AMDGPU_KERNEL_JOB_ID_MOVE_BLIT); > if (r) { > goto error; > } else if (wipe_fence) { > @@ -2413,23 +2413,21 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_ring *ring, > } > > /** > - * amdgpu_fill_buffer - fill a buffer with a given value > + * amdgpu_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 > * @f: optional out fence. If @entity is NULL, this must be NULL and the > * fences from each partial clear will be added to the &dma_resv. > * @dependency: optional input dependency fence. > * @k_job_id: trace id > * > */ > -int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > - struct amdgpu_bo *bo, > - uint32_t src_data, > - struct dma_fence **f, > - struct dma_fence *dependency, > - u64 k_job_id) > +int amdgpu_clear_buffer(struct amdgpu_ttm_entity *entity, > + struct amdgpu_bo *bo, > + struct dma_fence **f, > + struct dma_fence *dependency, > + u64 k_job_id) > { > struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > struct amdgpu_ring *ring = adev->mman.buffer_funcs_rings[0]; > @@ -2440,8 +2438,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > uint64_t cur_size, to; > int r, e, n_fences; > /* The clear flag is only valid directly after allocation. */ > - bool consider_clear_flag = > - src_data == 0 && k_job_id == AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER; > + bool consider_clear_flag = k_job_id == AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER; > > /* The fences will be either added to the resv object or the last fence > * will be returned to the caller. In the latter case, all fill jobs will > @@ -2520,7 +2517,7 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > > > r = amdgpu_ttm_fill_mem(ring, &entity->base, > - src_data, to, cur_size, > + 0, to, cur_size, > resv, > &fence, true, k_job_id); > if (r) { > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > index 97e73919cb0c..b685bf207e43 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -182,12 +182,11 @@ 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_entity *entity, > - struct amdgpu_bo *bo, > - uint32_t src_data, > - struct dma_fence **f, > - struct dma_fence *dependency, > - u64 k_job_id); > +int amdgpu_clear_buffer(struct amdgpu_ttm_entity *entity, > + struct amdgpu_bo *bo, > + struct dma_fence **f, > + struct dma_fence *dependency, > + u64 k_job_id); > > int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo); > void amdgpu_ttm_recover_gart(struct ttm_buffer_object *tbo);

1 month, 1 week

1
0
0 0

Re: [PATCH v1 17/20] drm/amdgpu: get rid of amdgpu_ttm_clear_buffer

by Christian König

On 11/4/25 09:35, Pierre-Eric Pelloux-Prayer wrote: > It's doing the same thing as amdgpu_fill_buffer(src_data=0), so drop it. > > The only caveat is that amdgpu_res_cleared() return value is only valid > right after allocation. > > Signed-off-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer(a)amd.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 9 +-- > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 86 ++++------------------ > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 - > 3 files changed, 18 insertions(+), 80 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > index 4a69324bb730..410e9b68ff81 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c > @@ -723,15 +723,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev, > > if (bp->flags & AMDGPU_GEM_CREATE_VRAM_CLEARED && > bo->tbo.resource->mem_type == TTM_PL_VRAM) { > - struct dma_fence *fence; > - > - r = amdgpu_ttm_clear_buffer(bo, bo->tbo.base.resv, &fence); > + r = amdgpu_fill_buffer(NULL, bo, 0, NULL, > + NULL, AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > if (unlikely(r)) > goto fail_unreserve; > - > - dma_resv_add_fence(bo->tbo.base.resv, fence, > - DMA_RESV_USAGE_KERNEL); > - dma_fence_put(fence); > } > if (!bp->resv) > amdgpu_bo_unreserve(bo); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > index d88bdb2ac083..1f553c56f31d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c > @@ -2412,75 +2412,6 @@ static int amdgpu_ttm_fill_mem(struct amdgpu_ring *ring, > return 0; > } > > -/** > - * amdgpu_ttm_clear_buffer - clear memory buffers > - * @bo: amdgpu buffer object > - * @resv: reservation object > - * @fence: dma_fence associated with the operation > - * > - * Clear the memory buffer resource. > - * > - * Returns: > - * 0 for success or a negative error code on failure. > - */ > -int amdgpu_ttm_clear_buffer(struct amdgpu_bo *bo, > - struct dma_resv *resv, > - struct dma_fence **fence) > -{ > - struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev); > - struct amdgpu_ring *ring = adev->mman.buffer_funcs_rings[0]; > - struct amdgpu_ttm_entity *entity; > - struct amdgpu_res_cursor cursor; > - u64 addr; > - int r = 0; > - > - if (!adev->mman.buffer_funcs_enabled) > - return -EINVAL; > - > - if (!fence) > - return -EINVAL; > - entity = &adev->mman.clear_entities[0]; > - *fence = dma_fence_get_stub(); > - > - amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &cursor); > - > - mutex_lock(&entity->gart_window_lock); > - while (cursor.remaining) { > - struct dma_fence *next = NULL; > - u64 size; > - > - if (amdgpu_res_cleared(&cursor)) { > - amdgpu_res_next(&cursor, cursor.size); > - continue; > - } > - > - /* Never clear more than 256MiB at once to avoid timeouts */ > - size = min(cursor.size, 256ULL << 20); > - > - r = amdgpu_ttm_map_buffer(&entity->base, > - &bo->tbo, bo->tbo.resource, &cursor, > - entity->gart_window_id1, ring, false, &size, &addr, > - NULL, NULL); > - if (r) > - goto err; > - > - r = amdgpu_ttm_fill_mem(ring, &entity->base, 0, addr, size, resv, > - &next, true, > - AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER); > - if (r) > - goto err; > - > - dma_fence_put(*fence); > - *fence = next; > - > - amdgpu_res_next(&cursor, size); > - } > -err: > - mutex_unlock(&entity->gart_window_lock); > - > - return r; > -} > - > /** > * amdgpu_fill_buffer - fill a buffer with a given value > * @entity: optional entity to use. If NULL, the clearing entities will be > @@ -2508,6 +2439,9 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > struct amdgpu_res_cursor dst; > uint64_t cur_size, to; > int r, e, n_fences; > + /* The clear flag is only valid directly after allocation. */ > + bool consider_clear_flag = > + src_data == 0 && k_job_id == AMDGPU_KERNEL_JOB_ID_TTM_CLEAR_BUFFER; Absolutely clear NAK to that. Christian. > > /* The fences will be either added to the resv object or the last fence > * will be returned to the caller. In the latter case, all fill jobs will > @@ -2531,6 +2465,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > while (dst.remaining) { > cur_size = min(dst.size, 256ULL << 20); > > + if (consider_clear_flag && amdgpu_res_cleared(&dst)) { > + amdgpu_res_next(&dst, dst.size); > + continue; > + } > + > n_fences += 1; > amdgpu_res_next(&dst, cur_size); > } > @@ -2550,6 +2489,11 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > amdgpu_res_first(bo->tbo.resource, 0, amdgpu_bo_size(bo), &dst); > > while (dst.remaining) { > + if (consider_clear_flag && amdgpu_res_cleared(&dst)) { > + amdgpu_res_next(&dst, dst.size); > + continue; > + } > + > /* Never fill more than 256MiB at once to avoid timeouts */ > cur_size = min(dst.size, 256ULL << 20); > > @@ -2574,8 +2518,10 @@ int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > goto error; > } > > + > r = amdgpu_ttm_fill_mem(ring, &entity->base, > - src_data, to, cur_size, resv, > + src_data, to, cur_size, > + resv, > &fence, true, k_job_id); > if (r) { > mutex_unlock(&entity->gart_window_lock); > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > index c059a3d52b57..97e73919cb0c 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h > @@ -182,9 +182,6 @@ 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_ttm_clear_buffer(struct amdgpu_bo *bo, > - struct dma_resv *resv, > - struct dma_fence **fence); > int amdgpu_fill_buffer(struct amdgpu_ttm_entity *entity, > struct amdgpu_bo *bo, > uint32_t src_data,

1 month, 1 week

1
0
0 0

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

by Leon Romanovsky

On Tue, Nov 04, 2025 at 11:19:43AM -0800, Nicolin Chen wrote: > On Sun, Nov 02, 2025 at 10:00:48AM +0200, Leon Romanovsky wrote: > > Changelog: > > v6: > > * Fixed wrong error check from pcim_p2pdma_init(). > > * Documented pcim_p2pdma_provider() function. > > * Improved commit messages. > > * Added VFIO DMA-BUF selftest. > > * Added __counted_by(nr_ranges) annotation to struct vfio_device_feature_dma_buf. > > * Fixed error unwind when dma_buf_fd() fails. > > * Document latest changes to p2pmem. > > * Removed EXPORT_SYMBOL_GPL from pci_p2pdma_map_type. > > * Moved DMA mapping logic to DMA-BUF. > > * Removed types patch to avoid dependencies between subsystems. > > * Moved vfio_pci_dma_buf_move() in err_undo block. > > * Added nvgrace patch. > > I have verified this v6 using Jason's iommufd dmabuf branch: > https://github.com/jgunthorpe/linux/commits/iommufd_dmabuf/ > > by drafting a QEMU patch on top of Shameer's vSMMU v5 series: > https://github.com/nicolinc/qemu/commits/wip/iommufd_dmabuf/ > > with that, I see GPU BAR memory be correctly fetched in the QEMU: > vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 0", offset: 0x0, size: 0x1000000 > vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 2", offset: 0x0, size: 0x44f00000 > vfio_region_dmabuf Device 0009:01:00.0, region "0009:01:00.0 BAR 4", offset: 0x0, size: 0x17a0000000 > > Tested-by: Nicolin Chen <nicolinc(a)nvidia.com> Thanks a lot.

1 month, 1 week

1
0
0 0

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

by Leon Romanovsky

On Mon, Nov 03, 2025 at 12:07:12PM -0800, Alex Mastro wrote: > On Sun, Nov 02, 2025 at 10:00:48AM +0200, Leon Romanovsky wrote: > > Changelog: > > v6: > > * Fixed wrong error check from pcim_p2pdma_init(). > > * Documented pcim_p2pdma_provider() function. > > * Improved commit messages. > > * Added VFIO DMA-BUF selftest. > > * Added __counted_by(nr_ranges) annotation to struct vfio_device_feature_dma_buf. > > * Fixed error unwind when dma_buf_fd() fails. > > * Document latest changes to p2pmem. > > * Removed EXPORT_SYMBOL_GPL from pci_p2pdma_map_type. > > * Moved DMA mapping logic to DMA-BUF. > > * Removed types patch to avoid dependencies between subsystems. > > * Moved vfio_pci_dma_buf_move() in err_undo block. > > * Added nvgrace patch. > > Thanks Leon. Attaching a toy program which sanity tests the dma-buf export UAPI > by feeding the allocated dma-buf into an dma-buf importer (libibverbs + CX-7). > > Tested-by: Alex Mastro <amastro(a)fb.com> Thanks a lot.

1 month, 1 week

1
0
0 0

Re: [EXTERNAL] Re: [PATCH net-next v4 2/6] net: ti: icssg-prueth: Add XSK pool helpers

by Jakub Kicinski

On Tue, 4 Nov 2025 14:23:24 +0530 Meghana Malladi wrote: > > I tried honoring Jakub's comment to avoid freeing the rx memory wherever > > necessary. > > > > "In case of icssg driver, freeing the rx memory is necessary as the > > rx descriptor memory is owned by the cppi dma controller and can be > > mapped to a single memory model (pages/xdp buffers) at a given time. > > In order to remap it, the memory needs to be freed and reallocated." > > Just to make sure we are on the same page, does the above explanation > make sense to you or do you want me to make any changes in this series > for v5 ? No. Based on your reply below you seem to understand what is being asked, so you're expected to do it. > >> I think you should: > >> - stop the H/W from processing incoming packets, > >> - spool all the pending packets > >> - attach/detach the xsk_pool > >> - refill the ring > >> - re-enable the H/W > > > > Current implementation follows the same sequence: > > 1. Does a channel teardown -> stop incoming traffic > > 2. free the rx descriptors from free queue and completion queue -> spool > > all pending packets/descriptors > > 3. attach/detach the xsk pool > > 4. allocate rx descriptors and fill the freeq after mapping them to the > > correct memory buffers -> refill the ring > > 5. restart the NAPI - re-enable the H/W to recv the traffic > > > > I am still working on skipping 2 and 4 steps but this will be a long > > shot. Need to make sure all corner cases are getting covered. If this > > approach looks doable without causing any regressions I might post it as > > a followup patch later in the future.

1 month, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig