On Thu, 29 Jan 2026, Jan Beulich wrote: > On 29.01.2026 15:16, Oleksii Moisieiev wrote: > > --- /dev/null > > +++ b/xen/arch/arm/lib/memcpy-fromio.c > > @@ -0,0 +1,56 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +#include <xen/io.h> > > + > > +#include <asm/io.h> > > Why both, when xen/io.h includes asm/io.h anyway? > > > +/* > > + * Arm implementation notes / limitations: > > + * - Uses ordered 8-bit for leading/trailing unaligned bytes and ordered > > + * 32-bit accesses for the aligned bulk; no wider accesses are issued. > > + * - Only suitable for devices that tolerate 8-bit and 32-bit accesses; > > + * do not use with devices requiring strictly 16-bit or 64-bit accesses. > > + * - MMIO must be mapped with appropriate device attributes to preserve > > + * ordering; no extra barriers beyond the ordered accessors are added. > > + * - If source or destination is misaligned, leading bytes are copied > > + * byte-by-byte until both sides are 32-bit aligned, > > Which may be never, which in turn may not be obvious to the reader. > > > then bulk copy uses > > + * 32-bit accesses. > > + */ > > It'll be Arm maintainers to judge whether these restrictions are really > going to be acceptable. I think I pointed out more than once that I > think these functions end up being too-narrow-purpose.
I am not the greatest fan of this code, but it seems to fit the purpose well enough, so: Reviewed-by: Stefano Stabellini <[email protected]>
