On 14.01.2026 19:29, Oleksii Moisieiev wrote: > --- /dev/null > +++ b/xen/lib/arm/Makefile > @@ -0,0 +1 @@ > +obj-y += memcpy_fromio.o memcpy_toio.o
lib-y please (requiring a change in Arm's arch.mk as well), and each file on its own line. Plus if this is to be Arm-only (see below), it really means to live in xen/arch/arm/lib/ - see how xen/lib/x86/ is about to go away: https://lists.xen.org/archives/html/xen-devel/2026-01/msg00138.html. > --- /dev/null > +++ b/xen/lib/arm/memcpy_fromio.c > @@ -0,0 +1,48 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +#include <asm/io.h> > +#include <xen/lib/io.h> > + > +/* > + * Use 32-bit raw IO operations for portability across ARM32/ARM64 where > + * 64-bit accessors may not be atomic and some devices only support 32-bit > + * aligned accesses. > + */ > + > +void memcpy_fromio(void *to, const volatile void __iomem *from, > + size_t count) > +{ > + while ( count && (!IS_ALIGNED((unsigned long)from, 4) || > + !IS_ALIGNED((unsigned long)to, 4)) ) Nit: Xen style indentation (no hard tabs) please throughout. > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > + > + while ( count >= 4 ) > + { > + *(uint32_t *)to = __raw_readl(from); > + from += 4; > + to += 4; > + count -= 4; > + } > + > + while ( count ) > + { > + *(uint8_t *)to = __raw_readb(from); > + from++; > + to++; > + count--; > + } > +} Barrier requirements on Arm aren't quite clear to me here: Is it really correct to use __raw_read{b,w,l}() here, rather than read{b,w,l}()? If it was, wouldn't a barrier then be needed at the end of the function? And then, if it was read{b,w,l}() that is to be used here, what about all of this would then still be Arm-specific? Hmm, I guess the IS_ALIGNED() on "to" is, but that's Arm32-specific, with Arm64 not needing it? Plus then it's again not exactly Arm-specific, but specific to all architectures where misaligned accesses may fault. Jan
