Re: [PATCH v3 1/2] system/memory: Use qemu_ram_{copy, move}() in ram device region accessors

[Peter Xu <peterx@redhat.com>]

On Wed, Jul 22, 2026 at 01:58:18AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2026 at 10:53:27AM +1000, Gavin Shan wrote:
> > On 7/22/26 2:27 AM, Peter Xu wrote:
> > > On Tue, Jul 21, 2026 at 03:37:53PM +1000, Gavin Shan wrote:
> > > > If Peter is fine with two variants for x86 and non-x86 architectures.
> > > > I can post (v4) for further review. That will be something like below
> > > > and let me know if there are any other improvements are needed.
> > > 
> > > I have a generic question on the "unaligned access for x86": I think the
> > > question is about the one Michael raised here on unaligned access may break
> > > x86 here:
> > > 
> > >    https://lore.kernel.org/qemu-devel/20260617022330-mutt-send-email-mst@kernel.org/
> > > 
> > >    3. (theoretical concern) also on x86, unaligned accesses are
> > >    possible on guest and host, so converting an unaligned access to a
> > >    series of aligned ones can in theory break devices.
> > > 
> > > Is that a real problem we need to consider, or can we start with unified
> > > approach and leave it for later?
> > > 
> > 
> > I'm leaving this question to Michael.
> 
> Knowing what I know about hardware designers, it's something someone
> somewhere does)
> It can be made a separate patch, just to show - it should be all of
> ~10LOC.

It's only about removal of anything that might be controversial for now,
thanks.  I also wonder if anything would break, then it's more solid proof
that per-arch change is required.

> 
> > > PS: I apologize if I missed important piece of info along the way; I didn't
> > > follow closely on the discussion on this topic in the past few weeks.
> > > 
> > > One thing to mention is, what we change should only need to affect
> > > ram_device, AFAIU.. so most memcpy()/memmove() shouldn't be changed for any
> > > arch when it's pure RAM.
> > > 
> > 
> > It depends. This patch intends to fix issue [1] in the lower layer by using
> > the newly added accessors (qemu_ram_{copy, move}) on all directly accessible
> > regions including the regular (pure) RAM region. Otherwise, the newly added
> > accessors should be limited to ram_device regions only as you said.
> > 
> > [1] https://lore.kernel.org/qemu-devel/20260527091711.3901-1-liugang24219@sangfor.com.cn/
> > 
> > Thanks,
> > Gavin
> 
> using memcpy()/memmove() to emulate guest's atomics is generally
> kinda broken.
> but yes there are architectures where doing it to device ram is
> more broken than doing it to regular ram.

If we keep memcpy()/memmove() for len>8 (aligned or not), I am thinking no
perf issue will happen, then looks like we can indeed change this even for
pure RAM operations, which we can't identify in case of e1000e driver use
case.

Then does it mean we should not use __builtin_memcpy()/memmove()?  Even if
we know constants 1/2/4/8 would work there, why not we go ahead and use
qatomics, which is even more future proof?  I also stumbled on top of
commit 77b1757090 ("include/qemu/bswap.h: Use __builtin_memcpy() in
accessor functions"), which seems to say the same thing "for the long
term".

For "should we still do unaligned access if the guest did it, so as to keep
the original behavior of a bare metal" question, are we on the same page
that we should just break it into aligned accesses for all archs?  I think
it means, we will not be able to emulate guest faults correctly as what
will happen on bare metal, but we're missing the fault injection logics
anyway, so whenever it's implemented we _could_ switch it back to unaligned
accesses.  Before that, breaking unaligned seems like a better way to go to
(1) satisfy all legit users, and (2) don't make QEMU crash by guest
operations.

Last, one silly question: why do we need any helper named with *memcpy*, if
memmove is always superior (to consider range overlap)?  Can we stick with
memmove all over the places?

Thanks,

-- 
Peter Xu