All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lizhi Hou <lizhi.hou@amd.com>
To: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>, <mamin506@gmail.com>,
	<ogabbay@kernel.org>
Cc: <christian.koenig@amd.com>, <sumit.semwal@linaro.org>,
	<alexdeucher@gmail.com>, <max.zhen@amd.com>,
	<sonal.santan@amd.com>, <dri-devel@lists.freedesktop.org>,
	<linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
	<linaro-mm-sig@lists.linaro.org>
Subject: Re: [PATCH v4 4/5] accel/amdxdna: refuse to flush an imported BO
Date: Wed, 19 Aug 2026 14:00:01 -0700	[thread overview]
Message-ID: <910192e2-5615-afe5-5129-701a0664a816@amd.com> (raw)
In-Reply-To: <20260817230707.356828-5-taimuraz@kaitmazov.com>


On 8/17/26 16:07, Taimuraz Kaitmazov wrote:
> SYNC_BO clflushes an imported BO's scatterlist. An importer may not do
> that: the memory belongs to the exporter, and dma-buf gives the importer
> no interface to ask for maintenance on it. Refuse the request instead.
>
> is_import_bo() is (obj)->attach, which covers more than foreign buffers.
> A userptr BO arrives through a ubuf, and on a carveout device every share
> BO and the device heap arrive through a cbuf, so SYNC_BO answers
> -EOPNOTSUPP for those too, including the AMDXDNA_BO_DEV path that flushes
> through its heap.
>
> Only the ubuf case gives up maintenance it was getting: on a 64 MiB
> userptr BO a 4 KiB sync and a full sync both cost 659 us, this arm having
> ignored the range. amdxdna_cbuf_map() fills in only the DMA address and
> length, so drm_clflush_sg() already walks zero pages on carveout memory.
> Userspace maintains these through the mapping it already holds, as XRT's
> buffer::sync() does unless it is told to sync through the driver.
>
> Suggested-by: Lizhi Hou <lizhi.hou@amd.com>
> Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com>
> ---
>   drivers/accel/amdxdna/amdxdna_gem.c | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/accel/amdxdna/amdxdna_gem.c b/drivers/accel/amdxdna/amdxdna_gem.c
> index 4f38f985c74e..a713a9982d34 100644
> --- a/drivers/accel/amdxdna/amdxdna_gem.c
> +++ b/drivers/accel/amdxdna/amdxdna_gem.c
> @@ -1224,6 +1224,9 @@ static int amdxdna_flush_bo(struct amdxdna_gem_obj *abo, u64 offset, u64 size)
>   {
>   	u64 end;
>   
> +	if (is_import_bo(abo))
> +		return -EOPNOTSUPP;
> +
>   	if (offset >= abo->mem.size)
>   		return -EINVAL;
>   
> @@ -1234,9 +1237,7 @@ static int amdxdna_flush_bo(struct amdxdna_gem_obj *abo, u64 offset, u64 size)
>   	if (!size)
>   		return 0;
>   
> -	if (is_import_bo(abo))
> -		drm_clflush_sg(abo->base.sgt);
> -	else if (amdxdna_gem_vmap(abo))
> +	if (amdxdna_gem_vmap(abo))
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
>   		drm_clflush_virt_range(amdxdna_gem_vmap(abo) + offset, size);
>   	else if (abo->base.pages)
>   		drm_clflush_pages(abo->base.pages, abo->mem.size >> PAGE_SHIFT);

  reply	other threads:[~2026-08-19 21:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17 23:07 [PATCH v4 0/5] accel/amdxdna: SYNC_BO correctness fixes Taimuraz Kaitmazov
2026-08-17 23:07 ` [PATCH v4 1/5] accel/amdxdna: refuse an I/O memory mapping of an imported BO Taimuraz Kaitmazov
2026-08-19 20:39   ` Lizhi Hou
2026-08-17 23:07 ` [PATCH v4 2/5] accel/amdxdna: check the sync range for overflow on a device BO Taimuraz Kaitmazov
2026-08-19 20:49   ` Lizhi Hou
2026-08-17 23:07 ` [PATCH v4 3/5] accel/amdxdna: do not warn when a sync request is rejected Taimuraz Kaitmazov
2026-08-19 20:57   ` Lizhi Hou
2026-08-17 23:07 ` [PATCH v4 4/5] accel/amdxdna: refuse to flush an imported BO Taimuraz Kaitmazov
2026-08-19 21:00   ` Lizhi Hou [this message]
2026-08-17 23:07 ` [PATCH v4 5/5] accel/amdxdna: do not fail a sync for a BO with no debug context Taimuraz Kaitmazov
2026-08-19 21:05   ` Lizhi Hou
2026-08-18 21:40 ` [PATCH v4 0/5] accel/amdxdna: SYNC_BO correctness fixes Taimuraz Kaitmazov
2026-08-19 16:30   ` Lizhi Hou

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=910192e2-5615-afe5-5129-701a0664a816@amd.com \
    --to=lizhi.hou@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mamin506@gmail.com \
    --cc=max.zhen@amd.com \
    --cc=ogabbay@kernel.org \
    --cc=sonal.santan@amd.com \
    --cc=sumit.semwal@linaro.org \
    --cc=taimuraz@kaitmazov.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.