From: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: simona.vetter@ffwll.ch, matthew.brost@intel.com,
christian.koenig@amd.com, thomas.hellstrom@linux.intel.com,
joonas.lahtinen@linux.intel.com, gustavo.sousa@intel.com,
jan.maslak@intel.com, dominik.karol.piatkowski@intel.com,
rodrigo.vivi@intel.com, andrzej.hajda@intel.com,
matthew.auld@intel.com, maciej.patelczyk@intel.com,
michal.wajdeczko@intel.com, dri-devel@lists.freedesktop.org,
"Felix Kuehling" <Felix.Kuehling@amd.com>,
"Michel Dänzer" <michel.daenzer@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>
Subject: Re: [PATCH 01/20] drm/ttm: Add ttm_bo_access_locked()
Date: Fri, 13 Nov 2026 11:09:04 -0800 [thread overview]
Message-ID: <3a2a052d-19ab-445c-9073-e49dbe2dd737@intel.com> (raw)
In-Reply-To: <20261109135549.4128280-2-mika.kuoppala@linux.intel.com>
Hi Mika,
the description of the "ttm_bo_access()" API states, "Should not be
directly exported to user space via a peak/poke interface."
When the newly added "ttm_bo_access_locked()" is used in "eudebug", it
is ultimately exposed to user space via functions such as "pread" and
"pwrite". @Mattew Brost,I would like to inquire whether this violates
the considerations made when the "ttm_bo_access()" API was initially
designed.
Aside from the above point, the added "ttm_bo_access_locked()" API
appears to be a simple refactoring, so this patch itself does not seem
to pose any issues.
Br,
G.G.
On 11/9/26 5:55 AM, Mika Kuoppala wrote:
> ttm_bo_access() reserves the buffer object itself, so a caller that
> already holds the reservation cannot use it. Split the body out as
> ttm_bo_access_locked(), which asserts the reservation is held, and leave
> ttm_bo_access() as reserve, access, unreserve.
>
> The first user, eudebug vm access, has to wait for the move fences and
> access the object under one reservation.
>
> Cc: Felix Kuehling <Felix.Kuehling@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Michel Dänzer <michel.daenzer@amd.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Matthew Auld <matthew.auld@intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 61 +++++++++++++++++++++++----------
> include/drm/ttm/ttm_bo.h | 2 ++
> 2 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 872bf444b1f0..9a252bce9091 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -405,6 +405,47 @@ static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo,
> return len;
> }
>
> +/**
> + * ttm_bo_access_locked - Helper to access a reserved buffer object
> + *
> + * @bo: ttm buffer object, reserved by the caller
> + * @offset: access offset into buffer object
> + * @buf: pointer to caller memory to read into or write from
> + * @len: length of access
> + * @write: write access
> + *
> + * Same as ttm_bo_access(), for a caller that already holds the reservation,
> + * for instance to wait for fences before the access without the placement
> + * changing in between.
> + *
> + * Returns:
> + * @len if successful, negative error code on failure.
> + */
> +int ttm_bo_access_locked(struct ttm_buffer_object *bo, unsigned long offset,
> + void *buf, int len, int write)
> +{
> + dma_resv_assert_held(bo->base.resv);
> +
> + if (len < 1 || (offset + len) > bo->base.size)
> + return -EIO;
> +
> + if (!bo->resource)
> + return -ENODATA;
> +
> + switch (bo->resource->mem_type) {
> + case TTM_PL_SYSTEM:
> + fallthrough;
> + case TTM_PL_TT:
> + return ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
> + default:
> + if (bo->bdev->funcs->access_memory)
> + return bo->bdev->funcs->access_memory
> + (bo, offset, buf, len, write);
> + return -EIO;
> + }
> +}
> +EXPORT_SYMBOL(ttm_bo_access_locked);
> +
> /**
> * ttm_bo_access - Helper to access a buffer object
> *
> @@ -433,26 +474,8 @@ int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset,
> if (ret)
> return ret;
>
> - if (!bo->resource) {
> - ret = -ENODATA;
> - goto unlock;
> - }
> -
> - switch (bo->resource->mem_type) {
> - case TTM_PL_SYSTEM:
> - fallthrough;
> - case TTM_PL_TT:
> - ret = ttm_bo_vm_access_kmap(bo, offset, buf, len, write);
> - break;
> - default:
> - if (bo->bdev->funcs->access_memory)
> - ret = bo->bdev->funcs->access_memory
> - (bo, offset, buf, len, write);
> - else
> - ret = -EIO;
> - }
> + ret = ttm_bo_access_locked(bo, offset, buf, len, write);
>
> -unlock:
> ttm_bo_unreserve(bo);
>
> return ret;
> diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
> index 32791c4db2a9..3b08baa33ffd 100644
> --- a/include/drm/ttm/ttm_bo.h
> +++ b/include/drm/ttm/ttm_bo.h
> @@ -441,6 +441,8 @@ s64 ttm_bo_evict_cgroup(struct ttm_device *bdev,
> struct dmem_cgroup_pool_state *limit_pool,
> s64 target_bytes,
> struct ttm_operation_ctx *ctx);
> +int ttm_bo_access_locked(struct ttm_buffer_object *bo, unsigned long offset,
> + void *buf, int len, int write);
> int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset,
> void *buf, int len, int write);
> vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
next prev parent reply other threads:[~2026-11-13 19:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 13:55 [PATCH 00/20] Intel Xe GPU Debug Support (eudebug) v11 Mika Kuoppala
2026-11-09 13:55 ` [PATCH 01/20] drm/ttm: Add ttm_bo_access_locked() Mika Kuoppala
2026-11-13 19:09 ` Gwan-gyeong Mun [this message]
2026-11-13 20:29 ` Kuehling, Felix
2026-11-09 13:55 ` [PATCH 02/20] drm/xe/eudebug: Introduce eudebug interface Mika Kuoppala
2026-11-09 13:55 ` [PATCH 03/20] drm/xe/eudebug: Add documentation Mika Kuoppala
2026-11-09 13:55 ` [PATCH 04/20] drm/xe/eudebug: Add connection establishment documentation Mika Kuoppala
2026-11-09 13:55 ` [PATCH 05/20] drm/xe: Implement SR-IOV and eudebug exclusivity Mika Kuoppala
2026-11-09 13:55 ` [PATCH 06/20] drm/xe/eudebug: Introduce discovery for resources Mika Kuoppala
2026-11-09 13:55 ` [PATCH 07/20] drm/xe: Add EUDEBUG_ENABLE exec queue property Mika Kuoppala
2026-11-09 13:55 ` [PATCH 08/20] drm/xe/eudebug: Introduce exec_queue events Mika Kuoppala
2026-11-09 14:16 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 09/20] drm/xe/eudebug: Mark guc contexts as debuggable Mika Kuoppala
2026-11-09 13:55 ` [PATCH 10/20] drm/xe: Introduce ADD_DEBUG_DATA and REMOVE_DEBUG_DATA vm bind ops Mika Kuoppala
2026-11-09 13:55 ` [PATCH 11/20] drm/xe/eudebug: Introduce vm bind and vm bind debug data events Mika Kuoppala
2026-11-09 14:12 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 12/20] drm/xe/eudebug: Add ufence events with acks Mika Kuoppala
2026-11-09 14:22 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 13/20] drm/xe/eudebug: Add vm open/pread/pwrite Mika Kuoppala
2026-11-09 14:22 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 14/20] drm/xe/eudebug: Add userptr vm pread/pwrite Mika Kuoppala
2026-11-09 13:55 ` [PATCH 15/20] drm/xe/eudebug: Add hw enablement Mika Kuoppala
2026-11-09 13:55 ` [PATCH 16/20] drm/xe/eudebug: Track debuggable exec queues Mika Kuoppala
2026-11-09 13:55 ` [PATCH 17/20] drm/xe/eudebug: Introduce EU control interface Mika Kuoppala
2026-11-09 14:35 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 18/20] drm/xe/eudebug: Introduce per device attention scan worker Mika Kuoppala
2026-11-09 14:24 ` sashiko-bot
2026-11-09 13:55 ` [PATCH 19/20] drm/xe/eudebug_test: Introduce eudebug live tests Mika Kuoppala
2026-11-09 13:55 ` [PATCH 20/20] drm/xe: Add xe_client_debugfs and introduce debug_data file Mika Kuoppala
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=3a2a052d-19ab-445c-9073-e49dbe2dd737@intel.com \
--to=gwan-gyeong.mun@intel.com \
--cc=Felix.Kuehling@amd.com \
--cc=alexander.deucher@amd.com \
--cc=andrzej.hajda@intel.com \
--cc=christian.koenig@amd.com \
--cc=dominik.karol.piatkowski@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo.sousa@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jan.maslak@intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=maciej.patelczyk@intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=michel.daenzer@amd.com \
--cc=mika.kuoppala@linux.intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona.vetter@ffwll.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.