Re: [PATCH v7 3/5] lib/arm: Add I/O memory copy helpers

[Jan Beulich <jbeulich@xxxxxxxx>]

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