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
