From: Peter Xu <peterx@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Gavin Shan <gshan@redhat.com>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org, mst@redhat.com,
philmd@oss.qualcomm.com, 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 v4 2/3] system/memory: Use qemu_ram_move() for directly accessible regions
Date: Mon, 27 Jul 2026 10:02:55 -0400 [thread overview]
Message-ID: <amdlD1kjhPPMLic3@x1.local> (raw)
In-Reply-To: <CAFEAcA9_tDRAd97z4UtNhFPK+fMbq37LJhWTSmD5cueo61hvvg@mail.gmail.com>
On Mon, Jul 27, 2026 at 01:51:45PM +0100, Peter Maydell wrote:
> I think we could usefully expand this comment, because the reasons
> we need it are not immediately obvious. How about:
>
> ===begin===
> 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()).
>
> 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 guarantee is needed for two major cases:
> - when the ram block is backed by a PCI BAR passed through
> from a host device (and so it might be hardware registers
> that must be accessed exactly once at the right width)
> - when an emulated device updates a data structure shared in
> guest memory with guest software (e.g. a network device's
> set of tx and rx descriptor blocks), if a write to memory
> is accidentally performed multiple times then it can break
> the guest code.
Maybe also append it with "the guest code when it busy polls the guest
memory"; I just found that the polling model isn't something obvious too
when reading it first.
>
> We don't attempt to perform the exact access when it would
> be unaligned, because this can't necessarily be done on
> all host architectures; although this is strictly speaking
> not doing what would happen on real hardware, we don't think
> there are going to be situations where that matters in practice.
Oh yes, mentioning the unaligned part of discussion would also be nice, I
forgot it when replying.
Thanks,
> ===endit===
--
Peter Xu
next prev parent reply other threads:[~2026-07-27 14:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 3:26 [PATCH v4 0/3] system/memory: Make ram device region directly accessible Gavin Shan
2026-07-27 3:26 ` [PATCH v4 1/3] system/memory: Use memmove() for directly accessible regions Gavin Shan
2026-07-27 10:51 ` Peter Maydell
2026-07-27 14:03 ` Peter Xu
2026-07-27 3:26 ` [PATCH v4 2/3] system/memory: Use qemu_ram_move() " Gavin Shan
2026-07-27 12:51 ` Peter Maydell
2026-07-27 13:52 ` Philippe Mathieu-Daudé
2026-07-28 3:09 ` Gavin Shan
2026-07-27 14:02 ` Peter Xu [this message]
2026-07-28 3:02 ` Gavin Shan
2026-07-28 3:00 ` Gavin Shan
2026-07-27 3:26 ` [PATCH v4 3/3] system/memory: Make ram device region directly accessible Gavin Shan
2026-07-27 12:07 ` Peter Maydell
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=amdlD1kjhPPMLic3@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.