Re: [PATCH v12 3/6] lib/arm: Add I/O memory copy helpers

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.09.2026 09:26, Oleksii Moisieiev wrote:
> Introduce memcpy_fromio() and memcpy_toio() helpers to copy between
> regular memory and MMIO space on Arm. The generic prototypes live in
> io.h so other architectures can provide their own implementations.
> 
> These helpers handle alignment safely by using ordered byte accesses for
> any leading/trailing unaligned bytes and ordered 32-bit accesses for the
> aligned bulk transfer.

That's over-simplifying things (just like code comments do). If source
and destination are equally misaligned modulo 4, what is said is true. If
they are differently misaligned, the entire copy will be done byte-wise.
Which can easily be a problem when 4-byte accesses are required for
particular MMIO locations (which may e.g. actually represent device
registers).

As said on earlier versions: I think you either want to get misalignment
handling right for all possible cases, or you want to demand aligned
incoming pointers.

(Ftaod, using byte accesses for two or three leading / trailing misaligned
bytes can be equally wrong, when the MMIO location accessed wants to be
accessed with a 16-bit load/store, for being e.g. a 16-bit device register.
Similarly using 32-bit loads/stores can be wrong in the general case. IOW
while some of that is said to a certain degree, I think there are
unmentioned further constraints on when these functions may safely be
used. For example "devices that tolerate 8-bit and 32-bit accesses" is
still ambiguous as to what exactly it means. Not the least because
"tolerate" doesn't mean "work correctly with".)

> Using the ordered `readb/readl` and
> `writeb/writel` accessors avoids unintended endianness conversion while
> respecting device ordering requirements on ARM32/ARM64 hardware that may
> not support 64-bit MMIO atomically.

I'm having trouble making sense of this part. Why's endianness of concern
here? The accessors used don't care about endianness at all, and what may
have (wrongly) been used in earlier versions shouldn't matter here (or it
would need calling out which other accessors would be wrong to use).

> --- a/xen/include/xen/io.h
> +++ b/xen/include/xen/io.h
> @@ -67,4 +67,14 @@ static inline bool write_mmio(volatile void __iomem *mem, 
> unsigned long data,
>      return true;
>  }
>  
> +/*
> + * Copy between regular memory and MMIO space.  Implementations are
> + * architecture-specific and must use appropriate MMIO accessors for
> + * their memory and I/O models.
> + */
> +void memcpy_fromio(void *to, const volatile void __iomem *from,
> +                   size_t count);
> +void memcpy_toio(volatile void __iomem *to, const void *from,
> +                 size_t count);

For somebody wanting to use these functions and merely looking here, how
would they know of all the constraints? That is implementations are not
merely arch-specific, they may also impose arch-specific constraints.

Jan