From: Peter Xu <peterx@redhat.com>
To: Gavin Shan <gshan@redhat.com>
Cc: qemu-arm@nongnu.org, qemu-devel@nongnu.org, mst@redhat.com,
philmd@oss.qualcomm.com, peter.maydell@linaro.org,
richard.henderson@linaro.org, alex@shazbot.org,
berrange@redhat.com, philmd@mailo.com, david@kernel.org,
clg@redhat.com, pbonzini@redhat.com, phrdina@redhat.com,
jugraham@redhat.com, liugang24219@sangfor.com.cn,
dinghui@sangfor.com.cn, shan.gavin@gmail.com
Subject: Re: [PATCH v5 0/3] system/memory: Make ram device region directly accessible
Date: Tue, 28 Jul 2026 11:19:24 -0400 [thread overview]
Message-ID: <amjIfGLjRpYACr6M@x1.local> (raw)
In-Reply-To: <20260728031731.286666-1-gshan@redhat.com>
On Tue, Jul 28, 2026 at 01:17:28PM +1000, Gavin Shan wrote:
> All ram device regions was turned to be indirectly accessible by commit
> 4a2e242bbb ("memory: Don't use memcpy for ram_device regions"). This leads
> to a frozen guest where a NVidia GH100 GPU is passed from host. The memory
> in its PCI BAR#4 can be allocated as DMA target buffer. qemu has to take
> DMA bounce buffer in address_space_map() to cover the DMA request. However,
> the bounce buffer size is 4096 bytes only and it's exhaused very quickly
> when the guest has significant disk activities on compiling 'cuda-samples'.
> The full log and problem description can be found from PATCH[2/3]'s commit
> log.
>
> Fix the issue handled in commit 4a2e242bbb by replacing memmove() with newly
> added qemu_ram_move() where the aligned and small-sized accesses are handled
> by qatomics, and fall back to memmove() otherwise, for the directly accessible
> regions. With this, we can revert 4a2e242bbb to make ram device region directly
> accessible again and bypass the bounce buffer in address_space_map() where the
> guest hang happens.
>
> PATCH[1] replaces memcpy() with memomve() for directly accessible regions
> PATCH[2] uses qemu_ram_move() for directly accessible regions
> PATCH[3] makes ram device region directly accessible again
Queued for 11.2, with fixups suggested by PeterM in v4 discussions:
https://lore.kernel.org/qemu-devel/CAFEAcA-y+vNK2u-rSq+SVjNZrhO2=BsUysEw2PtCdCZ=qYx2bw@mail.gmail.com/
Fixup:
diff --git a/include/system/memory.h b/include/system/memory.h
index d5fca96cea..16bf04ef07 100644
--- a/include/system/memory.h
+++ b/include/system/memory.h
@@ -2677,9 +2677,9 @@ void address_space_unregister_map_client(AddressSpace *as, QEMUBH *bh);
* Move @n bytes from @src to @dst, the memory areas may overlap. This
* provides the same semantics as memmove(), plus an additional stronger
* guarantee: if @n is 1, 2 or 4 or 8 bytes, and @src and @dst are both
- * naturally aligned for that access size, and the memory areas do not
- * overlap, then both the load and the store will be done as a single
- * atomic access (with the semantics of qatomic_read() and qatomic_set()).
+ * naturally aligned for that access size, then both the load and the store
+ * will be done as a single atomic access (with the semantics of
+ * qatomic_read() and qatomic_set()).
*
* This is the underlying function that we use to implement accesses by
* a guest vCPU or a device DMA operation to a ram block. The atomic
diff --git a/system/physmem.c b/system/physmem.c
index fbe7df2391..2f37cbeb07 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -3162,13 +3162,18 @@ void qemu_ram_move(void *dst, const void *src, size_t n)
{
uintptr_t test, len;
- if (src == dst || n == 0) {
+ if (n == 0) {
return;
}
/*
- * Maximal length of aligned access that are determined by @src,
- * @dst and @n
+ * Calculate "the lowest set bit" over @src, @dst and @n, result put
+ * into @len (which guarantees a power-of-two). With that and the
+ * later check (len!=n), it makes sure that we will only do the atomic
+ * ops when:
+ *
+ * (1) @n is a power-of-two
+ * (2) @src and @dst addresses are both aligned to @n
*/
test = (uintptr_t)src | (uintptr_t)dst | n;
len = test & -test;
--
Peter Xu
prev parent reply other threads:[~2026-07-28 15:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 3:17 [PATCH v5 0/3] system/memory: Make ram device region directly accessible Gavin Shan
2026-07-28 3:17 ` [PATCH v5 1/3] system/memory: Use memmove() for directly accessible regions Gavin Shan
2026-07-28 16:07 ` Philippe Mathieu-Daudé
2026-07-28 3:17 ` [PATCH v5 2/3] system/memory: Use qemu_ram_move() " Gavin Shan
2026-07-29 22:35 ` Michael S. Tsirkin
2026-07-30 6:26 ` Gavin Shan
2026-07-30 9:24 ` Peter Maydell
2026-07-30 10:27 ` Michael S. Tsirkin
2026-07-30 10:34 ` Peter Maydell
2026-07-30 10:50 ` Cédric Le Goater
2026-07-28 3:17 ` [PATCH v5 3/3] system/memory: Make ram device region directly accessible Gavin Shan
2026-07-28 15:19 ` Peter Xu [this message]
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=amjIfGLjRpYACr6M@x1.local \
--to=peterx@redhat.com \
--cc=alex@shazbot.org \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=david@kernel.org \
--cc=dinghui@sangfor.com.cn \
--cc=gshan@redhat.com \
--cc=jugraham@redhat.com \
--cc=liugang24219@sangfor.com.cn \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@mailo.com \
--cc=philmd@oss.qualcomm.com \
--cc=phrdina@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=shan.gavin@gmail.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.