On 7/28/26 12:02 AM, Peter Xu wrote:
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.
The extended context has been included for (v5).
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.
+1. The context has been included for (v5) either.
Thanks,
Gavin
