From: Simona Vetter <simona.vetter@ffwll.ch>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: intel-xe@lists.freedesktop.org, Dave Airlie <airlied@gmail.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Maarten Lankhorst <maarten.lankhorst@intel.com>,
Matthew Brost <matthew.brost@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Subject: Re: [PATCH v2 3/3] drm/xe/dma-buf: Allow pinning of p2p dma-buf
Date: Thu, 18 Sep 2025 18:10:59 +0200 [thread overview]
Message-ID: <aMwvE0SypYShDqsv@phenom.ffwll.local> (raw)
In-Reply-To: <20250918092207.54472-4-thomas.hellstrom@linux.intel.com>
On Thu, Sep 18, 2025 at 11:22:07AM +0200, Thomas Hellström wrote:
> RDMA NICs typically requires the VRAM dma-bufs to be pinned in
> VRAM for pcie-p2p communication, since they don't fully support
> the move_notify() scheme. We would like to support that.
>
> However allowing unaccounted pinning of VRAM creates a DOS vector
> so up until now we haven't allowed it.
>
> However with cgroups support in TTM, the amount of VRAM allocated
> to a cgroup can be limited, and since also the pinned memory is
> accounted as allocated VRAM we should be safe.
>
> An analogy with system memory can be made if we observe the
> similarity with kernel system memory that is allocated as the
> result of user-space action and that is accounted using __GFP_ACCOUNT.
>
> Ideally, to be more flexible, we would add a "pinned_memory",
> or possibly "kernel_memory" limit to the dmem cgroups controller,
> that would additionally limit the memory that is pinned in this way.
> If we let that limit default to the dmem::max limit we can
> introduce that without needing to care about regressions.
>
> Considering that we already pin VRAM in this way for at least
> page-table memory and LRC memory, and the above path to greater
> flexibility, allow this also for dma-bufs.
>
> v2:
> - Update comments about pinning in the dma-buf kunit test
> (Niranjana Vishwanathapura)
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Simona Vetter <simona.vetter@ffwll.ch>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
For the same reasons I've acked the amd version of this - vram/gpu memory
accounting is really complex, there's way too many pieces to land them all
perfectly in one big step. Which means the prudent choice is pragmatically
merging useful things without painting ourselves too badly into a corner.
And I think with basic vram cgroup accounting we have that now to land
cross-driver pinning. Of course, there's still a lot of work left to do.
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Cheers, Sima
> ---
> drivers/gpu/drm/xe/tests/xe_dma_buf.c | 17 +++++++++--
> drivers/gpu/drm/xe/xe_dma_buf.c | 41 +++++++++++++++++----------
> 2 files changed, 41 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/tests/xe_dma_buf.c b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> index a7e548a2bdfb..5df98de5ba3c 100644
> --- a/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/tests/xe_dma_buf.c
> @@ -31,6 +31,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
> struct drm_exec *exec)
> {
> struct dma_buf_test_params *params = to_dma_buf_test_params(test->priv);
> + struct dma_buf_attachment *attach;
> u32 mem_type;
> int ret;
>
> @@ -46,7 +47,7 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
> mem_type = XE_PL_TT;
> else if (params->force_different_devices && !is_dynamic(params) &&
> (params->mem_mask & XE_BO_FLAG_SYSTEM))
> - /* Pin migrated to TT */
> + /* Pin migrated to TT on non-dynamic attachments. */
> mem_type = XE_PL_TT;
>
> if (!xe_bo_is_mem_type(exported, mem_type)) {
> @@ -88,6 +89,18 @@ static void check_residency(struct kunit *test, struct xe_bo *exported,
>
> KUNIT_EXPECT_TRUE(test, xe_bo_is_mem_type(exported, mem_type));
>
> + /* Check that we can pin without migrating. */
> + attach = list_first_entry_or_null(&dmabuf->attachments, typeof(*attach), node);
> + if (attach) {
> + int err = dma_buf_pin(attach);
> +
> + if (!err) {
> + KUNIT_EXPECT_TRUE(test, xe_bo_is_mem_type(exported, mem_type));
> + dma_buf_unpin(attach);
> + }
> + KUNIT_EXPECT_EQ(test, err, 0);
> + }
> +
> if (params->force_different_devices)
> KUNIT_EXPECT_TRUE(test, xe_bo_is_mem_type(imported, XE_PL_TT));
> else
> @@ -150,7 +163,7 @@ static void xe_test_dmabuf_import_same_driver(struct xe_device *xe)
> xe_bo_lock(import_bo, false);
> err = xe_bo_validate(import_bo, NULL, false, exec);
>
> - /* Pinning in VRAM is not allowed. */
> + /* Pinning in VRAM is not allowed for non-dynamic attachments */
> if (!is_dynamic(params) &&
> params->force_different_devices &&
> !(params->mem_mask & XE_BO_FLAG_SYSTEM))
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> index a7d67725c3ee..54e42960daad 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -48,32 +48,43 @@ static void xe_dma_buf_detach(struct dma_buf *dmabuf,
>
> static int xe_dma_buf_pin(struct dma_buf_attachment *attach)
> {
> - struct drm_gem_object *obj = attach->dmabuf->priv;
> + struct dma_buf *dmabuf = attach->dmabuf;
> + struct drm_gem_object *obj = dmabuf->priv;
> struct xe_bo *bo = gem_to_xe_bo(obj);
> struct xe_device *xe = xe_bo_device(bo);
> struct drm_exec *exec = XE_VALIDATION_UNSUPPORTED;
> + bool allow_vram = true;
> int ret;
>
> - /*
> - * For now only support pinning in TT memory, for two reasons:
> - * 1) Avoid pinning in a placement not accessible to some importers.
> - * 2) Pinning in VRAM requires PIN accounting which is a to-do.
> - */
> - if (xe_bo_is_pinned(bo) && !xe_bo_is_mem_type(bo, XE_PL_TT)) {
> + if (!IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) {
> + allow_vram = false;
> + } else {
> + list_for_each_entry(attach, &dmabuf->attachments, node) {
> + if (!attach->peer2peer) {
> + allow_vram = false;
> + break;
> + }
> + }
> + }
> +
> + if (xe_bo_is_pinned(bo) && !xe_bo_is_mem_type(bo, XE_PL_TT) &&
> + !(xe_bo_is_vram(bo) && allow_vram)) {
> drm_dbg(&xe->drm, "Can't migrate pinned bo for dma-buf pin.\n");
> return -EINVAL;
> }
>
> - ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
> - if (ret) {
> - if (ret != -EINTR && ret != -ERESTARTSYS)
> - drm_dbg(&xe->drm,
> - "Failed migrating dma-buf to TT memory: %pe\n",
> - ERR_PTR(ret));
> - return ret;
> + if (!allow_vram) {
> + ret = xe_bo_migrate(bo, XE_PL_TT, NULL, exec);
> + if (ret) {
> + if (ret != -EINTR && ret != -ERESTARTSYS)
> + drm_dbg(&xe->drm,
> + "Failed migrating dma-buf to TT memory: %pe\n",
> + ERR_PTR(ret));
> + return ret;
> + }
> }
>
> - ret = xe_bo_pin_external(bo, true, exec);
> + ret = xe_bo_pin_external(bo, !allow_vram, exec);
> xe_assert(xe, !ret);
>
> return 0;
> --
> 2.51.0
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2025-09-18 16:11 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 9:22 [PATCH v2 0/3] drm/xe: Allow pinning of VRAM dma-bufs Thomas Hellström
2025-09-18 9:22 ` [PATCH v2 1/3] drm/xe: Don't copy pinned kernel bos twice on suspend Thomas Hellström
2025-09-18 9:38 ` Matthew Auld
2025-09-18 9:22 ` [PATCH v2 2/3] drm/xe: Pre-allocate system memory for pinned external bos in the pm notfier Thomas Hellström
2025-09-18 9:52 ` Matthew Auld
2025-09-18 9:22 ` [PATCH v2 3/3] drm/xe/dma-buf: Allow pinning of p2p dma-buf Thomas Hellström
2025-09-18 16:10 ` Simona Vetter [this message]
2025-09-22 9:11 ` Maarten Lankhorst
2025-09-18 9:40 ` ✓ CI.KUnit: success for drm/xe: Allow pinning of VRAM dma-bufs Patchwork
2025-09-18 10:12 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-18 17:28 ` ✗ Xe.CI.Full: failure " Patchwork
2025-09-22 12:27 ` Thomas Hellström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMwvE0SypYShDqsv@phenom.ffwll.local \
--to=simona.vetter@ffwll.ch \
--cc=airlied@gmail.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@intel.com \
--cc=matthew.brost@intel.com \
--cc=niranjana.vishwanathapura@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox