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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

This commit introduces two helper functions, `__memcpy_fromio` and
`__memcpy_toio`, to provide a robust mechanism for copying data between
standard memory and memory-mapped I/O (MMIO) space for the ARM
architecture.

These functions are designed to handle memory transfers safely,
accounting for potential address alignment issues to ensure correctness
and improve performance where possible. The implementation is specific
to ARM and uses relaxed I/O accessors.

__memcpy_fromio:
Copies a block of data from an I/O memory source to a destination in
standard ("real") memory. The implementation first handles any unaligned
bytes at the beginning of the source buffer individually using byte-wise
reads. It then copies the bulk of the data using 32-bit reads for
efficiency, and finally processes any remaining bytes at the end of the
buffer.

__memcpy_toio:
Copies a block of data from standard memory to a destination in I/O
memory space. It follows a similar strategy, handling any initial
unaligned portion of the destination buffer byte-by-byte before using
more efficient 32-bit writes for the main, aligned part of the transfer.
Any trailing bytes are also handled individually.

The double underscore (__) prefix follows the Linux kernel convention for
low-level or "raw" implementation functions that:

1. Indicate internal/low-level implementation: The __ prefix signals that these
   are the actual implementation functions, not wrapper macros or inline 
helpers.
   On x86, memcpy_fromio/memcpy_toio are simply #defined as memcpy (see
   xen/arch/x86/dmi_scan.c), but on ARM they require special handling.

2. Architecture-specific behavior: Unlike x86 where IO memory can be accessed
   like regular memory, ARM requires specific IO accessor functions 
(readl_relaxed,
   writel_relaxed, etc.) to ensure proper memory barriers and hardware 
semantics.

3. Prevent accidental misuse: The __ prefix warns developers that these 
functions:
   - Have specific alignment and ordering requirements
   - Must not be confused with regular memcpy()
   - Are meant for IO memory regions only (marked with __iomem)

4. Consistent with Linux kernel style: This naming convention is inherited from
   the Linux kernel's ARM implementation (see linux/arch/arm/include/asm/io.h),
   maintaining compatibility and familiarity for developers working across both
   codebases.

Signed-off-by: Oleksii Moisieiev <oleksii_moisieiev@xxxxxxxx>
---

Changes in v6:
- sorted objs in Makefile alhabetically
- added newline at the end of Makefile
- used uint{N}_t intead of u{N}
- add comment about why 32 bit IO operations were used
- updated cast opertaions to avoid dropping constness which is wrong
- move function definitions to generic place so the could be reused by
other arch
- add SPDX tag to io.c

Changes in v5:
- move memcpy_toio/fromio to the generic place

 xen/include/xen/lib/io.h |  83 +++++++++++++++++++++++++++++++
 xen/lib/Makefile         |   1 +
 xen/lib/arm/Makefile     |   1 +
 xen/lib/arm/io.c         | 102 +++++++++++++++++++++++++++++++++++++++
 4 files changed, 187 insertions(+)
 create mode 100644 xen/include/xen/lib/io.h
 create mode 100644 xen/lib/arm/Makefile
 create mode 100644 xen/lib/arm/io.c

diff --git a/xen/include/xen/lib/io.h b/xen/include/xen/lib/io.h
new file mode 100644
index 0000000000..16758691b8
--- /dev/null
+++ b/xen/include/xen/lib/io.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Generic I/O memory copy function prototypes.
+ *
+ * These functions provide low-level implementation for copying data between
+ * regular memory and I/O memory regions. Each architecture must provide its
+ * own implementation based on the specific requirements of the architecture's
+ * memory model and I/O access patterns.
+ *
+ * Architecture-specific implementations:
+ * =====================================
+ * Each architecture should implement these functions in xen/lib/<arch>/io.c
+ * based on their hardware requirements:
+ *
+ * - ARM/ARM64: Requires special I/O accessors (readl_relaxed, writel_relaxed)
+ *              with proper memory barriers and alignment handling.
+ *              See xen/lib/arm/io.c for implementation.
+ *
+ * - x86/x86_64: I/O memory is directly accessible, so typically uses:
+ *               #define memcpy_fromio memcpy
+ *               #define memcpy_toio   memcpy
+ *               See xen/arch/x86/dmi_scan.c for example usage.
+ *
+ * - Other architectures (RISC-V, PowerPC, MIPS, etc.): Should provide their
+ *   own implementations following the function signatures defined below.
+ *
+ * Naming Convention:
+ * ==================
+ * The double underscore (__) prefix indicates these are low-level "raw"
+ * implementation functions, following the Linux kernel convention for
+ * architecture-specific primitives. This warns developers that these
+ * functions have specific requirements and should not be confused with
+ * regular memcpy().
+ */
+
+#ifndef _XEN_LIB_IO_H
+#define _XEN_LIB_IO_H
+
+#include <xen/types.h>
+
+/*
+ * __memcpy_fromio - Copy data from I/O memory space to regular memory
+ * @to: Destination buffer in regular memory
+ * @from: Source address in I/O memory space (must be marked __iomem)
+ * @count: Number of bytes to copy
+ *
+ * This function handles copying from memory-mapped I/O regions using
+ * architecture-appropriate I/O accessor functions. It ensures proper:
+ * - Memory ordering and barriers
+ * - Alignment requirements
+ * - Hardware-specific access semantics
+ *
+ * Each architecture provides its own implementation that may:
+ * - Use special I/O accessor functions (ARM: readl_relaxed, readb_relaxed)
+ * - Implement alignment handling for devices requiring specific access sizes
+ * - Add memory barriers to ensure ordering with other I/O operations
+ * - Or simply map to memcpy() if the architecture allows direct I/O access
+ */
+extern void __memcpy_fromio(void *to, const volatile void __iomem *from,
+                            size_t count);
+
+/*
+ * __memcpy_toio - Copy data from regular memory to I/O memory space
+ * @to: Destination address in I/O memory space (must be marked __iomem)
+ * @from: Source buffer in regular memory
+ * @count: Number of bytes to copy
+ *
+ * This function handles copying to memory-mapped I/O regions using
+ * architecture-appropriate I/O accessor functions. It ensures proper:
+ * - Memory ordering and barriers
+ * - Alignment requirements
+ * - Hardware-specific access semantics
+ *
+ * Each architecture provides its own implementation that may:
+ * - Use special I/O accessor functions (ARM: writel_relaxed, writeb_relaxed)
+ * - Implement alignment handling for devices requiring specific access sizes
+ * - Add memory barriers to ensure ordering with other I/O operations
+ * - Or simply map to memcpy() if the architecture allows direct I/O access
+ */
+extern void __memcpy_toio(volatile void __iomem *to, const void *from,
+                          size_t count);
+
+#endif /* _XEN_LIB_IO_H */
diff --git a/xen/lib/Makefile b/xen/lib/Makefile
index 5ccb1e5241..6bb0491d89 100644
--- a/xen/lib/Makefile
+++ b/xen/lib/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_ARM) += arm/
 obj-$(CONFIG_X86) += x86/
 
 lib-y += bsearch.o
diff --git a/xen/lib/arm/Makefile b/xen/lib/arm/Makefile
new file mode 100644
index 0000000000..8a7b6cfd59
--- /dev/null
+++ b/xen/lib/arm/Makefile
@@ -0,0 +1 @@
+obj-y += io.o
diff --git a/xen/lib/arm/io.c b/xen/lib/arm/io.c
new file mode 100644
index 0000000000..fbce204775
--- /dev/null
+++ b/xen/lib/arm/io.c
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#include <asm/io.h>
+#include <xen/lib/io.h>
+
+/*
+ * These functions use 32-bit (uint32_t) IO operations rather than 64-bit for
+ * the following reasons:
+ *
+ * 1. ARM32/ARM64 compatibility: On ARM32, there is no atomic 64-bit IO 
accessor
+ *    (readq_relaxed). Only readq_relaxed_non_atomic() exists, which internally
+ *    performs two separate 32-bit reads. Using it would not provide any
+ *    performance benefit and could introduce ordering issues.
+ *
+ * 2. Hardware compatibility: Many IO devices only support 32-bit aligned 
accesses.
+ *    64-bit accesses might not be supported or could cause bus errors on some
+ *    hardware.
+ *
+ * 3. Simplicity: Using 32-bit operations keeps the code simple, maintainable,
+ *    and consistent across both ARM32 and ARM64 architectures without
+ *    architecture-specific conditionals.
+ *
+ * The performance difference between 32-bit and 64-bit operations in this
+ * context is negligible compared to the IO access latency itself.
+ */
+
+/*
+ * memcpy_fromio - Copy data from IO memory space to "real" memory space.
+ * @to: Where to copy to
+ * @from: Where to copy from
+ * @count: The size of the area.
+ */
+void __memcpy_fromio(void *to, const volatile void __iomem *from,
+                     size_t count)
+{
+    while ( count && !IS_ALIGNED((unsigned long)from, 4) )
+    {
+        *(uint8_t *)to = readb_relaxed(from);
+        from++;
+        to++;
+        count--;
+    }
+
+    while ( count >= 4 )
+    {
+        *(uint32_t *)to = readl_relaxed(from);
+        from += 4;
+        to += 4;
+        count -= 4;
+    }
+
+    while ( count )
+    {
+        *(uint8_t *)to = readb_relaxed(from);
+        from++;
+        to++;
+        count--;
+    }
+}
+
+/*
+ * memcpy_toio - Copy data from "real" memory space to IO memory space.
+ * @to: Where to copy to
+ * @from: Where to copy from
+ * @count: The size of the area.
+ */
+void __memcpy_toio(volatile void __iomem *to, const void *from,
+                   size_t count)
+{
+    while ( count && !IS_ALIGNED((unsigned long)to, 4) )
+    {
+        writeb_relaxed(*(const uint8_t *)from, to);
+        from++;
+        to++;
+        count--;
+    }
+
+    while ( count >= 4 )
+    {
+        writel_relaxed(*(const uint32_t *)from, to);
+        from += 4;
+        to += 4;
+        count -= 4;
+    }
+
+    while ( count )
+    {
+        writeb_relaxed(*(const uint8_t *)from, to);
+        from++;
+        to++;
+        count--;
+    }
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 8
+ * tab-width: 8
+ * indent-tabs-mode: t
+ * End:
+ */
-- 
2.34.1