Hi,
these patches add support for the s390 architecture both to nolibc
and rcutorture. Note that this only adds support for the 64 bit
version, no support for 31 bit (compat) is added. For nolibc it
includes one bugfix to make the fd_set datatype match the kernel
type.
Sven Schnelle (5):
nolibc: fix fd_set type
nolibc: add support for s390
selftests/nolibc: add s390 support
rcutorture: add support for s390
rcutorture: build initrd for rcutorture with nolibc
tools/include/nolibc/arch-s390.h | 213 ++++++++++++++++++
tools/include/nolibc/arch.h | 2 +
tools/include/nolibc/sys.h | 2 +
tools/include/nolibc/types.h | 53 +++--
tools/testing/selftests/nolibc/Makefile | 4 +
.../selftests/rcutorture/bin/functions.sh | 6 +
.../selftests/rcutorture/bin/mkinitrd.sh | 2 +-
7 files changed, 258 insertions(+), 24 deletions(-)
create mode 100644 tools/include/nolibc/arch-s390.h
--
2.34.1
The kernel uses unsigned long for the fd_set bitmap,
but nolibc use u32. This works fine on little endian
machines, but fails on big endian. Convert to unsigned
long to fix this.
Signed-off-by: Sven Schnelle <[email protected]>
---
tools/include/nolibc/types.h | 53 ++++++++++++++++++++----------------
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/tools/include/nolibc/types.h b/tools/include/nolibc/types.h
index 959997034e55..300e0ff1cd58 100644
--- a/tools/include/nolibc/types.h
+++ b/tools/include/nolibc/types.h
@@ -89,39 +89,46 @@
#define EXIT_SUCCESS 0
#define EXIT_FAILURE 1
+#define FD_SETIDXMASK (8 * sizeof(unsigned long))
+#define FD_SETBITMASK (8 * sizeof(unsigned long)-1)
+
/* for select() */
typedef struct {
- uint32_t fd32[(FD_SETSIZE + 31) / 32];
+ unsigned long fds[(FD_SETSIZE + FD_SETBITMASK) / FD_SETIDXMASK];
} fd_set;
-#define FD_CLR(fd, set) do { \
- fd_set *__set = (set); \
- int __fd = (fd); \
- if (__fd >= 0) \
- __set->fd32[__fd / 32] &= ~(1U << (__fd & 31)); \
+#define FD_CLR(fd, set) do { \
+ fd_set *__set = (set); \
+ int __fd = (fd); \
+ if (__fd >= 0) \
+ __set->fds[__fd / FD_SETIDXMASK] &= \
+ ~(1U << (__fd & FX_SETBITMASK)); \
} while (0)
-#define FD_SET(fd, set) do { \
- fd_set *__set = (set); \
- int __fd = (fd); \
- if (__fd >= 0) \
- __set->fd32[__fd / 32] |= 1U << (__fd & 31); \
+#define FD_SET(fd, set) do { \
+ fd_set *__set = (set); \
+ int __fd = (fd); \
+ if (__fd >= 0) \
+ __set->fds[__fd / FD_SETIDXMASK] |= \
+ 1 << (__fd & FD_SETBITMASK); \
} while (0)
-#define FD_ISSET(fd, set) ({ \
- fd_set *__set = (set); \
- int __fd = (fd); \
- int __r = 0; \
- if (__fd >= 0) \
- __r = !!(__set->fd32[__fd / 32] & 1U << (__fd & 31)); \
- __r; \
+#define FD_ISSET(fd, set) ({ \
+ fd_set *__set = (set); \
+ int __fd = (fd); \
+ int __r = 0; \
+ if (__fd >= 0) \
+ __r = !!(__set->fds[__fd / FD_SETIDXMASK] & \
+1U << (__fd & FD_SET_BITMASK)); \
+ __r; \
})
-#define FD_ZERO(set) do { \
- fd_set *__set = (set); \
- int __idx; \
- for (__idx = 0; __idx < (FD_SETSIZE+31) / 32; __idx ++) \
- __set->fd32[__idx] = 0; \
+#define FD_ZERO(set) do { \
+ fd_set *__set = (set); \
+ int __idx; \
+ int __size = (FD_SETSIZE+FD_SETBITMASK) / FD_SETIDXMASK;\
+ for (__idx = 0; __idx < __size; __idx++) \
+ __set->fds[__idx] = 0; \
} while (0)
/* for poll() */
--
2.34.1
This reduces the size of init from ~600KB to ~1KB.
Signed-off-by: Sven Schnelle <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
---
tools/testing/selftests/rcutorture/bin/mkinitrd.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
index 70d62fd0d31d..71f0dfbb2a6d 100755
--- a/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
+++ b/tools/testing/selftests/rcutorture/bin/mkinitrd.sh
@@ -64,7 +64,7 @@ ___EOF___
# build using nolibc on supported archs (smaller executable) and fall
# back to regular glibc on other ones.
if echo -e "#if __x86_64__||__i386__||__i486__||__i586__||__i686__" \
- "||__ARM_EABI__||__aarch64__\nyes\n#endif" \
+ "||__ARM_EABI__||__aarch64__||__s390x__\nyes\n#endif" \
| ${CROSS_COMPILE}gcc -E -nostdlib -xc - \
| grep -q '^yes'; then
# architecture supported by nolibc
--
2.34.1
Use arch-x86_64 as a template. Not really different, but
we have our own mmap syscall which takes a structure instead
of discrete arguments.
Signed-off-by: Sven Schnelle <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
---
tools/include/nolibc/arch-s390.h | 213 +++++++++++++++++++++++++++++++
tools/include/nolibc/arch.h | 2 +
tools/include/nolibc/sys.h | 2 +
3 files changed, 217 insertions(+)
create mode 100644 tools/include/nolibc/arch-s390.h
diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
new file mode 100644
index 000000000000..34b744e2f7d6
--- /dev/null
+++ b/tools/include/nolibc/arch-s390.h
@@ -0,0 +1,213 @@
+/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
+/*
+ * s390 specific definitions for NOLIBC
+ */
+
+#ifndef _NOLIBC_ARCH_S390_H
+#define _NOLIBC_ARCH_S390_H
+#include <asm/unistd.h>
+
+/* O_* macros for fcntl/open are architecture-specific */
+#define O_RDONLY 0
+#define O_WRONLY 1
+#define O_RDWR 2
+#define O_CREAT 0x40
+#define O_EXCL 0x80
+#define O_NOCTTY 0x100
+#define O_TRUNC 0x200
+#define O_APPEND 0x400
+#define O_NONBLOCK 0x800
+#define O_DIRECTORY 0x10000
+
+/* The struct returned by the stat() syscall, equivalent to stat64(). The
+ * syscall returns 116 bytes and stops in the middle of __unused.
+ */
+
+struct sys_stat_struct {
+ unsigned long st_dev;
+ unsigned long st_ino;
+ unsigned long st_nlink;
+ unsigned int st_mode;
+ unsigned int st_uid;
+ unsigned int st_gid;
+ unsigned int __pad1;
+ unsigned long st_rdev;
+ unsigned long st_size;
+ unsigned long st_atime;
+ unsigned long st_atime_nsec;
+ unsigned long st_mtime;
+ unsigned long st_mtime_nsec;
+ unsigned long st_ctime;
+ unsigned long st_ctime_nsec;
+ unsigned long st_blksize;
+ long st_blocks;
+ unsigned long __unused[3];
+};
+
+/* Syscalls for s390:
+ * - registers are 64-bit
+ * - syscall number is passed in r1
+ * - arguments are in r2-r7
+ * - the system call is performed by calling the svc instruction
+ * - syscall return value is in r2
+ * - r1 and r2 are clobbered, others are preserved.
+ *
+ * Link s390 ABI: https://github.com/IBM/s390x-abi
+ *
+ */
+
+#define my_syscall0(num) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _rc __asm__ ("2"); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "=d"(_rc) \
+ : "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _rc; \
+})
+
+#define my_syscall1(num, arg1) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall2(num, arg1, arg2) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall3(num, arg1, arg2, arg3) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall4(num, arg1, arg2, arg3, arg4) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall5(num, arg1, arg2, arg3, arg4, arg5) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ register long _arg5 __asm__ ("6") = (long)(arg5); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_arg5), \
+ "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ register long _arg5 __asm__ ("6") = (long)(arg5); \
+ register long _arg6 __asm__ ("7") = (long)(arg6); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_arg5), \
+ "d"(_arg6), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+/* startup code */
+__asm__ (".section .text\n"
+ ".weak _start\n"
+ "_start:\n"
+ "lg %r2,0(%r15)\n" /* argument count */
+ "la %r3,8(%r15)\n" /* argument pointers */
+ "la %r4,24(%r15)\n" /* environment pointers */
+ "lay %r15,-160(%r15)\n" /* allocate new stackframe */
+ "xc 0(8,%r15),0(%r15)\n" /* clear backchain */
+ "brasl %r14,main\n" /* ret value of main is arg to exit */
+ "lghi %r1,1\n" /* __NR_exit */
+ "svc 0\n"
+ "");
+
+struct s390_mmap_arg_struct {
+ unsigned long addr;
+ unsigned long len;
+ unsigned long prot;
+ unsigned long flags;
+ unsigned long fd;
+ unsigned long offset;
+};
+
+static __maybe_unused
+void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
+ off_t offset)
+{
+ struct s390_mmap_arg_struct args = {
+ .addr = (unsigned long)addr,
+ .len = (unsigned long)length,
+ .prot = prot,
+ .flags = flags,
+ .fd = fd,
+ .offset = (unsigned long)offset
+ };
+
+ return (void *)my_syscall1(__NR_mmap, &args);
+}
+#define sys_mmap sys_mmap
+#endif // _NOLIBC_ARCH_S390_H
diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
index 4c6992321b0d..fcded65b98d7 100644
--- a/tools/include/nolibc/arch.h
+++ b/tools/include/nolibc/arch.h
@@ -27,6 +27,8 @@
#include "arch-mips.h"
#elif defined(__riscv)
#include "arch-riscv.h"
+#elif defined(__s390x__)
+#include "arch-s390x.h"
#endif
#endif /* _NOLIBC_ARCH_H */
diff --git a/tools/include/nolibc/sys.h b/tools/include/nolibc/sys.h
index ce3ee03aa679..3db1dd8c74ee 100644
--- a/tools/include/nolibc/sys.h
+++ b/tools/include/nolibc/sys.h
@@ -686,6 +686,7 @@ int mknod(const char *path, mode_t mode, dev_t dev)
#define MAP_FAILED ((void *)-1)
#endif
+#ifndef sys_mmap
static __attribute__((unused))
void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset)
@@ -707,6 +708,7 @@ void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
return (void *)my_syscall6(n, addr, length, prot, flags, fd, offset);
#endif
}
+#endif
static __attribute__((unused))
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)
--
2.34.1
Add the required values to identify_qemu() and
identify_bootimage().
Signed-off-by: Sven Schnelle <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
---
tools/testing/selftests/rcutorture/bin/functions.sh | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh
index 66d0414d8e4b..b52d5069563c 100644
--- a/tools/testing/selftests/rcutorture/bin/functions.sh
+++ b/tools/testing/selftests/rcutorture/bin/functions.sh
@@ -159,6 +159,9 @@ identify_boot_image () {
qemu-system-aarch64)
echo arch/arm64/boot/Image
;;
+ qemu-system-s390x)
+ echo arch/s390/boot/bzImage
+ ;;
*)
echo vmlinux
;;
@@ -184,6 +187,9 @@ identify_qemu () {
elif echo $u | grep -q aarch64
then
echo qemu-system-aarch64
+ elif echo $u | grep -q 'IBM S/390'
+ then
+ echo qemu-system-s390x
elif uname -a | grep -q ppc64
then
echo qemu-system-ppc64
--
2.34.1
Signed-off-by: Sven Schnelle <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
---
tools/testing/selftests/nolibc/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
index 69ea659caca9..92d8276bc226 100644
--- a/tools/testing/selftests/nolibc/Makefile
+++ b/tools/testing/selftests/nolibc/Makefile
@@ -19,6 +19,7 @@ IMAGE_arm64 = arch/arm64/boot/Image
IMAGE_arm = arch/arm/boot/zImage
IMAGE_mips = vmlinuz
IMAGE_riscv = arch/riscv/boot/Image
+IMAGE_s390 = arch/s390/boot/bzImage
IMAGE = $(IMAGE_$(ARCH))
IMAGE_NAME = $(notdir $(IMAGE))
@@ -29,6 +30,7 @@ DEFCONFIG_arm64 = defconfig
DEFCONFIG_arm = multi_v7_defconfig
DEFCONFIG_mips = malta_defconfig
DEFCONFIG_riscv = defconfig
+DEFCONFIG_s390 = defconfig
DEFCONFIG = $(DEFCONFIG_$(ARCH))
# optional tests to run (default = all)
@@ -41,6 +43,7 @@ QEMU_ARCH_arm64 = aarch64
QEMU_ARCH_arm = arm
QEMU_ARCH_mips = mipsel # works with malta_defconfig
QEMU_ARCH_riscv = riscv64
+QEMU_ARCH_s390 = s390x
QEMU_ARCH = $(QEMU_ARCH_$(ARCH))
# QEMU_ARGS : some arch-specific args to pass to qemu
@@ -50,6 +53,7 @@ QEMU_ARGS_arm64 = -M virt -cpu cortex-a53 -append "panic=-1 $(TEST:%=NOLIBC_TE
QEMU_ARGS_arm = -M virt -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_mips = -M malta -append "panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS_riscv = -M virt -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
+QEMU_ARGS_s390 = -M s390-ccw-virtio -m 1G -append "console=ttyS0 panic=-1 $(TEST:%=NOLIBC_TEST=%)"
QEMU_ARGS = $(QEMU_ARGS_$(ARCH))
# OUTPUT is only set when run from the main makefile, otherwise
--
2.34.1
On Fri, Dec 09, 2022 at 03:19:34PM +0100, Sven Schnelle wrote:
> Hi,
>
> these patches add support for the s390 architecture both to nolibc
> and rcutorture. Note that this only adds support for the 64 bit
> version, no support for 31 bit (compat) is added. For nolibc it
> includes one bugfix to make the fd_set datatype match the kernel
> type.
Nice!!!
The rcutorture patches look plausible to me, but I must defer to Willy
Tarreau on the nolibc changes.
Thanx, Paul
> Sven Schnelle (5):
> nolibc: fix fd_set type
> nolibc: add support for s390
> selftests/nolibc: add s390 support
> rcutorture: add support for s390
> rcutorture: build initrd for rcutorture with nolibc
>
> tools/include/nolibc/arch-s390.h | 213 ++++++++++++++++++
> tools/include/nolibc/arch.h | 2 +
> tools/include/nolibc/sys.h | 2 +
> tools/include/nolibc/types.h | 53 +++--
> tools/testing/selftests/nolibc/Makefile | 4 +
> .../selftests/rcutorture/bin/functions.sh | 6 +
> .../selftests/rcutorture/bin/mkinitrd.sh | 2 +-
> 7 files changed, 258 insertions(+), 24 deletions(-)
> create mode 100644 tools/include/nolibc/arch-s390.h
>
> --
> 2.34.1
>
On Fri, Dec 09, 2022 at 07:03:25AM -0800, Paul E. McKenney wrote:
> On Fri, Dec 09, 2022 at 03:19:34PM +0100, Sven Schnelle wrote:
> > Hi,
> >
> > these patches add support for the s390 architecture both to nolibc
> > and rcutorture. Note that this only adds support for the 64 bit
> > version, no support for 31 bit (compat) is added. For nolibc it
> > includes one bugfix to make the fd_set datatype match the kernel
> > type.
>
> Nice!!!
indeed :-)
> The rcutorture patches look plausible to me, but I must defer to Willy
> Tarreau on the nolibc changes.
I had a very quick glance over them and nothing shocked me. I just want
to double-check the u32->long conversion with a careful eye but I'm happy
to see that your rcutorture binary continues its diet on more and more
architectures ;-)
Cheers,
Willy
On Fri, Dec 09, 2022 at 04:28:35PM +0100, Willy Tarreau wrote:
> On Fri, Dec 09, 2022 at 07:03:25AM -0800, Paul E. McKenney wrote:
> > On Fri, Dec 09, 2022 at 03:19:34PM +0100, Sven Schnelle wrote:
> > > Hi,
> > >
> > > these patches add support for the s390 architecture both to nolibc
> > > and rcutorture. Note that this only adds support for the 64 bit
> > > version, no support for 31 bit (compat) is added. For nolibc it
> > > includes one bugfix to make the fd_set datatype match the kernel
> > > type.
> >
> > Nice!!!
>
> indeed :-)
>
> > The rcutorture patches look plausible to me, but I must defer to Willy
> > Tarreau on the nolibc changes.
>
> I had a very quick glance over them and nothing shocked me. I just want
> to double-check the u32->long conversion with a careful eye but I'm happy
> to see that your rcutorture binary continues its diet on more and more
> architectures ;-)
Very good, and I will await your review.
Thanx, Paul
On Fri, Dec 09, 2022 at 03:19:35PM +0100, Sven Schnelle wrote:
> The kernel uses unsigned long for the fd_set bitmap,
> but nolibc use u32. This works fine on little endian
> machines, but fails on big endian. Convert to unsigned
> long to fix this.
Thank you for spotting and fixing this one! I had been using these for
a long time, including for pure user-land code to manipulate bits and
never thought about the risk of incompatibility when passing them as-is
to the kernel! It's fairly possible that I'm having non-working code for
64-bit BE machines at a few places!
> Signed-off-by: Sven Schnelle <[email protected]>
Acked-by: Willy Tarreau <[email protected]>
Willy
On Fri, Dec 09, 2022 at 05:26:43PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 09, 2022 at 04:28:35PM +0100, Willy Tarreau wrote:
> > On Fri, Dec 09, 2022 at 07:03:25AM -0800, Paul E. McKenney wrote:
> > > On Fri, Dec 09, 2022 at 03:19:34PM +0100, Sven Schnelle wrote:
> > > > Hi,
> > > >
> > > > these patches add support for the s390 architecture both to nolibc
> > > > and rcutorture. Note that this only adds support for the 64 bit
> > > > version, no support for 31 bit (compat) is added. For nolibc it
> > > > includes one bugfix to make the fd_set datatype match the kernel
> > > > type.
> > >
> > > Nice!!!
> >
> > indeed :-)
> >
> > > The rcutorture patches look plausible to me, but I must defer to Willy
> > > Tarreau on the nolibc changes.
> >
> > I had a very quick glance over them and nothing shocked me. I just want
> > to double-check the u32->long conversion with a careful eye but I'm happy
> > to see that your rcutorture binary continues its diet on more and more
> > architectures ;-)
>
> Very good, and I will await your review.
So overall the series looks good to me except one occurrence of "s390x"
instead of "s390" in arch.h which will prevent the build from working
with the old "-include nolibc.h" mode. If Sven agrees we can fix it
directly in the patch (drop the 'x' in the "#include") so that he does
not need to respin the series. I'm deferring to you the final word on
the part on rcutorture (but it looks trivially correct to me).
Thanks!
Willy
On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> Whoops. One of my colleagues suggested that i should name the file
> arch-390x.h. Reason for this is that the architecture name "s390"
> describes the 31bit (compat) architecture mode in userspace, and "s390x"
> the 64 bit mode. To make it a bit more complicated, the architecture in
> the kernel is named "s390". That's because in the beginning the kernel
> could run in 31bit or 64 bit mode, and there can be only one
> architecture name. When support for running 31bit kernels was removed
> years ago, the architecture name s390 was kept because renaming the
> architecture would have been quite some fun. So in short:
>
> Kernel s390 == 64 bit only
> Userspace s390 == 31 bit
> Userspace s390x == 64 bit
OK, that might be why it's always a bit confusing to me :-)
> So i tried renaming the header file, noted that the Makefile just uses:
>
> nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
> arch_file := arch-$(nolibc_arch).h
>
> which would then need special handling. Obviously i failed to revert the
> change completely during rebase.
>
> So it should be:
>
> >> +#elif defined(__s390x__)
> >> +#include "arch-s390.h"
>
> I'm fine with both - either you fixing it up or me sending a v2.
As you like. If you prefer to rename the file to s390x as your colleague
suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
drop that 'x' in the #include.
Thanks,
Willy
Willy Tarreau <[email protected]> writes:
> On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
>> Use arch-x86_64 as a template. Not really different, but
>> we have our own mmap syscall which takes a structure instead
>> of discrete arguments.
>
> I'm fine with placing the mmap syscall inside the arch-s390 file, though
> it differs from what's done for other syscalls. But I admit that mmap is
> one of these syscalls that differ between various archs and that it's not
> shocking to leave it per-arch.
>
> However you're having an issue here:
>
>> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
>> new file mode 100644
>> index 000000000000..34b744e2f7d6
>> --- /dev/null
>> +++ b/tools/include/nolibc/arch-s390.h
> ^^^^^^^^^
> vs:
>
>> diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
>> index 4c6992321b0d..fcded65b98d7 100644
>> --- a/tools/include/nolibc/arch.h
>> +++ b/tools/include/nolibc/arch.h
>> @@ -27,6 +27,8 @@
>> #include "arch-mips.h"
>> #elif defined(__riscv)
>> #include "arch-riscv.h"
>> +#elif defined(__s390x__)
>> +#include "arch-s390x.h"
> ^^^^^^^^^^
>
> As you see the file is not the same so if you build by including nolibc.h
> directly it will not work. The difference between s390 and s390x has never
> been very clear to me, so I can't easily suggest which name is the most
> suitable, but you'll definitely have to choose one :-) If it's just a
> matter of dropping that trailing 'x' there, I think we can fix your patch
> here without re-submitting, let us know.
Whoops. One of my colleagues suggested that i should name the file
arch-390x.h. Reason for this is that the architecture name "s390"
describes the 31bit (compat) architecture mode in userspace, and "s390x"
the 64 bit mode. To make it a bit more complicated, the architecture in
the kernel is named "s390". That's because in the beginning the kernel
could run in 31bit or 64 bit mode, and there can be only one
architecture name. When support for running 31bit kernels was removed
years ago, the architecture name s390 was kept because renaming the
architecture would have been quite some fun. So in short:
Kernel s390 == 64 bit only
Userspace s390 == 31 bit
Userspace s390x == 64 bit
So i tried renaming the header file, noted that the Makefile just uses:
nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
arch_file := arch-$(nolibc_arch).h
which would then need special handling. Obviously i failed to revert the
change completely during rebase.
So it should be:
>> +#elif defined(__s390x__)
>> +#include "arch-s390.h"
I'm fine with both - either you fixing it up or me sending a v2.
Thanks!
Sven
On Fri, Dec 09, 2022 at 03:19:37PM +0100, Sven Schnelle wrote:
> Signed-off-by: Sven Schnelle <[email protected]>
> Acked-by: Heiko Carstens <[email protected]>
Looks pretty good and clean:
Acked-by: Willy Tarreau <[email protected]>
BTW I'm glad to see that splitting the qemu args lately made it much
easier to add new archs!
Willy
On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
> Use arch-x86_64 as a template. Not really different, but
> we have our own mmap syscall which takes a structure instead
> of discrete arguments.
I'm fine with placing the mmap syscall inside the arch-s390 file, though
it differs from what's done for other syscalls. But I admit that mmap is
one of these syscalls that differ between various archs and that it's not
shocking to leave it per-arch.
However you're having an issue here:
> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
> new file mode 100644
> index 000000000000..34b744e2f7d6
> --- /dev/null
> +++ b/tools/include/nolibc/arch-s390.h
^^^^^^^^^
vs:
> diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
> index 4c6992321b0d..fcded65b98d7 100644
> --- a/tools/include/nolibc/arch.h
> +++ b/tools/include/nolibc/arch.h
> @@ -27,6 +27,8 @@
> #include "arch-mips.h"
> #elif defined(__riscv)
> #include "arch-riscv.h"
> +#elif defined(__s390x__)
> +#include "arch-s390x.h"
^^^^^^^^^^
As you see the file is not the same so if you build by including nolibc.h
directly it will not work. The difference between s390 and s390x has never
been very clear to me, so I can't easily suggest which name is the most
suitable, but you'll definitely have to choose one :-) If it's just a
matter of dropping that trailing 'x' there, I think we can fix your patch
here without re-submitting, let us know.
Once this one is fixed, I'm fine with this:
Acked-by: Willy Tarreau <[email protected]>
Willy
On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> Willy Tarreau <[email protected]> writes:
>
> > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> >> So it should be:
> >>
> >> >> +#elif defined(__s390x__)
> >> >> +#include "arch-s390.h"
> >>
> >> I'm fine with both - either you fixing it up or me sending a v2.
> >
> > As you like. If you prefer to rename the file to s390x as your colleague
> > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > drop that 'x' in the #include.
>
> Just drop the 'x'. Thanks! :)
OK will do, thank you!
Wlily
Willy Tarreau <[email protected]> writes:
> On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
>> So it should be:
>>
>> >> +#elif defined(__s390x__)
>> >> +#include "arch-s390.h"
>>
>> I'm fine with both - either you fixing it up or me sending a v2.
>
> As you like. If you prefer to rename the file to s390x as your colleague
> suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> drop that 'x' in the #include.
Just drop the 'x'. Thanks! :)
On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > Willy Tarreau <[email protected]> writes:
> >
> > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > >> So it should be:
> > >>
> > >> >> +#elif defined(__s390x__)
> > >> >> +#include "arch-s390.h"
> > >>
> > >> I'm fine with both - either you fixing it up or me sending a v2.
> > >
> > > As you like. If you prefer to rename the file to s390x as your colleague
> > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > drop that 'x' in the #include.
> >
> > Just drop the 'x'. Thanks! :)
>
> OK will do, thank you!
And I have queued this series with Willy's acks on the first three and
the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
tree's "dev" branch.
But please double-check to make sure that I removed the correct "x"
and that there are not others that I missed!
Thanx, Paul
On Sat, Dec 10, 2022 at 09:57:14AM -0800, Paul E. McKenney wrote:
> On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> > On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > > Willy Tarreau <[email protected]> writes:
> > >
> > > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > > >> So it should be:
> > > >>
> > > >> >> +#elif defined(__s390x__)
> > > >> >> +#include "arch-s390.h"
> > > >>
> > > >> I'm fine with both - either you fixing it up or me sending a v2.
> > > >
> > > > As you like. If you prefer to rename the file to s390x as your colleague
> > > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > > drop that 'x' in the #include.
> > >
> > > Just drop the 'x'. Thanks! :)
> >
> > OK will do, thank you!
>
> And I have queued this series with Willy's acks on the first three and
> the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
> tree's "dev" branch.
>
> But please double-check to make sure that I removed the correct "x"
> and that there are not others that I missed!
Just checked, looks good to me, many thanks Paul!
Willy
On Sat, Dec 10, 2022 at 11:05:04PM +0100, Willy Tarreau wrote:
> On Sat, Dec 10, 2022 at 09:57:14AM -0800, Paul E. McKenney wrote:
> > On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> > > On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > > > Willy Tarreau <[email protected]> writes:
> > > >
> > > > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > > > >> So it should be:
> > > > >>
> > > > >> >> +#elif defined(__s390x__)
> > > > >> >> +#include "arch-s390.h"
> > > > >>
> > > > >> I'm fine with both - either you fixing it up or me sending a v2.
> > > > >
> > > > > As you like. If you prefer to rename the file to s390x as your colleague
> > > > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > > > drop that 'x' in the #include.
> > > >
> > > > Just drop the 'x'. Thanks! :)
> > >
> > > OK will do, thank you!
> >
> > And I have queued this series with Willy's acks on the first three and
> > the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
> > tree's "dev" branch.
> >
> > But please double-check to make sure that I removed the correct "x"
> > and that there are not others that I missed!
>
> Just checked, looks good to me, many thanks Paul!
Whew! And thank you for checking!
Thanx, Paul
Hi Sven,
On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
> Use arch-x86_64 as a template. Not really different, but
> we have our own mmap syscall which takes a structure instead
> of discrete arguments.
(...)
This evening I downloaded an s390 toolchain from kernel.org's nolibc
toolchains and expected to test the code under qemu, but I met two
build errors.
The first one is that __maybe_unused breaks the build below:
> +static __maybe_unused
> +void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
> + off_t offset)
And indeed, __maybe_unused is not defined here in userland. The following
patch allows to go further:
diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
index 34b744e2f7d6..effae6e3d9e2 100644
--- a/tools/include/nolibc/arch-s390.h
+++ b/tools/include/nolibc/arch-s390.h
@@ -194,7 +194,7 @@ struct s390_mmap_arg_struct {
unsigned long offset;
};
-static __maybe_unused
+static __attribute__((unused))
void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset)
{
But with this addressed, I'm facing this next error:
$ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
MKDIR sysroot/s390/include
make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
make[2]: Entering directory '/g/public/linux/master'
make[2]: Leaving directory '/g/public/linux/master'
make[2]: Entering directory '/g/public/linux/master'
INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/g/public/linux/master'
make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
CC nolibc-test
/tmp/ccCzaBgD.s: Assembler messages:
/tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
/tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
/tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
make: *** [Makefile:108: nolibc-test] Error 1
Thus I'm wondering if specific options are required for the compiler
(it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
or if there's anything wrong in the asm code (e.g. maybe by accident you
sent the patch from an earlier development branch), or anything else ?
FWIW I've used the patches from Paul's dev branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=dev
And the s390 toolchain from here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/
Thanks in advance for any help,
Willy
Hi Willy,
Willy Tarreau <[email protected]> writes:
> On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
>> Use arch-x86_64 as a template. Not really different, but
>> we have our own mmap syscall which takes a structure instead
>> of discrete arguments.
> (...)
>
> This evening I downloaded an s390 toolchain from kernel.org's nolibc
> toolchains and expected to test the code under qemu, but I met two
> build errors.
>
> The first one is that __maybe_unused breaks the build below:
>
>> +static __maybe_unused
>> +void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
>> + off_t offset)
>
> And indeed, __maybe_unused is not defined here in userland. The following
> patch allows to go further:
>
> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
> index 34b744e2f7d6..effae6e3d9e2 100644
> --- a/tools/include/nolibc/arch-s390.h
> +++ b/tools/include/nolibc/arch-s390.h
> @@ -194,7 +194,7 @@ struct s390_mmap_arg_struct {
> unsigned long offset;
> };
>
> -static __maybe_unused
> +static __attribute__((unused))
> void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
> off_t offset)
> {
Hrm, yes. I didn't thought about this macro not being present.
> But with this addressed, I'm facing this next error:
>
> $ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
> MKDIR sysroot/s390/include
> make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> make[2]: Entering directory '/g/public/linux/master'
> make[2]: Leaving directory '/g/public/linux/master'
> make[2]: Entering directory '/g/public/linux/master'
> INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/g/public/linux/master'
> make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> CC nolibc-test
> /tmp/ccCzaBgD.s: Assembler messages:
> /tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
> /tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
> /tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
> make: *** [Makefile:108: nolibc-test] Error 1
>
> Thus I'm wondering if specific options are required for the compiler
> (it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
> or if there's anything wrong in the asm code (e.g. maybe by accident you
> sent the patch from an earlier development branch), or anything else ?
Hmm, tried this on my x86 laptop, and it looks like there are two things
here:
The cross compiler needs -m64 to compile in 64bit mode. otherwise it
assumes 31bit mode, where both lg and lghi are not present. The other
thing is that lay was introduced with later generations of the
z/Architecture. The kernel compiles with z10 as minimum architecture, so
i'm leaning towards enforcing the same arch for nolibc. What do you think?
Hi Sven,
On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
> > But with this addressed, I'm facing this next error:
> >
> > $ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
> > MKDIR sysroot/s390/include
> > make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> > make[2]: Entering directory '/g/public/linux/master'
> > make[2]: Leaving directory '/g/public/linux/master'
> > make[2]: Entering directory '/g/public/linux/master'
> > INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> > make[2]: Leaving directory '/g/public/linux/master'
> > make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> > CC nolibc-test
> > /tmp/ccCzaBgD.s: Assembler messages:
> > /tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
> > /tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
> > /tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
> > make: *** [Makefile:108: nolibc-test] Error 1
> >
> > Thus I'm wondering if specific options are required for the compiler
> > (it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
> > or if there's anything wrong in the asm code (e.g. maybe by accident you
> > sent the patch from an earlier development branch), or anything else ?
>
> Hmm, tried this on my x86 laptop, and it looks like there are two things
> here:
>
> The cross compiler needs -m64 to compile in 64bit mode. otherwise it
> assumes 31bit mode, where both lg and lghi are not present. The other
> thing is that lay was introduced with later generations of the
> z/Architecture.
Ah, this explains why along my various tests at some point I managed
to remove two of these errors (likely with -m64)!
> The kernel compiles with z10 as minimum architecture, so
> i'm leaning towards enforcing the same arch for nolibc. What do you think?
Sure, as long as this works for most users, that's likely fine.
Alternately, are there equivalent sequences of instructions that achieve
the same on older architectures, and would that be relevant ?
One future improvement I'll need will be to store the envp value into a
global "environ" variable, and run over it to catch the pointer that
follows the NULL and save it into the "_auxv" variable. I've done it for
all other archs here already:
https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
I'll give it a try once I'm able to build and test your code, and may
ask you for some help if I don't succeed in doing it. If you want to do
it yourself, please have a look at the last commits adding environ and
auxv to any arch of your choice, such as x86_64.
Thanks!
Willy
Willy Tarreau <[email protected]> writes:
> On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
>> The kernel compiles with z10 as minimum architecture, so
>> i'm leaning towards enforcing the same arch for nolibc. What do you think?
>
> Sure, as long as this works for most users, that's likely fine.
> Alternately, are there equivalent sequences of instructions that achieve
> the same on older architectures, and would that be relevant ?
Well, it's only one instruction that needs to be changed - we could also
use aghi to do the same thing. Maybe that's better.
Also i will add -m64 to the testing Makefile, it shouldn't hurt.
> One future improvement I'll need will be to store the envp value into a
> global "environ" variable, and run over it to catch the pointer that
> follows the NULL and save it into the "_auxv" variable. I've done it for
> all other archs here already:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
>
> I'll give it a try once I'm able to build and test your code, and may
> ask you for some help if I don't succeed in doing it. If you want to do
> it yourself, please have a look at the last commits adding environ and
> auxv to any arch of your choice, such as x86_64.
Ok, thanks for the Heads-Up. I'll take a look. I think i would send this
as a separate Patch, so we get the initial support done first if that's ok.
On Mon, Jan 02, 2023 at 10:33:08AM +0100, Sven Schnelle wrote:
> Willy Tarreau <[email protected]> writes:
>
> > On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
> >> The kernel compiles with z10 as minimum architecture, so
> >> i'm leaning towards enforcing the same arch for nolibc. What do you think?
> >
> > Sure, as long as this works for most users, that's likely fine.
> > Alternately, are there equivalent sequences of instructions that achieve
> > the same on older architectures, and would that be relevant ?
>
> Well, it's only one instruction that needs to be changed - we could also
> use aghi to do the same thing. Maybe that's better.
>
> Also i will add -m64 to the testing Makefile, it shouldn't hurt.
>
> > One future improvement I'll need will be to store the envp value into a
> > global "environ" variable, and run over it to catch the pointer that
> > follows the NULL and save it into the "_auxv" variable. I've done it for
> > all other archs here already:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
> >
> > I'll give it a try once I'm able to build and test your code, and may
> > ask you for some help if I don't succeed in doing it. If you want to do
> > it yourself, please have a look at the last commits adding environ and
> > auxv to any arch of your choice, such as x86_64.
>
> Ok, thanks for the Heads-Up. I'll take a look. I think i would send this
> as a separate Patch, so we get the initial support done first if that's ok.
Yes absolutely, that was also my intent. I have not yet submitted this
series.
Thanks!
Willy