Re: [PATCH v5 2/3] system/memory: Use qemu_ram_move() for directly accessible regions

On Thu, Jul 30, 2026 at 10:24:32AM +0100, Peter Maydell wrote:
> On Wed, 29 Jul 2026 at 23:35, Michael S. Tsirkin <[email protected]> wrote:
> >
> > On Tue, Jul 28, 2026 at 01:17:30PM +1000, Gavin Shan wrote:
> > > +void qemu_ram_move(void *dst, const void *src, size_t n)
> > > +{
> > > +    uintptr_t test, len;
> > > +
> > > +    if (src == dst || n == 0) {
> > > +        return;
> > > +    }
> > > +
> > > +    /*
> > > +     * Maximal length of aligned access that are determined by @src,
> > > +     * @dst and @n
> > > +     */
> > > +    test = (uintptr_t)src | (uintptr_t)dst | n;
> > > +    len = test & -test;
> > > +
> > > +    /* Overlapping buffers, unaligned or oversized access */
> > > +    if (n > 8 || len != n) {
> > > +        memmove(dst, src, n);
> > > +        return;
> > > +    }
> >
> >
> > This part I don't get exactly. It's fine on most arches I think.
> > x86, power...
> >
> > But here is aarch64 for example:
> > https://codebrowser.dev/glibc/glibc/sysdeps/aarch64/memcpy.S.html
> >
> > it says
> >    It uses unaligned accesses and branchless sequences to keep the code small,
> >    simple and improve performance.
> >
> > so if the point is to get rid of unaligned accesses to BARs, are you sure
> > it achieves this?
> 
> The idea is rather just to ignore the unaligned-access-to-not-RAM
> case as "only a theoretical issue" and default it to memmove().
> If anybody reports an actual problem we can think about it then :-)
> 
> -- PMM

Well given the only reported case of virtio DMA into vfio memory we have is
GH100 and that one is mapped MT_NORMAL, I'm fine with that.

I feel extending vfio to report the mapping type to userspace might
not be a bad idea down the road, though. "Directly accessible"
is a very rough approximation to the rich variety of mappings
available across architectures.

-- 
MST