[PATCH v4 03/24] arm64: rename COMPAT to AARCH32_EL0 in Kconfig
From: Andrew Pinski Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/Kconfig | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e9733..6211b3f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -669,9 +669,13 @@ menu "Userspace binary formats" source "fs/Kconfig.binfmt" config COMPAT + def_bool y + depends on AARCH32_EL0 + select COMPAT_BINFMT_ELF + +config AARCH32_EL0 bool "Kernel support for 32-bit EL0" depends on !ARM64_64K_PAGES - select COMPAT_BINFMT_ELF select HAVE_UID16 select OLD_SIGSUSPEND3 select COMPAT_OLD_SIGACTION @@ -685,7 +689,7 @@ config COMPAT config SYSVIPC_COMPAT def_bool y - depends on COMPAT && SYSVIPC + depends on AARCH32_EL0 && SYSVIPC endmenu -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 24/24] arm64:ilp32: add ARM64_ILP32 to Kconfig
From: Andrew Pinski This patch adds the config option for ILP32. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/Kconfig | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 6211b3f..0725a60 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -670,7 +670,7 @@ source "fs/Kconfig.binfmt" config COMPAT def_bool y - depends on AARCH32_EL0 + depends on AARCH32_EL0 || ARM64_ILP32 select COMPAT_BINFMT_ELF config AARCH32_EL0 @@ -687,6 +687,13 @@ config AARCH32_EL0 If you want to execute 32-bit userspace applications, say Y. +config ARM64_ILP32 + bool "Kernel support for ILP32" + help + This option enables support for AArch64 ILP32 user space. ILP32 + is an ABI where long and pointers are 32bits but it uses the AARCH64 + instruction set. + config SYSVIPC_COMPAT def_bool y depends on AARCH32_EL0 && SYSVIPC -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 19/24] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
From: Andrew Pinski Add a separate syscall-table for ILP32, which dispatches either to native LP64 system call implementation or to compat-syscalls, as appropriate. This revision of the patch now addresses Catalin's comment regarding the duplicate reading of the task-flags in the el0_svc-handler and simply relies on the flags having been read by the kernel_entry macro. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/include/asm/unistd.h | 4 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/entry.S | 12 ++- arch/arm64/kernel/sys_ilp32.c | 173 4 files changed, 189 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/kernel/sys_ilp32.c diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h index bed97c3..10397e8 100644 --- a/arch/arm64/include/asm/unistd.h +++ b/arch/arm64/include/asm/unistd.h @@ -13,6 +13,10 @@ * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ +#ifdef CONFIG_ARM64_ILP32 +#define __ARCH_WANT_COMPAT_SYS_PREADV64 +#define __ARCH_WANT_COMPAT_SYS_PWRITEV64 +#endif #ifdef CONFIG_AARCH32_EL0 #define __ARCH_WANT_COMPAT_SYS_GETDENTS64 #define __ARCH_WANT_COMPAT_STAT64 diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index 3cf8120..131996d 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -23,6 +23,7 @@ arm64-obj-$(CONFIG_AARCH32_EL0) += sys32.o kuser32.o signal32.o \ sys_compat.o entry32.o \ ../../arm/kernel/opcodes.o arm64-obj-$(CONFIG_FUNCTION_TRACER)+= ftrace.o entry-ftrace.o +arm64-obj-$(CONFIG_ARM64_ILP32)+= sys_ilp32.o arm64-obj-$(CONFIG_MODULES)+= arm64ksyms.o module.o arm64-obj-$(CONFIG_SMP)+= smp.o smp_spin_table.o topology.o arm64-obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index 0dce3d0..39fdf67 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -642,9 +642,13 @@ ENDPROC(ret_from_fork) */ .align 6 el0_svc: - adrpstbl, sys_call_table// load syscall table pointer uxtwscno, w8// syscall number in w8 mov sc_nr, #__NR_syscalls +#ifdef CONFIG_ARM64_ILP32 + ldr x16, [tsk, #TI_FLAGS] + tbnzx16, #TIF_32BIT_AARCH64, el0_ilp32_svc // We are using ILP32 +#endif + adrpstbl, sys_call_table// load syscall table pointer el0_svc_naked: // compat entry point stp x0, scno, [sp, #S_ORIG_X0] // save the original x0 and syscall number enable_dbg_and_irq @@ -664,6 +668,12 @@ ni_sys: b ret_fast_syscall ENDPROC(el0_svc) +#ifdef CONFIG_ARM64_ILP32 +el0_ilp32_svc: + adrpstbl, sys_call_ilp32_table // load syscall table pointer + b el0_svc_naked +#endif + /* * This is the really slow path. We're going to be doing context * switches, and waiting for our parent to respond. diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c new file mode 100644 index 000..06c05ce --- /dev/null +++ b/arch/arm64/kernel/sys_ilp32.c @@ -0,0 +1,173 @@ +/* + * AArch64- ILP32 specific system calls implementation + * + * Copyright (C) 2013 Cavium Inc. + * Author: Andrew Pinski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see <http://www.gnu.org/licenses/>. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * Wrappers to pass the pt_regs argument. + */ +#define sys_rt_sigreturnsys_rt_sigreturn_wrapper + +/* Using Compat syscalls where necessary */ +#define sys_ioctl compat_sys_ioctl +/* iovec */ +#define sys_readv compat_sys_readv +#define sys_writev compat_sys_writev +#define sys_preadv compat_sys_preadv64 +#define sys_pwritevcompat_sys_pwritev64 +#define sys_vmsplice compat_sys_vmsplice +/* robust_list_head */ +#define sys_set_robust_listcompat_sys_set_robust_list +#define sys_get_robust_listcompat_sys_get_robust_list + +/* kex
[PATCH v4 09/24] arm64:ilp32: use non-compat syscall names for ILP32 as for LP64
From: Andrew Pinski Define __ARCH_WANT_64BIT_SYSCALLS for ILP32, so we (can) use the 64bit syscall names for ILP32. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/include/uapi/asm/unistd.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/include/uapi/asm/unistd.h b/arch/arm64/include/uapi/asm/unistd.h index 1caadc2..067eab0 100644 --- a/arch/arm64/include/uapi/asm/unistd.h +++ b/arch/arm64/include/uapi/asm/unistd.h @@ -1,5 +1,6 @@ /* * Copyright (C) 2012 ARM Ltd. + * Copyright (C) 2014 Cavium Inc. * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as @@ -13,4 +14,10 @@ * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ + +/* For ILP32 AARCH64, we want to use the non compat names. */ +#if defined(__aarch64__) && defined(__ILP32__) +#define __SYSCALL_NONCOMPAT +#endif + #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 23/24] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32
To make life for tools (such as gdb) easier when dealing with ILP32 processes,
we report a proper subarchitecture for ILP32 in the ELF auxiliary vectors.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/elf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index ff005d9..c35922c 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -168,9 +168,9 @@ extern unsigned long arch_randomize_brk(struct mm_struct
*mm);
#ifdef CONFIG_COMPAT
#ifdef __AARCH64EB__
-#define COMPAT_ELF_PLATFORM("v8b")
+#define COMPAT_ELF_PLATFORM(is_ilp32_compat_task() ?
"aarch64_be:ilp32" : "v8b")
#else
-#define COMPAT_ELF_PLATFORM("v8l")
+#define COMPAT_ELF_PLATFORM(is_ilp32_compat_task() ?
"aarch64:ilp32" : "v8l")
#endif
#define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 16/24] arm64: add support for starting ILP32 (ELFCLASS32) binaries
From: Andrew Pinski
Handle ILP32 (AArch64, but ELFCLASS32) binaries on ARM64.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/elf.h | 66 +---
1 file changed, 56 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 8218925..ff005d9 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -135,7 +135,11 @@ extern unsigned long randomize_et_dyn(unsigned long base);
*/
#define ELF_PLAT_INIT(_r, load_addr) (_r)->regs[0] = 0
-#define SET_PERSONALITY(ex)clear_thread_flag(TIF_32BIT);
+#define SET_PERSONALITY(ex)\
+do { \
+ clear_thread_flag(TIF_32BIT_AARCH64); \
+ clear_thread_flag(TIF_32BIT); \
+} while (0)
#define ARCH_DLINFO\
do { \
@@ -185,25 +189,28 @@ typedef compat_a32_elf_greg_t
compat_a32_elf_gregset_t[COMPAT_A32_ELF_NGREG];
((x)->e_flags & EF_ARM_EABI_MASK))
#define compat_start_threadcompat_start_thread
-#define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
-#define COMPAT_ARCH_DLINFO
+#define COMPAT_A32_SET_PERSONALITY(ex) \
+do { \
+ clear_thread_flag(TIF_32BIT_AARCH64); \
+ set_thread_flag(TIF_32BIT); \
+} while (0)
+#define COMPAT_A32_ARCH_DLINFO do {} while (0)
extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
int uses_interp);
-#define compat_arch_setup_additional_pages \
- aarch32_setup_vectors_page
#else
-
typedef elf_greg_t compat_elf_greg_t;
typedef elf_gregset_t compat_elf_gregset_t;
#define compat_a32_elf_check_arch(x) 0
-#define COMPAT_SET_PERSONALITY(ex)
-#define COMPAT_ARCH_DLINFO
-
+#define COMPAT_A32_SET_PERSONALITY(ex) do {} while (0)
+#define COMPAT_A32_ARCH_DLINFO do {} while (0)
+#define aarch32_setup_vectors_page(x, y) -EINVAL
#endif
+
+
/* If ILP32 is turned on, we want to define the compat_elf_greg_t to the non
compat
one and define PR_REG_SIZE/PRSTATUS_SIZE/SET_PR_FPVALID so we pick up the
correct
ones for AARCH32. Note also the definition of the macros have to be correct
for
@@ -222,7 +229,46 @@ typedef compat_a32_elf_greg_t compat_elf_greg_t;
typedef compat_a32_elf_gregset_t compat_elf_gregset_t;
#endif
-#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
+#ifdef CONFIG_ARM64_ILP32
+#define compat_ilp32_elf_check_arch(x) ((x)->e_machine == EM_AARCH64)
+#define COMPAT_ILP32_SET_PERSONALITY(ex) \
+do { \
+ set_thread_flag(TIF_32BIT_AARCH64); \
+ clear_thread_flag(TIF_32BIT); \
+} while (0)
+#define COMPAT_ILP32_ARCH_DLINFO \
+do { \
+ NEW_AUX_ENT(AT_SYSINFO_EHDR,\
+ (elf_addr_t)(long)current->mm->context.vdso); \
+} while (0)
+#else
+#define compat_ilp32_elf_check_arch(x) 0
+#define COMPAT_ILP32_SET_PERSONALITY(ex) do {} while (0)
+#define COMPAT_ILP32_ARCH_DLINFO do {} while (0)
+#endif
+
+#define compat_elf_check_arch(x) (compat_a32_elf_check_arch(x) ||
compat_ilp32_elf_check_arch(x))
+#define COMPAT_SET_PERSONALITY(ex) \
+do { \
+ if (compat_a32_elf_check_arch(&ex)) \
+ COMPAT_A32_SET_PERSONALITY(ex); \
+ else\
+ COMPAT_ILP32_SET_PERSONALITY(ex); \
+} while (0)
+
+/* ILP32 uses the "LP64-like" vdso pages */
+#define compat_arch_setup_additional_pages \
+ (is_a32_compat_task() \
+? &aarch32_setup_vectors_page \
+: &(arch_setup_additional_pages))
+
+#define COMPAT_ARCH_DLINFO \
+do { \
+ if (is_a32_compat_task()) \
+ COMPAT_A32_ARCH_DLINFO; \
+ else\
+ COMPAT_ILP32_ARCH_DLINFO; \
+} while (0)
#endif /* CONFIG_COMPAT */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 12/24] arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks
Since __kernel_long_t (time_t) is long long, we need to tell the rest of
kernel that we use 64bit time_t for compat when the task is not an
AARCH32 task. The reason why we check AARCH32 rather than ILP32 here is
because if we don't have AARCH32 compiled in (which is going to be the
common case due to AARCH32 requiring 4k pages).
Stricly speaking, a 'long long' time_t is not standards-compliant
(refer to https://sourceware.org/bugzilla/show_bug.cgi?id=16437 for
details), but there is precedent (i.e. x32) for such an implementation both
in the kernel and in glibc.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/compat.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index f53c4e6..4b717df 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -76,6 +76,9 @@ struct compat_timeval {
s32 tv_usec;
};
+/* ILP32 uses 64bit time_t and not the above compat structures */
+#define COMPAT_USE_64BIT_TIME !is_a32_compat_task()
+
struct compat_stat {
#ifdef __AARCH64EB__
short st_dev;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 00/24] ILP32 for ARM64
This is an updated version of Andrew Pinski's ILP32 patch-series for ARM64
(see https://lkml.org/lkml/2014/9/3/704) which merges some changes from our
implementation of ILP32 with his.
I made sure to have Andrew as an author, wherever no significant
changes to his patches occurred and updated the author field on the
others, so it's easier for reviewers (and for Andrew) to track what
changed and what did not... we've also tried to address as outstanding
review comments against those patches if we were aware of those (as a
result and an exception to the aforementioned rule, some of original patches
may have been updated, even if we the below list doesn't make it apparent).
Note that we didn't resort to changing the time_t definition to 32bit for
ILP32 (related to https://sourceware.org/bugzilla/show_bug.cgi?id=16437).
This patch-series has been verified using LTP in a buildroot-environment
with no unexpected fails (note, that the io_submit test currently fails,
as we haven't updated the userspace data-structures in libaio for ILP32,
yet). There's a full set of matching changes to binutils, gdb, gcc, glibc,
strace, LTP and openssl (probably other packages,too) to be submitted, once
we have the kernel-level ABI changes committed.
If anybody wants to rerun LTP, let me know, so I can provide a
buildroot-generated rootfs-image via FTP.
The key differences from earlier changesets are:
* updated to 4.0
* fixes for functions using 'struct msgbuf' (using compat)
* deduplication of code by using a 32bit stack_t (using compat)
* updated the documentation to clarify the changes to stack_t
* introduced a sub-architecture (via COMPAT_ELF_PLATFORM) to make
life easier for tools (e.g. gdb) when attaching to a live process
(a corefile is easily distinguishable by being ELFCLASS32).
Any review comments are welcome.
--Phil.
Andrew Pinski (18):
arm64: ensure the kernel is compiled for LP64
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0
instead
arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64:ilp32: share signal structures between ILP32 and LP64 ABIs
arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit
registers
arm64:ilp32: use non-compat syscall names for ILP32 as for LP64
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64:ilp32: share HWCAP between LP64 and ILP32
arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads
arm64:ilp32: support core dump generation for ILP32
arm64: add support for starting ILP32 (ELFCLASS32) binaries
ptrace: Allow compat to use the native siginfo
arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
it
arm64:ilp32: use the native siginfo instead of the compat siginfo
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (6):
arm64:ilp32: add documentation on the ILP32 ABI for ARM64
arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks
arm64:ilp32: add vdso-ilp32 and use for signal return
arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32
arm64:ilp32: use compat for stack_t
arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for
ILP32
Documentation/arm64/ilp32.txt | 64
arch/arm64/Kconfig| 15 ++-
arch/arm64/Makefile | 4 +
arch/arm64/include/asm/compat.h | 65 +++-
arch/arm64/include/asm/elf.h | 105 +---
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/hwcap.h| 12 ++-
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/include/asm/processor.h| 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/signal32.h | 2 +
arch/arm64/include/asm/stat.h | 2 +
arch/arm64/include/asm/thread_info.h | 3 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/vdso.h | 4 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/include/uapi/asm/posix_types.h | 12 ++-
arch/arm64/include/uapi/asm/siginfo.h | 21
arch/arm64/include/uapi/asm/signal.h | 32 ++
arch/arm64/include/uapi/asm/unistd.h | 7 ++
arch/arm64/kernel/Makefile| 8 +-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 18 +++-
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 6 +-
arch/arm64/kernel/process.c | 6 +-
arch/arm64/ker
[PATCH v4 18/24] ptrace: Allow compat to use the native siginfo
From: Andrew Pinski
Set COMPAT_USE_NATIVE_SIGINFO to be true for non AARCH32 tasks.
With ARM64 ILP32 ABI, we want to use the non-compat
siginfo as we want to simplify signal handling for this new ABI.
This patch just adds a new define COMPAT_USE_NATIVE_SIGINFO and
if it is true then read/write in the compat case as it was the
non-compat case.
Signed-off-by: Christoph Muellner
Signed-off-by: Philipp Tomsich
---
include/linux/compat.h | 4
kernel/ptrace.c| 24 +---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index ab25814..d11c556 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -24,6 +24,10 @@
#define COMPAT_USE_64BIT_TIME 0
#endif
+#ifndef COMPAT_USE_NATIVE_SIGINFO
+#define COMPAT_USE_NATIVE_SIGINFO 0
+#endif
+
#ifndef __SC_DELOUSE
#define __SC_DELOUSE(t,v) ((t)(unsigned long)(v))
#endif
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 227fec3..5bea58b 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -640,7 +640,7 @@ static int ptrace_peek_siginfo(struct task_struct *child,
break;
#ifdef CONFIG_COMPAT
- if (unlikely(is_compat_task())) {
+ if (unlikely(is_compat_task() && !COMPAT_USE_NATIVE_SIGINFO)) {
compat_siginfo_t __user *uinfo = compat_ptr(data);
if (copy_siginfo_to_user32(uinfo, &info) ||
@@ -1108,16 +1108,26 @@ int compat_ptrace_request(struct task_struct *child,
compat_long_t request,
case PTRACE_GETSIGINFO:
ret = ptrace_getsiginfo(child, &siginfo);
- if (!ret)
- ret = copy_siginfo_to_user32(
- (struct compat_siginfo __user *) datap,
- &siginfo);
+ if (!ret) {
+ if (COMPAT_USE_NATIVE_SIGINFO)
+ ret = copy_siginfo_to_user(
+ (struct siginfo __user *) datap,
+ &siginfo);
+ else
+ ret = copy_siginfo_to_user32(
+ (struct compat_siginfo __user *) datap,
+ &siginfo);
+ }
break;
case PTRACE_SETSIGINFO:
memset(&siginfo, 0, sizeof siginfo);
- if (copy_siginfo_from_user32(
- &siginfo, (struct compat_siginfo __user *) datap))
+ if (COMPAT_USE_NATIVE_SIGINFO)
+ ret = copy_from_user(&siginfo, datap, sizeof(siginfo));
+ else
+ ret = copy_siginfo_from_user32(
+&siginfo, (struct compat_siginfo __user *)
datap);
+ if (ret)
ret = -EFAULT;
else
ret = ptrace_setsiginfo(child, &siginfo);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/24] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs
From: Andrew Pinski
Defines the macros which allow the signal structures to be the same between
ILP32 and LP64.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/uapi/asm/siginfo.h | 21 +
arch/arm64/include/uapi/asm/signal.h | 32
include/uapi/asm-generic/siginfo.h| 17 +
include/uapi/asm-generic/signal.h | 27 +++
4 files changed, 89 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/siginfo.h
b/arch/arm64/include/uapi/asm/siginfo.h
index 5a74a08..1a6aa32 100644
--- a/arch/arm64/include/uapi/asm/siginfo.h
+++ b/arch/arm64/include/uapi/asm/siginfo.h
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2012 ARM Ltd.
+ * Copyright (C) 2014 Cavium Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -18,6 +19,26 @@
#define __ARCH_SI_PREAMBLE_SIZE(4 * sizeof(int))
+#ifdef __ILP32__
+# ifdef __AARCH64EB__
+# define __SIGINFO_INNER(type, field) \
+ int __pad#field;\
+ type field
+# else
+# define __SIGINFO_INNER(type, field) \
+ type field; \
+ int __pad#field
+# endif
+
+# undef __SIGINFO_VOIDPOINTER
+# define __SIGINFO_VOIDPOINTER(field) \
+ __SIGINFO_INNER(void __user*, field)
+# undef __SIGINFO_BAND
+
+# define __SIGINFO_BAND(field) \
+ __SIGINFO_INNER(long, field)
+#endif
+
#include
#endif
diff --git a/arch/arm64/include/uapi/asm/signal.h
b/arch/arm64/include/uapi/asm/signal.h
index 8d1e723..d90d53b 100644
--- a/arch/arm64/include/uapi/asm/signal.h
+++ b/arch/arm64/include/uapi/asm/signal.h
@@ -19,6 +19,38 @@
/* Required for AArch32 compatibility. */
#define SA_RESTORER0x0400
+/* For ILP32, sigset should be the same size fields as LP64 so use
+ unsigned long long. */
+#ifdef __ILP32__
+#define __SIGSET_INNER_TYPE __extension__ unsigned long long
+#define _NSIG_BPW 64
+
+# ifdef __AARCH64EB__
+# define __SIGNAL_INNER(type, field) \
+ __extension__ struct { \
+ int __pad_##field; \
+ type field; \
+ } __attribute__((aligned(8)))
+# else
+# define __SIGNAL_INNER(type, field) \
+ __extension__ struct { \
+ type field; \
+ int __pad_##field; \
+ } __attribute__((aligned(8)))
+# endif
+
+# define __SIGACTION_HANDLER(field)\
+ __SIGNAL_INNER(__sighandler_t, field)
+
+
+#define __SIGACTION_FLAGS(field) \
+ __extension__ unsigned long long field
+
+#define __SIGACTION_RESTORER(field)\
+ __SIGNAL_INNER(__sigrestore_t, field)
+
+#endif
+
#include
#endif
diff --git a/include/uapi/asm-generic/siginfo.h
b/include/uapi/asm-generic/siginfo.h
index 1e35520..be640a9 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -4,9 +4,17 @@
#include
#include
+#ifndef __SIGINFO_VOIDPOINTER
+#define __SIGINFO_VOIDPOINTER(field) void __user *field
+#endif
+
+#ifndef __SIGINFO_BAND
+#define __SIGINFO_BAND(field) __ARCH_SI_BAND_T field
+#endif
+
typedef union sigval {
int sival_int;
- void __user *sival_ptr;
+ __SIGINFO_VOIDPOINTER(sival_ptr);
} sigval_t;
/*
@@ -86,7 +94,7 @@ typedef struct siginfo {
/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
struct {
- void __user *_addr; /* faulting insn/memory ref. */
+ __SIGINFO_VOIDPOINTER(_addr); /* faulting insn/memory
ref. */
#ifdef __ARCH_SI_TRAPNO
int _trapno;/* TRAP # which caused the signal */
#endif
@@ -99,13 +107,13 @@ typedef struct siginfo {
/* SIGPOLL */
struct {
- __ARCH_SI_BAND_T _band; /* POLL_IN, POLL_OUT, POLL_MSG
*/
+ __SIGINFO_BAND(_band); /* POLL_IN, POLL_OUT, POLL_MSG
*/
int _fd;
} _sigpoll;
/* SIGSYS */
struct {
- void __user *_call_addr; /* calling user insn */
+ __SIGINFO_VOIDPOINTER(_call_addr); /* calling user insn
*/
int _syscall; /* triggering system call number */
unsigned int _arch; /* AUDIT_ARCH_* of syscall */
} _sigsys;
@@ -290,6 +298,7 @@ typedef struct sigevent {
int _pad[SIGEV_PAD_SIZE];
int _tid;
+ /* Note these two are handled only in userspace */
struct {
void (*_function)(sigval_t);
void *_attribute; /* really
[PATCH v4 20/24] arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32
msgsnd and msgrcv require the compat-layer, as they are defined to use data structures with a 'long' (32bit in ILP32, 64bit in LP64) element. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/kernel/sys_ilp32.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c index 06c05ce..3471f27 100644 --- a/arch/arm64/kernel/sys_ilp32.c +++ b/arch/arm64/kernel/sys_ilp32.c @@ -1,9 +1,12 @@ /* - * AArch64- ILP32 specific system calls implementation + * AArch64: ILP32 specific system calls implementation * * Copyright (C) 2013 Cavium Inc. * Author: Andrew Pinski * + * Copyright (C) 2014 Theobroma Systems GmbH + * + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. @@ -50,6 +53,10 @@ /* Ptrace has some structures which are different between ILP32 and LP64 */ #define sys_ptrace compat_sys_ptrace +/* message type is 64bit in LP64 and 32bit in ILP32 */ +#define sys_msgsnd compat_sys_msgsnd +#define sys_msgrcv compat_sys_msgrcv + /* struct msghdr */ #define sys_recvfrom compat_sys_recvfrom #define sys_recvmmsg compat_sys_recvmmsg -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 21/24] arm64:ilp32: use the native siginfo instead of the compat siginfo
From: Andrew Pinski
Set COMPAT_USE_NATIVE_SIGINFO to be true for non AARCH32 tasks.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/compat.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 4b717df..47f2b7a 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -217,6 +217,9 @@ typedef struct compat_siginfo {
} _sifields;
} compat_siginfo_t;
+/* ILP32 uses the native siginfo and not the compat struct */
+#define COMPAT_USE_NATIVE_SIGINFO !is_a32_compat_task()
+
#define COMPAT_OFF_T_MAX 0x7fff
#define COMPAT_LOFF_T_MAX 0x7fffL
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 02/24] arm64: ensure the kernel is compiled for LP64
From: Andrew Pinski The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 69ceedc..2ad0c34 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -18,14 +18,18 @@ GZFLAGS :=-9 KBUILD_DEFCONFIG := defconfig KBUILD_CFLAGS += -mgeneral-regs-only +KBUILD_CFLAGS += $(call cc-option,-mabi=lp64) +KBUILD_AFLAGS += $(call cc-option,-mabi=lp64) ifeq ($(CONFIG_CPU_BIG_ENDIAN), y) KBUILD_CPPFLAGS+= -mbig-endian AS += -EB LD += -EB +LDFLAGS+= -maarch64linuxb else KBUILD_CPPFLAGS+= -mlittle-endian AS += -EL LD += -EL +LDFLAGS+= -maarch64linux endif CHECKFLAGS += -D__aarch64__ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 14/24] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads
From: Andrew Pinski
If we have both ILP32 and AARCH32 compiled in, we need use the non compat start
thread for ILP32.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/processor.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index ea80e86..29ca21a 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -106,6 +106,15 @@ static inline void start_thread(struct pt_regs *regs,
unsigned long pc,
static inline void compat_start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
+#ifdef CONFIG_ARM64_ILP32
+ /* ILP32 thread are started the same way as LP64 threads.
+ Note we cannot use is_ilp32_compat_task here as that
+ would introduce a header depency issue. */
+ if (test_thread_flag(TIF_32BIT_AARCH64)) {
+ start_thread(regs, pc, sp);
+ return;
+ }
+#endif
start_thread_common(regs, pc);
regs->pstate = COMPAT_PSR_MODE_USR;
if (pc & 1)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/24] arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
From: Andrew Pinski
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/compat.h | 32 ++--
arch/arm64/include/asm/thread_info.h | 1 +
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 3a2976d..f53c4e6 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -319,6 +319,26 @@ static inline int is_a32_compat_thread(struct thread_info
*thread)
}
#endif
+#ifdef CONFIG_ARM64_ILP32
+static inline int is_ilp32_compat_task(void)
+{
+ return test_thread_flag(TIF_32BIT_AARCH64);
+}
+static inline int is_ilp32_compat_thread(struct thread_info *thread)
+{
+ return test_ti_thread_flag(thread, TIF_32BIT_AARCH64);
+}
+#else
+static inline int is_ilp32_compat_task(void)
+{
+ return 0;
+}
+static inline int is_ilp32_compat_thread(struct thread_info *thread)
+{
+ return 0;
+}
+#endif
+
#else /* !CONFIG_COMPAT */
static inline int is_compat_thread(struct thread_info *thread)
@@ -330,17 +350,25 @@ static inline int is_a32_compat_task(void)
{
return 0;
}
+static inline int is_ilp32_compat_task(void)
+{
+ return 0;
+}
+static inline int is_ilp32_compat_thread(struct thread_info *thread)
+{
+ return 0;
+}
#endif /* CONFIG_COMPAT */
static inline int is_compat_task(void)
{
- return is_a32_compat_task();
+ return is_a32_compat_task() || is_ilp32_compat_task();
}
static inline int is_compat_thread(struct thread_info *thread)
{
- return is_a32_compat_thread(thread);
+ return is_a32_compat_thread(thread) || is_ilp32_compat_thread(thread);
}
#endif /* __KERNEL__ */
#endif /* __ASM_COMPAT_H */
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index 75f8d56..d41586c 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -115,6 +115,7 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_SINGLESTEP 21
#define TIF_32BIT 22 /* AARCH32 process */
#define TIF_SWITCH_MM 23 /* deferred switch_mm */
+#define TIF_32BIT_AARCH64 24 /* 32 bit process on AArch64(ILP32) */
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
#define _TIF_NEED_RESCHED (1 << TIF_NEED_RESCHED)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 08/24] arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit registers
From: Andrew Pinski In the ARM64 ILP32 case, we want to say the syscalls that normally would pass 64bit as two arguments are now passing as one so want to use the 64bit naming scheme. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- include/uapi/asm-generic/unistd.h | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index e016bd9..398a890 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -885,8 +885,11 @@ __SYSCALL(__NR_fork, sys_ni_syscall) * they take different names. * Here we map the numbers so that both versions * use the same syscall table layout. + * For 32bit abis where 64bit can be passed via one + * register, use the same naming as the 64bit ones + * as they will only have a 64 bit off_t. */ -#if __BITS_PER_LONG == 64 && !defined(__SYSCALL_COMPAT) +#if (__BITS_PER_LONG == 64 && !defined(__SYSCALL_COMPAT)) || defined(__SYSCALL_NONCOMPAT) #define __NR_fcntl __NR3264_fcntl #define __NR_statfs __NR3264_statfs #define __NR_fstatfs __NR3264_fstatfs -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 22/24] arm64:ilp32: use compat for stack_t
We use a 'natively sized' stack_t in glibc (i.e. having a 32bit pointer for
ss_sp), which requires the invocation of the compat layer for the following
functionality:
* sigaltstack
* saving and restoring uc_stack during signal setup and returns
As the userspace stack_t is natively sized, we avoid code duplication in the
syscall table and can use the compat-functions to zero-extend the pointers
involved.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/kernel/signal.c| 19 +++
arch/arm64/kernel/sys_ilp32.c | 44 +--
2 files changed, 20 insertions(+), 43 deletions(-)
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 99e36be..b3f6e52 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
/*
* Do a signal return; undo the signal stack. These are aligned to 128-bit.
@@ -148,9 +149,22 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
if (restore_sigframe(regs, frame))
goto badframe;
+
+#if defined(CONFIG_ARM64_ILP32)
+ if (is_ilp32_compat_task()) {
+ /* For ILP32, we have a different stack_t (the ss_sp
+ field will be only 32bit sized), which fits into
+ the memory area reserved for the (larger) LP64
+ stack_t and which we place into uc_stack: this
+ implies padding after the ILP32 stack_t. */
+ if
(compat_restore_altstack((compat_stack_t*)&frame->uc.uc_stack))
+ goto badframe;
+ } else
+#endif
if (restore_altstack(&frame->uc.uc_stack))
goto badframe;
+
return regs->regs[0];
badframe:
@@ -264,6 +278,11 @@ static int setup_rt_frame(int usig, struct ksignal *ksig,
sigset_t *set,
__put_user_error(0, &frame->uc.uc_flags, err);
__put_user_error(NULL, &frame->uc.uc_link, err);
+#if defined(CONFIG_ARM64_ILP32)
+ if (is_ilp32_compat_task())
+ err |=
__compat_save_altstack((compat_stack_t*)&frame->uc.uc_stack, regs->sp);
+ else
+#endif
err |= __save_altstack(&frame->uc.uc_stack, regs->sp);
err |= setup_sigframe(frame, regs, set);
if (err == 0) {
diff --git a/arch/arm64/kernel/sys_ilp32.c b/arch/arm64/kernel/sys_ilp32.c
index 3471f27..31f82ca 100644
--- a/arch/arm64/kernel/sys_ilp32.c
+++ b/arch/arm64/kernel/sys_ilp32.c
@@ -77,6 +77,7 @@
/* Pointer in struct */
#define sys_mount compat_sys_mount
+#define sys_sigaltstack compat_sys_sigaltstack
/* NUMA */
/* unsigned long bitmaps */
@@ -122,49 +123,6 @@ asmlinkage long ilp32_sys_mq_notify(mqd_t mqdes, const
struct sigevent __user *u
but need special handling due to padding for SIGEV_THREAD. */
#define sys_mq_notify ilp32_sys_mq_notify
-
-/* sigaltstack needs some special handling as the
- padding for stack_t might not be non-zero. */
-long ilp32_sys_sigaltstack(const stack_t __user *uss_ptr,
- stack_t __user *uoss_ptr)
-{
- stack_t uss, uoss;
- int ret;
- mm_segment_t seg;
-
- if (uss_ptr) {
- if (!access_ok(VERIFY_READ, uss_ptr, sizeof(*uss_ptr)))
- return -EFAULT;
- if (__get_user(uss.ss_sp, &uss_ptr->ss_sp) |
- __get_user(uss.ss_flags, &uss_ptr->ss_flags) |
- __get_user(uss.ss_size, &uss_ptr->ss_size))
- return -EFAULT;
- /* Zero extend the sp address and the size. */
- uss.ss_sp = (void *)(uintptr_t)(unsigned
int)(uintptr_t)uss.ss_sp;
- uss.ss_size = (size_t)(unsigned int)uss.ss_size;
- }
- seg = get_fs();
- set_fs(KERNEL_DS);
- /* Note we need to use uoss as we have changed the segment to the
- kernel one so passing an user one around is wrong. */
- ret = sys_sigaltstack((stack_t __force __user *) (uss_ptr ? &uss :
NULL),
- (stack_t __force __user *) &uoss);
- set_fs(seg);
- if (ret >= 0 && uoss_ptr) {
- if (!access_ok(VERIFY_WRITE, uoss_ptr, sizeof(stack_t)) ||
- __put_user(uoss.ss_sp, &uoss_ptr->ss_sp) ||
- __put_user(uoss.ss_flags, &uoss_ptr->ss_flags) ||
- __put_user(uoss.ss_size, &uoss_ptr->ss_size))
- ret = -EFAULT;
- }
- return ret;
-}
-
-/* sigaltstack needs some special handling as the padding
- for stack_t might not be non-zero. */
-#define sys_sigaltstackilp32_sys_sigaltstack
-
-
#include
#undef __SYSCALL
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
[PATCH v4 05/24] arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32
From: Andrew Pinski
Since we want time_t and some other userland types to be the same
between ILP32 and LP64, we define __kernel_long_t to be long long.
To reuse the bulk of LP64 system calls (and data structures), the LP64
kernel data types ('kernel_long', 'kernel_ulong') are exposed as their
ILP32 'long long' and 'unsigned long long' equivalents to allow glibc
to correctly interpret most data-structures used in the kernel ABI
(i.el with the exception of those, that include pointers).
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/uapi/asm/posix_types.h | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/uapi/asm/posix_types.h
b/arch/arm64/include/uapi/asm/posix_types.h
index 7985ff6..d6a7cb5 100644
--- a/arch/arm64/include/uapi/asm/posix_types.h
+++ b/arch/arm64/include/uapi/asm/posix_types.h
@@ -5,6 +5,16 @@ typedef unsigned short __kernel_old_uid_t;
typedef unsigned short __kernel_old_gid_t;
#define __kernel_old_uid_t __kernel_old_uid_t
+#if defined(__ILP32__)
+/* The ILP32 kernel ABI reuses LP64 system calls where possible; to
+ this end, the equivalent ILP32 type definitions are used (a 64bit
+ 'long'-type in LP64 corresponds to a 'long long' in LP64). */
+
+typedef long long __kernel_long_t;
+typedef unsigned long long __kernel_ulong_t;
+#define __kernel_long_t __kernel_long_t
+#endif /* defined(__ILP32__) */
+
#include
-#endif /* __ASM_POSIX_TYPES_H */
+#endif /* __ASM_POSIX_TYPES_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 04/24] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead
From: Andrew Pinski
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/elf.h | 23 ---
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/signal32.h | 2 ++
arch/arm64/include/asm/stat.h | 2 ++
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/kernel/Makefile| 2 +-
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/entry.S | 6 +++---
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/ptrace.c| 31 ---
arch/arm64/kernel/signal.c| 13 +
arch/arm64/kernel/traps.c | 2 +-
arch/arm64/kernel/vdso.c | 4 ++--
14 files changed, 73 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 1f65be3..b73c2e2 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -171,24 +171,41 @@ extern unsigned long arch_randomize_brk(struct mm_struct
*mm);
#define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
+
+#ifdef CONFIG_AARCH32_EL0
+
/* AArch32 registers. */
-#define COMPAT_ELF_NGREG 18
+#define COMPAT_A32_ELF_NGREG 18
typedef unsigned int compat_elf_greg_t;
-typedef compat_elf_greg_t compat_elf_gregset_t[COMPAT_ELF_NGREG];
+typedef compat_elf_greg_t
compat_elf_gregset_t[COMPAT_A32_ELF_NGREG];
/* AArch32 EABI. */
#define EF_ARM_EABI_MASK 0xff00
-#define compat_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
+#define compat_a32_elf_check_arch(x) (((x)->e_machine == EM_ARM) && \
((x)->e_flags & EF_ARM_EABI_MASK))
#define compat_start_threadcompat_start_thread
#define COMPAT_SET_PERSONALITY(ex) set_thread_flag(TIF_32BIT);
#define COMPAT_ARCH_DLINFO
+
+
extern int aarch32_setup_vectors_page(struct linux_binprm *bprm,
int uses_interp);
#define compat_arch_setup_additional_pages \
aarch32_setup_vectors_page
+#else
+
+typedef elf_greg_t compat_elf_greg_t;
+typedef elf_gregset_t compat_elf_gregset_t;
+#define compat_a32_elf_check_arch(x) 0
+#define COMPAT_SET_PERSONALITY(ex)
+#define COMPAT_ARCH_DLINFO
+
+#endif
+
+#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
+
#endif /* CONFIG_COMPAT */
#endif
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index 50f559f..63b19f1 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -52,7 +52,7 @@ struct fpsimd_partial_state {
};
-#if defined(__KERNEL__) && defined(CONFIG_COMPAT)
+#if defined(__KERNEL__) && defined(CONFIG_AARCH32_EL0)
/* Masks for extracting the FPSR and FPCR from the FPSCR */
#define VFP_FPSCR_STAT_MASK0xf89f
#define VFP_FPSCR_CTRL_MASK0x07f79f00
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index d6dd9fd..a379596 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -120,7 +120,7 @@ struct pt_regs {
#define arch_has_single_step() (1)
-#ifdef CONFIG_COMPAT
+#ifdef CONFIG_AARCH32_EL0
#define compat_thumb_mode(regs) \
(((regs)->pstate & COMPAT_PSR_T_BIT))
#else
diff --git a/arch/arm64/include/asm/signal32.h
b/arch/arm64/include/asm/signal32.h
index eeaa975..4302909 100644
--- a/arch/arm64/include/asm/signal32.h
+++ b/arch/arm64/include/asm/signal32.h
@@ -20,6 +20,7 @@
#ifdef CONFIG_COMPAT
#include
+#ifdef CONFIG_AARCH32_EL0
#define AARCH32_KERN_SIGRET_CODE_OFFSET0x500
extern const compat_ulong_t aarch32_sigret_code[6];
@@ -47,6 +48,7 @@ static inline int compat_setup_rt_frame(int usig, struct
ksignal *ksig, sigset_t
static inline void compat_setup_restart_syscall(struct pt_regs *regs)
{
}
+#endif /* CONFIG_AARCH32_EL0 */
#endif /* CONFIG_COMPAT */
#endif /* __KERNEL__ */
#endif /* __ASM_SIGNAL32_H */
diff --git a/arch/arm64/include/asm/stat.h b/arch/arm64/include/asm/stat.h
index 15e3559..af04276 100644
--- a/arch/arm64/include/asm/stat.h
+++ b/arch/arm64/include/asm/stat.h
@@ -22,6 +22,7 @@
#include
+#ifdef CONFIG_AARCH32_EL0
/*
* struct stat64 is needed for compat tasks only. Its definition is different
* from the generic struct stat64.
@@ -59,3 +60,4 @@ struct stat64 {
#endif
#endif
+#endif
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 3bc498c..bed97c3 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -13,7 +13,7 @@
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
-#ifdef CONFIG_COMPAT
+#ifdef CON
[PATCH v4 10/24] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
From: Andrew Pinski
This patch introduces is_a32_compat_task and is_a32_thread so it is easier
to say this is a a32 specific thread or a generic compat thread/task.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/compat.h | 31 ---
arch/arm64/include/asm/elf.h | 2 +-
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/include/asm/thread_info.h | 2 +-
arch/arm64/kernel/hw_breakpoint.c| 6 +++---
arch/arm64/kernel/process.c | 6 +++---
arch/arm64/kernel/ptrace.c | 8
arch/arm64/kernel/signal.c | 4 ++--
arch/arm64/kernel/traps.c| 2 +-
10 files changed, 45 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 7fbed69..3a2976d 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -299,15 +299,25 @@ struct compat_shmid64_ds {
compat_ulong_t __unused5;
};
-static inline int is_compat_task(void)
+#ifdef CONFIG_AARCH32_EL0
+static inline int is_a32_compat_task(void)
{
return test_thread_flag(TIF_32BIT);
}
-
-static inline int is_compat_thread(struct thread_info *thread)
+static inline int is_a32_compat_thread(struct thread_info *thread)
{
return test_ti_thread_flag(thread, TIF_32BIT);
}
+#else
+static inline int is_a32_compat_task(void)
+{
+ return 0;
+}
+static inline int is_a32_compat_thread(struct thread_info *thread)
+{
+ return 0;
+}
+#endif
#else /* !CONFIG_COMPAT */
@@ -316,6 +326,21 @@ static inline int is_compat_thread(struct thread_info
*thread)
return 0;
}
+static inline int is_a32_compat_task(void)
+{
+ return 0;
+}
+
#endif /* CONFIG_COMPAT */
+
+static inline int is_compat_task(void)
+{
+ return is_a32_compat_task();
+}
+
+static inline int is_compat_thread(struct thread_info *thread)
+{
+ return is_a32_compat_thread(thread);
+}
#endif /* __KERNEL__ */
#endif /* __ASM_COMPAT_H */
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index b73c2e2..4e565dd 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -150,7 +150,7 @@ extern int arch_setup_additional_pages(struct linux_binprm
*bprm,
/* 1GB of VA */
#ifdef CONFIG_COMPAT
-#define STACK_RND_MASK (test_thread_flag(TIF_32BIT) ? \
+#define STACK_RND_MASK (is_compat_task() ? \
0x7ff >> (PAGE_SHIFT - 12) : \
0x3 >> (PAGE_SHIFT - 12))
#else
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index f800d45..960d059 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -58,7 +58,7 @@
#ifdef CONFIG_COMPAT
#define TASK_SIZE_32 UL(0x1)
-#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
+#define TASK_SIZE (is_compat_task() ? \
TASK_SIZE_32 : TASK_SIZE_64)
#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
TASK_SIZE_32 : TASK_SIZE_64)
diff --git a/arch/arm64/include/asm/processor.h
b/arch/arm64/include/asm/processor.h
index 20e9591..ea80e86 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -39,7 +39,7 @@
#define STACK_TOP_MAX TASK_SIZE_64
#ifdef CONFIG_COMPAT
#define AARCH32_VECTORS_BASE 0x
-#define STACK_TOP (test_thread_flag(TIF_32BIT) ? \
+#define STACK_TOP (is_compat_task() ? \
AARCH32_VECTORS_BASE : STACK_TOP_MAX)
#else
#define STACK_TOP STACK_TOP_MAX
diff --git a/arch/arm64/include/asm/thread_info.h
b/arch/arm64/include/asm/thread_info.h
index 702e1e6..75f8d56 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -113,7 +113,7 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_FREEZE 19
#define TIF_RESTORE_SIGMASK20
#define TIF_SINGLESTEP 21
-#define TIF_32BIT 22 /* 32bit process */
+#define TIF_32BIT 22 /* AARCH32 process */
#define TIF_SWITCH_MM 23 /* deferred switch_mm */
#define _TIF_SIGPENDING(1 << TIF_SIGPENDING)
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index 98bbe06..3fcfaa5 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -433,7 +433,7 @@ static int arch_build_bp_info(struct perf_event *bp)
* Watchpoints can be of length 1, 2, 4 or 8 bytes.
*/
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE) {
- if (is_compat_task()) {
+ i
[PATCH v4 13/24] arm64:ilp32: share HWCAP between LP64 and ILP32
From: Andrew Pinski Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/include/asm/hwcap.h | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h index 0ad7351..1e5361e 100644 --- a/arch/arm64/include/asm/hwcap.h +++ b/arch/arm64/include/asm/hwcap.h @@ -47,9 +47,17 @@ #define ELF_HWCAP (elf_hwcap) #ifdef CONFIG_COMPAT -#define COMPAT_ELF_HWCAP (compat_elf_hwcap) -#define COMPAT_ELF_HWCAP2 (compat_elf_hwcap2) extern unsigned int compat_elf_hwcap, compat_elf_hwcap2; +#define COMPAT_ELF_HWCAP \ + (is_a32_compat_task() \ + ? compat_elf_hwcap\ + : elf_hwcap) + +#define COMPAT_ELF_HWCAP2 \ + (is_a32_compat_task() \ + ? compat_elf_hwcap2 \ + : 0) + #endif extern unsigned long elf_hwcap; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 15/24] arm64:ilp32: support core dump generation for ILP32
From: Andrew Pinski
This patch supports core dumping on ILP32.
We need a few extra macros (COMPAT_PR_REG_SIZE and COMPAT_PRSTATUS_SIZE) due
to size differences of the register sets.
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/elf.h | 22 --
arch/arm64/kernel/ptrace.c | 12 ++--
2 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 4e565dd..8218925 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -176,8 +176,8 @@ extern unsigned long arch_randomize_brk(struct mm_struct
*mm);
/* AArch32 registers. */
#define COMPAT_A32_ELF_NGREG 18
-typedef unsigned int compat_elf_greg_t;
-typedef compat_elf_greg_t
compat_elf_gregset_t[COMPAT_A32_ELF_NGREG];
+typedef unsigned int compat_a32_elf_greg_t;
+typedef compat_a32_elf_greg_t
compat_a32_elf_gregset_t[COMPAT_A32_ELF_NGREG];
/* AArch32 EABI. */
#define EF_ARM_EABI_MASK 0xff00
@@ -204,6 +204,24 @@ typedef elf_gregset_t
compat_elf_gregset_t;
#endif
+/* If ILP32 is turned on, we want to define the compat_elf_greg_t to the non
compat
+ one and define PR_REG_SIZE/PRSTATUS_SIZE/SET_PR_FPVALID so we pick up the
correct
+ ones for AARCH32. Note also the definition of the macros have to be correct
for
+ LP64 as this file is included in the standard binfmt_elf.c. */
+#ifdef CONFIG_ARM64_ILP32
+typedef elf_greg_t compat_elf_greg_t;
+typedef elf_gregset_t compat_elf_gregset_t;
+#define PR_REG_SIZE(S) (is_a32_compat_task() ? 72 : 272)
+#define PRSTATUS_SIZE(S) (is_a32_compat_task() ? 124 :
(is_ilp32_compat_task() ? 352 : 392))
+#define SET_PR_FPVALID(S, V)
\
+do {
\
+ *(int *) (((void *) &((S)->pr_reg)) + PR_REG_SIZE((S)->pr_reg)) = (V);
\
+} while (0)
+#else
+typedef compat_a32_elf_greg_t compat_elf_greg_t;
+typedef compat_a32_elf_gregset_t compat_elf_gregset_t;
+#endif
+
#define compat_elf_check_arch(x) compat_a32_elf_check_arch(x)
#endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 75f313a..efb9a54 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -830,8 +830,8 @@ static const struct user_regset aarch32_regsets[] = {
[REGSET_COMPAT_GPR] = {
.core_note_type = NT_PRSTATUS,
.n = COMPAT_A32_ELF_NGREG,
- .size = sizeof(compat_elf_greg_t),
- .align = sizeof(compat_elf_greg_t),
+ .size = sizeof(compat_a32_elf_greg_t),
+ .align = sizeof(compat_a32_elf_greg_t),
.get = compat_gpr_get,
.set = compat_gpr_set
},
@@ -864,7 +864,7 @@ static int compat_ptrace_read_user(struct task_struct *tsk,
compat_ulong_t off,
tmp = tsk->mm->start_data;
else if (off == COMPAT_PT_TEXT_END_ADDR)
tmp = tsk->mm->end_code;
- else if (off < sizeof(compat_elf_gregset_t))
+ else if (off < sizeof(compat_a32_elf_gregset_t))
return copy_regset_to_user(tsk, &user_aarch32_view,
REGSET_COMPAT_GPR, off,
sizeof(compat_ulong_t), ret);
@@ -885,7 +885,7 @@ static int compat_ptrace_write_user(struct task_struct
*tsk, compat_ulong_t off,
if (off & 3 || off >= COMPAT_USER_SZ)
return -EIO;
- if (off >= sizeof(compat_elf_gregset_t))
+ if (off >= sizeof(compat_a32_elf_gregset_t))
return 0;
set_fs(KERNEL_DS);
@@ -1048,7 +1048,7 @@ long compat_a32_arch_ptrace(struct task_struct *child,
compat_long_t request,
ret = copy_regset_to_user(child,
&user_aarch32_view,
REGSET_COMPAT_GPR,
- 0,
sizeof(compat_elf_gregset_t),
+ 0,
sizeof(compat_a32_elf_gregset_t),
datap);
break;
@@ -1056,7 +1056,7 @@ long compat_a32_arch_ptrace(struct task_struct *child,
compat_long_t request,
ret = copy_regset_from_user(child,
&user_aarch32_view,
REGSET_COMPAT_GPR,
- 0,
sizeof(compat_elf_gregset_t),
+ 0,
sizeof(compat_a32_elf_gregset_t),
[PATCH v4 17/24] arm64:ilp32: add vdso-ilp32 and use for signal return
Adjusted to move the move data page before code pages in sync with
commit 601255ae3c98fd3a8bb4696425e4f868b4f1
Signed-off-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
---
arch/arm64/include/asm/vdso.h | 4 ++
arch/arm64/kernel/Makefile| 5 ++
arch/arm64/kernel/signal.c| 4 ++
arch/arm64/kernel/vdso-ilp32/.gitignore | 2 +
arch/arm64/kernel/vdso-ilp32/Makefile | 72
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S | 33 +
arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S | 98 +++
arch/arm64/kernel/vdso.c | 63 ++---
8 files changed, 270 insertions(+), 11 deletions(-)
create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.S
create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
diff --git a/arch/arm64/include/asm/vdso.h b/arch/arm64/include/asm/vdso.h
index 839ce00..84050c6 100644
--- a/arch/arm64/include/asm/vdso.h
+++ b/arch/arm64/include/asm/vdso.h
@@ -29,6 +29,10 @@
#include
+#ifdef CONFIG_ARM64_ILP32
+#include
+#endif
+
#define VDSO_SYMBOL(base, name)
\
({\
(void *)(vdso_offset_##name - VDSO_LBASE + (unsigned long)(base)); \
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 61f8fbb..3cf8120 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -37,6 +37,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
obj-y += $(arm64-obj-y) vdso/
+obj-$(CONFIG_ARM64_ILP32) += vdso-ilp32/
obj-m += $(arm64-obj-m)
head-y := head.o
extra-y:= $(head-y) vmlinux.lds
@@ -44,3 +45,7 @@ extra-y := $(head-y)
vmlinux.lds
# vDSO - this must be built first to generate the symbol offsets
$(call objectify,$(arm64-obj-y)): $(obj)/vdso/vdso-offsets.h
$(obj)/vdso/vdso-offsets.h: $(obj)/vdso
+
+# vDSO - this must be built first to generate the symbol offsets
+$(call objectify,$(arm64-obj-y)): $(obj)/vdso-ilp32/vdso-ilp32-offsets.h
+$(obj)/vdso-ilp32/vdso-ilp32-offsets.h: $(obj)/vdso-ilp32
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index b91e6e1..99e36be 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -241,6 +241,10 @@ static void setup_return(struct pt_regs *regs, struct
k_sigaction *ka,
if (ka->sa.sa_flags & SA_RESTORER)
sigtramp = ka->sa.sa_restorer;
+#ifdef CONFIG_ARM64_ILP32
+ else if (is_ilp32_compat_task())
+ sigtramp = VDSO_SYMBOL(current->mm->context.vdso,
sigtramp_ilp32);
+#endif
else
sigtramp = VDSO_SYMBOL(current->mm->context.vdso, sigtramp);
diff --git a/arch/arm64/kernel/vdso-ilp32/.gitignore
b/arch/arm64/kernel/vdso-ilp32/.gitignore
new file mode 100644
index 000..61806c3
--- /dev/null
+++ b/arch/arm64/kernel/vdso-ilp32/.gitignore
@@ -0,0 +1,2 @@
+vdso-ilp32.lds
+vdso-ilp32-offsets.h
diff --git a/arch/arm64/kernel/vdso-ilp32/Makefile
b/arch/arm64/kernel/vdso-ilp32/Makefile
new file mode 100644
index 000..c8f5472
--- /dev/null
+++ b/arch/arm64/kernel/vdso-ilp32/Makefile
@@ -0,0 +1,72 @@
+#
+# Building a vDSO image for AArch64.
+#
+# Author: Will Deacon
+# Heavily based on the vDSO Makefiles for other archs.
+#
+
+obj-ilp32-vdso := gettimeofday-ilp32.o note-ilp32.o sigreturn-ilp32.o
+
+# Build rules
+targets := $(obj-ilp32-vdso) vdso-ilp32.so vdso-ilp32.so.dbg
+obj-ilp32-vdso := $(addprefix $(obj)/, $(obj-ilp32-vdso))
+
+ccflags-y := -shared -fno-common -fno-builtin
+ccflags-y += -nostdlib -Wl,-soname=linux-ilp32-vdso.so.1 \
+ $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
+
+obj-y += vdso-ilp32.o
+extra-y += vdso-ilp32.lds vdso-ilp32-offsets.h
+CPPFLAGS_vdso-ilp32.lds += -P -C -U$(ARCH) -mabi=ilp32
+
+# Force dependency (incbin is bad)
+$(obj)/vdso-ilp32.o : $(obj)/vdso-ilp32.so
+
+# Link rule for the .so file, .lds has to be first
+$(obj)/vdso-ilp32.so.dbg: $(src)/vdso-ilp32.lds $(obj-ilp32-vdso)
+ $(call if_changed,vdso-ilp32ld)
+
+# Strip rule for the .so file
+$(obj)/%.so: OBJCOPYFLAGS := -S
+$(obj)/%.so: $(obj)/%.so.dbg FORCE
+ $(call if_changed,objcopy)
+
+# Generate VDSO offsets using helper script
+gen-vdsosym := $(srctree)/$(src)/../vdso/gen_vdso_offsets.sh
+quiet_cmd_vdsosym = VDSOSYM $@
+define cmd_vdsosym
+ $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ && \
+ cp $@ include/generated/
+endef
+
+$(obj)/vdso-ilp32-offsets.h: $(obj)/vdso-ilp32.so.dbg FOR
[PATCH v4 06/24] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
From: Andrew Pinski Define __BITS_PER_LONG depending on the ABI used (i.e. check whether __ILP32__ or __LP64__ is defined). This is necessary for glibc to determine the appropriate type definitions for the system call interface. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- arch/arm64/include/uapi/asm/bitsperlong.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/include/uapi/asm/bitsperlong.h b/arch/arm64/include/uapi/asm/bitsperlong.h index fce9c29..4265243 100644 --- a/arch/arm64/include/uapi/asm/bitsperlong.h +++ b/arch/arm64/include/uapi/asm/bitsperlong.h @@ -16,7 +16,14 @@ #ifndef __ASM_BITSPERLONG_H #define __ASM_BITSPERLONG_H -#define __BITS_PER_LONG 64 +#if defined(__LP64__) +/* Assuming __LP64__ will be defined for native ELF64's and not for ILP32. */ +# define __BITS_PER_LONG 64 +#elif defined(__ILP32__) +# define __BITS_PER_LONG 32 +#else +# error "Neither LP64 nor ILP32: unsupported ABI in asm/bitsperlong.h" +#endif #include -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 01/24] arm64:ilp32: add documentation on the ILP32 ABI for ARM64
Based on Andrew Pinski's original patch-series and adapted with changes to reduce the duplication of code-paths and resolve issue found during LTP testing. Signed-off-by: Philipp Tomsich Signed-off-by: Christoph Muellner --- Documentation/arm64/ilp32.txt | 64 +++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/arm64/ilp32.txt diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt new file mode 100644 index 000..7524d06 --- /dev/null +++ b/Documentation/arm64/ilp32.txt @@ -0,0 +1,64 @@ +ILP32 AARCH64 SYSCALL ABI += +Written by Andrew Pinski +Updated by Philipp Tomsich + + +This document describes the ILP32 syscall ABI and where it differs +from the generic linux syscall interface. + +ILP32 sets __kernel_long_t and __kernel_ulong_t both to 64bit. This +affects the following type definitions for ILP32 client programs: + * time_t unsigned long long + * clock_t unsigned long long + * fsword_tlong long + * suseconds_t long long + * swblk_t long long + * fd_mask_t long long + +Some structures are changed to reduce the difference in the code path +for both ILP32 and LP64 ABIs for signal handling. + +The following structures have been changed so the layout of the +structures are the same between ILP32 and LP64 ABIs, including: + * timespecuses time_t and suseconds_t + * timeval uses time_t and suseconds_t + * statuses timespec/time_t + * semid64_ds uses time_t. + * msqid64_ds uses time_t. + * shmid64_ds uses time_t. + * rt_sigframe uses siginfo and ucontext. + * siginfo_t uses clock_t and sigval_t + * ucontextuses stack_t and sigset_t + * sigval_tcontains pointers + * sigeventUses sigval_t which causes it to be the same. Special + handing is needed for reading; in the mq_notify syscall + * sigaction Conversion is handled in the userland (glibc), as the + userland data structures are defined in glibc anyway. + * fd_set This is done to avoid endian issues between ILP32 and + LP64. Syscalls consuming fd_set use timespec. + +A number of structures differ between ILP32 and LP64, including: + * struct msgbuf The specification of 'struct msgbuf' defines the 'mtype' + field as a 'long' (i.e. 32bit for ILP32, but 64bit for + LP64). Functions that operate on 'struct msgbuf' need + to be passed through the compat-syscalls to resolve + this. + * stack_t contains pointers (handled in the compatibility layer) + +Also the syscalls which normally would pass 64bit values as two arguments; +now pass the 64bit value as one argument. Also they have been renamed +(removing the 64 from the name) to avoid confusion. +The list of these LP64 syscalls reused by ILP32 clients is: + * fcntl + * statfs + * fstatfs + * truncate + * ftruncate + * lseek + * sendfile + * newfstatat + * fstat + * mmap + * fadvise64 + -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] dt-bindings: mmc: Add a new property disable-cqe-dcmd.
> On 01.03.2019, at 17:43, Christoph Muellner
> wrote:
>
> This patch documents the new proprty disable-cqe-dcmd
typo: proprty -> property
> for the Arasan eMMC 5.1 driver.
>
> Signed-off-by: Christoph Muellner
> Signed-off-by: Philipp Tomsich
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 1edbb049cccb..ec699bf98b7c 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -44,6 +44,10 @@ Optional Properties:
> properly. Test mode can be used to force the controller to function.
> - xlnx,int-clock-stable-broken: when present, the controller always reports
> that the internal clock is stable even when it is not.
> + - disable-cqe-dcmd: The eMMC 5.1 standard specifies direct commands (DCMDs)
> +as part of the command queue engine (CQE). On controllers with a CQHCI,
> +such as the Arasan eMMC 5.1 host controller, the driver has to enable
> DCMDs.
> +This is done unless disable-cqe-dcmd is specified.
>
> Example:
> sdhci@e010 {
> --
> 2.11.0
>
Re: [PATCH 1/3] phy: rockchip-emmc: Allow to set drive impedance via DTS.
Doug,
> On 01.03.2019, at 17:48, Doug Anderson wrote:
>
> Hi,
>
> On Fri, Mar 1, 2019 at 7:37 AM Christoph Muellner
> wrote:
>>
>> The rockchip-emmc PHY can be configured with different
>> drive impedance values. Currenlty a value of 50 Ohm is
>> hard coded into the driver.
>>
>> This patch introduces the DTS property 'drive-impedance-ohm'
>> for the rockchip-emmc phy node, which uses the value from the DTS
>> to setup the drive impedance accordingly.
>>
>> Signed-off-by: Christoph Muellner
>> Signed-off-by: Philipp Tomsich
>> ---
>> drivers/phy/rockchip/phy-rockchip-emmc.c | 38
>> ++--
>> 1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
>> b/drivers/phy/rockchip/phy-rockchip-emmc.c
>> index 19bf84f0bc67..5413fa73dd45 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
>> @@ -87,6 +87,7 @@ struct rockchip_emmc_phy {
>>unsigned intreg_offset;
>>struct regmap *reg_base;
>>struct clk *emmcclk;
>> + unsigned int drive_impedance;
>> };
>>
>> static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>> @@ -281,10 +282,10 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
>> {
>>struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
>>
>> - /* Drive impedance: 50 Ohm */
>> + /* Drive impedance: from DTS */
>>regmap_write(rk_phy->reg_base,
>> rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>> -HIWORD_UPDATE(PHYCTRL_DR_50OHM,
>> +HIWORD_UPDATE(rk_phy->drive_impedance,
>> PHYCTRL_DR_MASK,
>> PHYCTRL_DR_SHIFT));
>>
>> @@ -314,6 +315,28 @@ static const struct phy_ops ops = {
>>.owner = THIS_MODULE,
>> };
>>
>> +static u32 convert_drive_impedance_ohm(struct platform_device *pdev, u32
>> dr_ohm)
>> +{
>> + switch (dr_ohm) {
>> + case 100:
>> + return PHYCTRL_DR_100OHM;
>> + case 66:
>> + return PHYCTRL_DR_66OHM;
>> + case 50:
>> + return PHYCTRL_DR_50OHM;
>> + case 40:
>> + return PHYCTRL_DR_40OHM;
>> + case 33:
>> + return PHYCTRL_DR_33OHM;
>> + }
>> +
>> + dev_warn(&pdev->dev,
>> + "Invalid value %u for drive-impedance-ohm. "
>> + "Falling back to 50 Ohm.\n",
>> + dr_ohm);
>> + return PHYCTRL_DR_50OHM;
>> +}
>> +
>> static int rockchip_emmc_phy_probe(struct platform_device *pdev)
>> {
>>struct device *dev = &pdev->dev;
>> @@ -322,6 +345,7 @@ static int rockchip_emmc_phy_probe(struct
>> platform_device *pdev)
>>struct phy_provider *phy_provider;
>>struct regmap *grf;
>>unsigned int reg_offset;
>> + u32 val;
>>
>>if (!dev->parent || !dev->parent->of_node)
>>return -ENODEV;
>> @@ -345,6 +369,16 @@ static int rockchip_emmc_phy_probe(struct
>> platform_device *pdev)
>>rk_phy->reg_offset = reg_offset;
>>rk_phy->reg_base = grf;
>>
>> + if (of_property_read_u32(dev->of_node, "drive-impedance-ohm", &val))
>> {
>> + dev_info(dev,
>> + "Missing drive-impedance-ohm property in node %s "
>> + "Falling back to 50 Ohm.\n",
>> + dev->of_node->name);
>
> This is awfully noisy for something that pretty much all existing
> boards will run. debug level instead of info level? Also:
>
> * Don't split strings
> across lines
>
> * There's a magic % thing to get the name of an OF node. Use that.
>
>
>> + rk_phy->drive_impedance = PHYCTRL_DR_50OHM;
>> + } else {
>> + rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev,
>> val);
>> + }
>
> It's been a long time since I looked at this, but I could have sworn
> that it was more complicated than that. Specifically I though you
> were supposed to query the eMMC card for what it supported and then
> resolve that with what the host could support.
>
> Assuming
Re: [PATCH 1/3] phy: rockchip-emmc: Allow to set drive impedance via DTS.
> On 01.03.2019, at 19:09, Christoph Müllner
> wrote:
>
> Hi Doug,
>
>> On 01.03.2019, at 17:48, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Fri, Mar 1, 2019 at 7:37 AM Christoph Muellner
>> wrote:
>>>
>>> The rockchip-emmc PHY can be configured with different
>>> drive impedance values. Currenlty a value of 50 Ohm is
>>> hard coded into the driver.
>>>
>>> This patch introduces the DTS property 'drive-impedance-ohm'
>>> for the rockchip-emmc phy node, which uses the value from the DTS
>>> to setup the drive impedance accordingly.
>>>
>>> Signed-off-by: Christoph Muellner
>>> Signed-off-by: Philipp Tomsich
>>> ---
>>> drivers/phy/rockchip/phy-rockchip-emmc.c | 38
>>> ++--
>>> 1 file changed, 36 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
>>> b/drivers/phy/rockchip/phy-rockchip-emmc.c
>>> index 19bf84f0bc67..5413fa73dd45 100644
>>> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
>>> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
>>> @@ -87,6 +87,7 @@ struct rockchip_emmc_phy {
>>> unsigned intreg_offset;
>>> struct regmap *reg_base;
>>> struct clk *emmcclk;
>>> + unsigned int drive_impedance;
>>> };
>>>
>>> static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
>>> @@ -281,10 +282,10 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
>>> {
>>> struct rockchip_emmc_phy *rk_phy = phy_get_drvdata(phy);
>>>
>>> - /* Drive impedance: 50 Ohm */
>>> + /* Drive impedance: from DTS */
>>> regmap_write(rk_phy->reg_base,
>>>rk_phy->reg_offset + GRF_EMMCPHY_CON6,
>>> -HIWORD_UPDATE(PHYCTRL_DR_50OHM,
>>> +HIWORD_UPDATE(rk_phy->drive_impedance,
>>> PHYCTRL_DR_MASK,
>>> PHYCTRL_DR_SHIFT));
>>>
>>> @@ -314,6 +315,28 @@ static const struct phy_ops ops = {
>>> .owner = THIS_MODULE,
>>> };
>>>
>>> +static u32 convert_drive_impedance_ohm(struct platform_device *pdev, u32
>>> dr_ohm)
>>> +{
>>> + switch (dr_ohm) {
>>> + case 100:
>>> + return PHYCTRL_DR_100OHM;
>>> + case 66:
>>> + return PHYCTRL_DR_66OHM;
>>> + case 50:
>>> + return PHYCTRL_DR_50OHM;
>>> + case 40:
>>> + return PHYCTRL_DR_40OHM;
>>> + case 33:
>>> + return PHYCTRL_DR_33OHM;
>>> + }
>>> +
>>> + dev_warn(&pdev->dev,
>>> + "Invalid value %u for drive-impedance-ohm. "
>>> + "Falling back to 50 Ohm.\n",
>>> + dr_ohm);
>>> + return PHYCTRL_DR_50OHM;
>>> +}
>>> +
>>> static int rockchip_emmc_phy_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = &pdev->dev;
>>> @@ -322,6 +345,7 @@ static int rockchip_emmc_phy_probe(struct
>>> platform_device *pdev)
>>> struct phy_provider *phy_provider;
>>> struct regmap *grf;
>>> unsigned int reg_offset;
>>> + u32 val;
>>>
>>> if (!dev->parent || !dev->parent->of_node)
>>> return -ENODEV;
>>> @@ -345,6 +369,16 @@ static int rockchip_emmc_phy_probe(struct
>>> platform_device *pdev)
>>> rk_phy->reg_offset = reg_offset;
>>> rk_phy->reg_base = grf;
>>>
>>> + if (of_property_read_u32(dev->of_node, "drive-impedance-ohm",
>>> &val)) {
>>> + dev_info(dev,
>>> + "Missing drive-impedance-ohm property in node %s "
>>> + "Falling back to 50 Ohm.\n",
>>> + dev->of_node->name);
>>
>> This is awfully noisy for something that pretty much all existing
>> boards will run. debug level instead of info level? Also:
>
> Removed for v2 as suggested by Robin.
>
>>
>> * Don't split strings
>> across lines
>>
>> * There's a magic % thing to get the name of an OF node. Use that
[PATCH] clk: sunxi-ng: Fix div/mult settings for osc12M on A64
The mult/div for osc12M was previously backwards (giving a 48M rate for osc12M). Fix it. X-AffectedPlatforms: A64-uQ7 Signed-off-by: Philipp Tomsich Tested-by: Christoph Muellner Cc: Maxime Ripard --- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index e3c084c..f54114c 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -566,7 +566,7 @@ static SUNXI_CCU_M_WITH_GATE(gpu_clk, "gpu", "pll-gpu", 0x1a0, 0, 3, BIT(31), CLK_SET_RATE_PARENT); /* Fixed Factor clocks */ -static CLK_FIXED_FACTOR(osc12M_clk, "osc12M", "osc24M", 1, 2, 0); +static CLK_FIXED_FACTOR(osc12M_clk, "osc12M", "osc24M", 2, 1, 0); /* We hardcode the divider to 4 for now */ static CLK_FIXED_FACTOR(pll_audio_clk, "pll-audio", -- 1.9.1
Re: [PATCH 15/24] ARM64:ILP32: Use the non compat HWCAP for ILP32.
On 24 May 2014, at 09:02 , Andrew Pinski wrote:
> #ifdef CONFIG_COMPAT
> -#define COMPAT_ELF_HWCAP (compat_elf_hwcap)
> -#define COMPAT_ELF_HWCAP2(compat_elf_hwcap2)
> extern unsigned int compat_elf_hwcap, compat_elf_hwcap2;
> +#define COMPAT_ELF_HWCAP \
> + (is_a32_compat_task() \
> + ? compat_elf_hwcap\
> + : elf_hwcap)
> +
> +#define COMPAT_ELF_HWCAP2\
> + (is_a32_compat_task() \
> + ? compat_elf_hwcap2 \
> + : 0)
> +
> #endif
You missed the COMPAT_ELF_PLATFORM (in arm64/include/asm/elf.h), which is used
to setup AT_PLATFORM in the auxilary vectors. I’d suggest to use a similar
naming convention to what will be used in gdb (i.e. appending a “:ilp32” to the
base architecture.
The proposed change would thus be:
---
arch/arm64/include/asm/elf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 3f979b5..6d38edc 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -168,9 +168,9 @@ extern unsigned long arch_randomize_brk(struct mm_struct
*mm);
#ifdef CONFIG_COMPAT
#ifdef __AARCH64EB__
-#define COMPAT_ELF_PLATFORM("v8b")
+#define COMPAT_ELF_PLATFORM(is_ilp32_compat_task() ?
"aarch64_be:ilp32" : "v8b")
#else
-#define COMPAT_ELF_PLATFORM("v8l")
+#define COMPAT_ELF_PLATFORM(is_ilp32_compat_task() ?
"aarch64:ilp32" : "v8l")
#endif
#define COMPAT_ELF_ET_DYN_BASE (randomize_et_dyn(2 * TASK_SIZE_32 / 3))
--
1.9.0
Best,
Philipp.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 14 Apr 2015, at 13:14, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 10:45:43 Pinski, Andrew wrote: >>> On Apr 14, 2015, at 3:08 AM, Arnd Bergmann wrote: >>> >>>> On Tuesday 14 April 2015 11:33:13 Dr. Philipp Tomsich wrote: >>>> Arnd, >>>> >>>> After getting a good night’s sleep, the “reuse the existing system call >>>> table” comment >>>> makes a little more sense as I construe it as having just one merged >>>> system call table >>>> for both LP64 and ILP32 and handling the differences through a different >>>> system call >>>> numbering in unistd.h towards LP64 and ILP32 processes. >>>> >>>> If this is the intended implementation, I am not fully sold on the >>>> benefit: having a private >>>> copy of unistd.h for ARM64 seems to be a less readable and less >>>> maintenance-friendly >>>> solution to having separate tables. >>>> >>>> We’re open to input on this and—if merging the system call tables is the >>>> consensus— >>>> would like to get the change underway as soon as possible. >>> >>> There are multiple ways of doing this: >>> >>> a) separate syscall table for arm64: as you say, this is the current >>> approach, >>> and I'd like to avoid that too >>> b) add syscalls for ilp32 as additional numbers in the normal lp64 version >>> of >>> asm-generic/unistd.h, and share the binary tables between ilp32 and lp64 >>> on aarch64 >>> c) change asm-generic/unistd.h to generate three possible tables: instead of >>> just native (lp64 or ilp32 depending on the arch), compat (support for >>> existing ilp32 binaries on some architectures, there would also be a >>> "modern" ilp32 variant that is a mix of the two, as your table today >>> d) don't use the asm-generic/unistd.h table for aarch64-ilp32 at all, but >>> instead >>> reuse the table from arch/arm64/include/asm/unistd32.h >>> >>> I think you are referring to approach b) or c) above, but my preferred one >>> would actually be d). >> >> D is the worst of all 4 options in my mind. The reason is when a new syscall >> is >> added, then you have to update that file too. > > I don't know what the miscommunication is here, but the advantage of d is > specifically that it is /less/ work to maintain: With the current approach, > each new syscall that gets added needs to be checked to see if the normal > aarch64 version works or if it needs another wrapper, while with d) we > get the update for free, because we follow exactly what aarch32 is doing. I must agree with Andrew, that (d) seems like a bad fit for ILP32… after all the ILP32 (ELF) ABI specifies that 64bit values are to be passed in a single register, but the unistd32.h assumes a 32bit kernel that receives 64bit arguments split over two registers (i.e. the 64-variants of the various system calls, such as ftruncate64). I strongly prefer (b) as this satisfies the largest number of requirements: (i) it will be a single system call table for LP64 and ILP32 (ii) it’s easy to be make use of the 64bit capable system calls (iii) it fits with the relationship of ILP32 to LP64 in the ILP32 ELF ABI definition As we don’t support ILP32 without LP64, the resulting implementation will be even simpler (i.e. no need to duplicate the entire table) than the n32 implementation on MIPS... >> Also d is worse than the rest as >> you no longer default to 64bit off_t which is not a good thing. > > That decision is up to the libc implementation, just as it is for the existing > aarch32 libc. The kernel just offers both versions and the libc can pick > one, or use the _LARGEFILE64_SOURCE hack that glibc has to also implement > both. It would probably be reasonable to use 64-bit off_t only for a libc > and ignore the old calls. The glibc implementation, as we have it today, always uses the 64bit system call and performs overflow-checking on results (on ILP32, we can’t perform overflow checking on arguments, as the callee needs to sign-extend). In other words: glibc uses the LP64 system calls and handles any pre- and post-processing in the system-call wrappers. >> B is just as bad and goes against using the generic syscall numbers. > > How so? The newly introduce syscalls then would be the generic ones. By applying the “strace-test” (i.e. “How will this affect the implementation of strace, when considering a ILP32-compiled and a LP64-compiled strace where both should be capable of tracing either ILP32 or LP64 targets?”), option (b)
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 14 Apr 2015, at 16:47, Catalin Marinas wrote:
>
>> I mainly want to avoid accidentally creating new ABIs for syscalls and
>> ioctls:
>> we have many drivers that today use ioctls with data structures derived from
>> '__kernel_ulong_t' in some form, often by including a timespec or time_t in
>> their own data structures. These are almost all broken today, because the
>> data structures are a mix of the aarch32 and aarch64 variants, while the
>> ioctl() system call in ilp32 always uses the aarch32 format by default.
>>
>> An example here would be
>>
>> struct cyclades_idle_stats {
>>__kernel_time_t in_use; /* Time device has been in use (secs) */
>>__kernel_time_t recv_idle; /* Time since last char received (secs) */
>>__kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */
>>unsigned long recv_bytes; /* Bytes received */
>>unsigned long xmit_bytes; /* Bytes transmitted */
>>unsigned long overruns;/* Input overruns */
>>unsigned long frame_errs; /* Input framing errors */
>>unsigned long parity_errs; /* Input parity errors */
>> };
>>
>> for a random ancient driver. Introducing a third set of data structures
>> and syscalls for aarch64-ilp32 means that any driver doing something like
>> this needs to be modified to support existing user space source code.
>
> That's indeed a problem as ILP32 doesn't look like any of the other
> options (the siginfo structure is another case that doesn't fit in any
> of the ABI as long as time_t is 64-bit).
I believe we’ve already arrived at the conclusion that timespec needs to be
changed from what Andrew and I had submitted.
Let’s go back to the underlying definition of timespec:
"The range and precision of times representable in clock_t and time_t
are
implementation-defined. The timespec structure shall contain at least
the
following members, in any order.
time_t tv_sec; // whole seconds -- >= 0
long tv_nsec; // nanoseconds -- [0, 9]”
So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C
language. Any program that assumes that tv_nsec is sizeof(long) would be
correct and it would be unexpected and surprising behaviour [even though it
would be consider a good programming style] if one would need to explicitly
ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem
like a good justification to do the same.
For time_t, I don’t see the need to have a 32bit type yet.
As long as the the type is properly exposed through header files (and user
programs can thus recreate the kernel’s data model), we should be safe.
Cases like the above data structure from an ioctl are clearly non-portable
and would break today on any architecture that supports ABIs with different
data models (say ILP32 and LP64)… so I would consider any attempt to
support this as trying to remain “bug-compatible”.
There are plenty of good examples in the uapi that will be nicely portable
between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this,
as the userspace library libaio uses a broken redefinition instead of the
kernel header file) as an example:
> /*
> * we always use a 64bit off_t when communicating
> * with userland. its up to libraries to do the
> * proper padding and aio_error abstraction
> */
>
> struct iocb {
> /* these are internal to the kernel/libc. */
> __u64 aio_data; /* data to be returned in event's data */
> __u32 PADDED(aio_key, aio_reserved1);
> /* the kernel sets aio_key to the req # */
>
> /* common fields */
> __u16 aio_lio_opcode; /* see IOCB_CMD_ above */
> __s16 aio_reqprio;
> __u32 aio_fildes;
>
> __u64 aio_buf;
> __u64 aio_nbytes;
> __s64 aio_offset;
>
> /* extra parameters */
> __u64 aio_reserved2; /* TODO: use this for a (struct sigevent *) */
>
> /* flags for the "struct iocb" */
> __u32 aio_flags;
>
> /*
> * if the IOCB_FLAG_RESFD flag of "aio_flags" is set, this is an
> * eventfd to signal AIO readiness to
> */
> __u32 aio_resfd;
> }; /* 64 bytes */
The key to any design decision should be that we
(a) don’t break C11, POSIX or the Single UNIX Specification
(b) remain true to the definitions from the the AArch64 ILP32 ELF ABI
(which defines 64bit values transferable in registers to callees)
Can we thus agree on the following for the next revision of the patch-set:
(1) We retain a 64bit time_t, but implement different sizes (between ILP32 and
LP64) for ‘tv_nsec' in 'struct timespec’?
(2) We use the 64bit system calls whereever possible (i.e. no register
splitting).
Best,
Phil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 15 Apr 2015, at 00:28, Arnd Bergmann wrote: > > On Tuesday 14 April 2015 16:00:34 Catalin Marinas wrote: >> On Tue, Apr 14, 2015 at 04:07:36PM +0200, Arnd Bergmann wrote: >>> For completeness, there is yet another option, which would be to use the >>> exact system call table from arm64 and do all the emulation in user space >>> rather than the kernel. This would however be the least compatible with >>> existing source code, so you probably don't want to do that. >> >> It would be great if this worked but I think we looked at it before and >> it seems nice until you hit the futex stuff and robust lists (I don't >> fully remember the details). Some of the structures (siginfo) would no >> longer be POSIX compliant and some of them aren't only accessed via libc >> to be able to create shadow copies. > > Well, that may or may not be acceptable. Aarch64-ilp32 mode is a hack to > enable a very special class of applications, it's not like anyone would > want to run a full system for this and need POSIX compliance. I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 ecosystem as a “data-model” for AArch64. Having a corresponding Linux syscall ABI is necessitated because not all data structures shared across the syscall-boundary are describted/defined in data-model agnostic types. ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus neither a hack nor likely/expected to go away anytime soon. We’ve run full systems (built from buildroot) consisting of ILP32 binaries only (ok… admittedly gdb was an exception, as we haven’t fixed the fact that someone has assumed sizeof(long) == 8 in some data-structure of the AArch64 backend there) in our verification runs. In fact, it will be very special classes of applications that will need a 64bit address-space. If anything, then backward-compatibility for ARMv7 binaries should be considered a hack (although one that is performed in hardware). > We could definitely be pragmatic and do whatever helps get the job > done. That said, it diverges further from what legacy 32-bit applications > expect to see, so this approach will likely make an application port harder, > not easier. The key question at this point seems to be whether we want to support “legacy 32-bit applications” (i.e. ones that make assumption that are not covered by the underlying type definitions or specifications) or whether we aim for “well-formed 32-bit applications”. To stay with the 'struct timespec’-example, the difference between the former and the latter would (among others) be that the former might assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to except that sizeof(long) == sizeof(ts.tv_nsec). I don’t believe in keeping compatibility for the former type of applications. Consequently, I don’t necessarily see the value in defining ILP32 for AArch64 with a 32bit time_t (even though it would be simpler at this moment), as I don’t see the benefit of adding a new ABI that propagates a well known problem (even if one could argue that there’s plenty of time to fix this by 2038). Phil.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Catalin, even though this may now be moot, as we’ll out a 32bit time_t on ILP32 (making it very similar to n32 on MIPS), here’s the the info on what would be affected by changing timespec. Below is a (hopefully) full list of system calls, helper functions and exposed data structures (with some comments on what will need to be done to resolve this change) that would be affected by introducing an other timespec (let’s call it ilp32_timespec for the ease of discussion) consisting of a 64bit time_t and a 32bit integer. > On 14 Apr 2015, at 18:55, Catalin Marinas wrote: > > As I mentioned above, timespec and possibly other structures no longer > like any of the existing ABIs. Do we know how many syscalls are > affected? Here’s everything that affected (details on how to resolve are below) in no particular order: > syscall: utimensat > syscall: io_getevents > syscall: select > internal: poll_select_copy_remaining (via select) [+on stack: struct > compat_timespec rts;] > syscall: pselect6 > internal: do_compat_pselect (via pselect6) [+on stack: struct compat_timespec > ts;] > syscall: ppoll [+on stack: struct compat_timespec ts;] > syscall: nanosleep > internal: compat_nanosleep_restart (via nanosleep) > syscall: clock_gettime > syscall: clock_settime > syscall: clock_getres > syscall: clock_nanosleep > syscall: rt_sigtimedwait > syscall: sched_rr_get_interval > internal: compat_get_timespec > internal: compat_put_timespec > syscall: futex > syscall: recvmmsg > file_operations: compat_sock_ioctl > internal: do_siocgstampns (via compat_sock_ioctl_trans via compat_sock_ioctl) > syscall: semtimedop > syscall: mq_timedsend > syscall: mq_timedreceive > internal: compat_convert_timespec > syscall: timer_settime > syscall: timer_gettime > syscall: timerfd_settime > syscall: timerfd_gettime > struct: itimerspec > internal: get_compat_itimerspec > internal: put_compat_itimerspec > struct: snd_pcm_status32 > internal: snd_pcm_ioctl_sync_ptr_compat > struct: snd_pcm_mmap_status32 > internal: snd_pcm_status_user_compat > struct: v4l2_event32 > internal: put_v4l2_event32 (via do_video_ioctl) > struct: restart_block [simple change: additional field; for nanosleep] > internal: put_cmsg_compat [on stack: struct compat_timespec cts[3];] > struct: snd_rawmidi_status32 > internal: snd_rawmidi_ioctl_status_compat (handles snd_rawmidi_status32) > struct: snd_timer_status32 > internal: snd_timer_user_status_compat > struct: struct snd_pcm_mmap_status32 > internal: snd_pcm_ioctl_sync_ptr_compat (handles snd_pcm_mmap_status32) > struct: snd_pcm_status32 > internal: snd_pcm_status_user_compat (handles snd_pcm_status32) For dealing with them, we can roughly use the following strategy (I may have lost 1. The timespec/compat_timespec/ilp32_timespec is ever only referenced through its memory address and used for userspace/kernel-transfers. For these cases we mere need to extend the compat_get_timespec and compat_put_timespec functions to recognize the ILP32-case… same for compat_convert_timespec For the affected syscalls, the ILP32 implementation should route through the compat-layer. This can be done in the following cases (I’m leaving the compat off for readability): utimensat io_getevents nanosleep clock_gettime clock_settime clock_getres clock_nanosleep rt_sigtimedwait sched_rr_get_interval recvmmsg futex semtimedop mq_timedsend mq_timedreceive One helper called through an ioctl will also need to pick this us: do_siocgstampns (through compat_sock_ioctl) A special case is the nanosleep syscall and its restart-helper: even though less apparent, this would be covered by the changes to compat_get_timespec and compat_put_timespec also (as there’s only a pointer to a compat_timespec involved). 2. An similar change will be required for anything that uses itimerspec (as that structure contains two timespec elements): timer_settime timer_gettime timerfd_settime timerfd_gettime 3. A compat_timespec is currently created on the stack, even though it’s used only for a get_user/put_user in a few cases; this can be resolved by changing to use compat_get_timespec/compat_put_timespec. Once this has been done, then the changes from step 1 should also extend to these case. Instances include: poll_select_copy_remaining (helper function called from ‘select’) do_compat_pselect (helper function called from ‘pselect6’) ppoll The syscalls associated with these helper-functions need to be passed through the compat-layer f
Re: [PATCH v4 00/24] ILP32 for ARM64
> On 15 Apr 2015, at 17:38, Catalin Marinas wrote: > > On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: >> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: >>> On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: >>>> We’ve run full systems (built from buildroot) consisting of ILP32 binaries >>>> only (ok… admittedly gdb was an exception, as we haven’t fixed the fact >>>> that someone has assumed sizeof(long) == 8 in some data-structure of >>>> the AArch64 backend there) in our verification runs. In fact, it will be >>>> very >>>> special classes of applications that will need a 64bit address-space. >>> >>> If we are to merge AArch64-ILP32, I'd like to see a full software stack, >>> maybe a distro like Debian. Otherwise the kernel code will bit-rot (just >>> like it regularly happens with big endian). >> >> I actually don't think this should be a prerequisite. We have too many >> dependencies here, and as long as we are debating the exact ABI, >> any work that gets put into a full distro support (other than openembedded >> etc) would likely be wasted. > > I agree with this not being a prerequisite for merging ILP32 but at > least a long term plan to do something beyond openembedded, once we > agreed on the ABI and _upstreamed_ the kernel and glibc code. Those > legacy applications will probably need more than glibc to run and it's > likely that people will want to run them in a full AArch64 (LP64) > environment. A simpler approach (to me, I'm not a distro person) would > be to just provide additional ILP32 libs in a multi-lib arm64 distro > like Debian rather than all the packages. As for the compiler, AFAIK > aarch64-linux-gnu-* simply needs an option to build for ILP32. We’ve had a PPA for Ubuntu 14.04 in the past that included glibc, ncurses, termcap, zlib and a few others in a multiarch setup… this was used in the field by customers and worked rather well. One of the engineers in my team is currently working on carrying this forward so we can use this for any Debian-based AArch64 distribution in the future. Best, Phil. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Just for the record (and to avoid anyone wasting their time on what’s available today): we are migrating this over to option (a) now, even though we would prefer to see option (b) implemented. If we get a consensus on (b) in the next couple of days, we’ll redo things for option (b). If not, we will have an implementation for option (a) available that we can hopefully all agree on merging. Best, Phil. > On 16 Apr 2015, at 13:03, Catalin Marinas wrote: > > On Thu, Apr 16, 2015 at 12:25:36AM +0200, Alexander Graf wrote: >> We've just started to bootstrap openSUSE for ILP32 with the non-final >> abi. However, keep in mind that at least for us bootstrapping is a >> manual process. So changing syscall numbers means we'll need to go >> through the manual process again. >> >> So if you need any help on getting you an environment that allows you to >> build LTP with whatever syscall abi people come up with, feel free to >> poke Andreas or me. > > Thanks for the offer. It's great to see a full distro being built (even > though no commitment). > > But I'm a bit worried that people started using these patches and we > haven't agreed on the ABI yet (well, for a while we thought that the x32 > approach was fine until I've seen objections from others). > > Maybe a quick poll on the options, ignoring syscall number details (we > go for the generic ones) or syscall tables sharing: > > a) AArch32-like ILP32 ABI, 32-bit time_t, 32-bit __kernel_long_t > (POSIX-compliant) > b) Future-proof ILP32 ABI, 64-bit time_t, 32-bit __kernel_long_t (as > seen by the user) (POSIX-compliant) > c) LP64-like ILP32 ABI, 64-bit time_t, 64-bit __kernel_long_t > (non-POSIX-compliant) > > Option (a) is the easiest from the kernel perspective and has the > highest chance of not breaking legacy AArch32 applications. > > Option (b) is more future looking (beyond 2038) but it introduces a > third ABI in the kernel (incompatible with both compat and native). > There is also a risk that legacy applications assume a 32-bit time_t. > > Option (c) is pretty much what we currently have in these patches. While > many syscalls are native LP64, it doesn't fully solve pointers in > structures shared between user and kernel (ioctl being one of the > affected areas) > > I can't tell how bad the impact of non-POSIX compliance is. If this is > essential, between (a) and (b) I'm more in favour of (a) as the easiest > for both kernel and user. If we were to start a new ABI from scratch > without legacy applications, I would have definitely gone for (b) but > I'm worried about legacy applications still not fully working with this > option while adding more maintenance burden in the kernel. > > -- > Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Arnd, Where can I pull this prototype implementation from? As we are working on getting a final ILP32 change-set ready, I’d like to make sure that we base this on the latest consensus for new ILP32 ABIs on 64bit machines. Thanks, Philipp. > On 04 May 2015, at 12:29, Arnd Bergmann wrote: > > On Saturday 18 April 2015 21:24:19 Arnd Bergmann wrote: >> Given Catalin's comments from yesterday, I think we can just fix the >> definitions of 'struct stat64' for asm-generic to make it have the same >> layout as the 64-bit version of 'struct stat', and use that for >> aarch64-ilp32. >> >> Similarly for the four sysvipc headers, we can have a modified version of >> the asm-generic ones in arch/arm64/uapi/asm, which will use the same layout >> for ilp32 and lp64 without having to set __kernel_ulong_t to 64-bit. > > To pick up that earlier thread, I now have a prototype implementation for > converting all 32-bit architectures to use 64-bit time_t. > > For 'struct stat', I ended up introducing a new structure on arm32 that > matches the layout of arm64 (and I did the same for all other 32-bit > architectures that have a 64-bit counterpart). This means we can share > the same system calls between arm64-lp64, arm64-ilp32 and arm32 with > 64-bit time_t and arm64-aarch32 emulation for 32-bit time_t, while > using the existing compat handling for the original 'struct stat' > emulation in both arm32 and arm64-aarch32. > > However, for ipc, the situation is different: I found a way to use > extra padding fields in semid64_ds/shmid64_ds/msqid64_ds, so the > ipc system calls will still use normal 32-bit data structures > on arm32 and arm64-aarch64, but you cannot use them arm64-ilp32, > and will have to #ifdef the three header files there to choose between > the two implementations. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/24] ILP32 for ARM64
Arnd, > 1. Adding a whole new ABI to the kernel is adding a long-term maintenance > burden, and we don't want to do that just because someone thinks it's a cute > hack or because it might add a few percent in performance of some low-level > benchmark. Please describe in the cover-letter for the patch series > specifically what applications you have in mind that would be using this, and > what the expected timeframe is before users could move to 64-bit user space. There’s a couple of drivers behind getting ILP32 merged on ARM64: (a) There’s plenty of applications (i.e. having a large code-base, but not requiring a 64bit address space) that can’t readily be migrated to LP64 (typically networking or data-storage applications) because they were written assuming an ILP32 data model. Many of these applications will never become suitable for a LP64 data model and will remain locked into ILP32 operating environments. (b) A number of SPEC2006 components (i.e. not low-level benchmarks, but test cases that have been derived from large application use cases) benefit from having a denser data-representation—this includes the mcf, xalancbmk, astar and ometpp. This not an observation specific to ARM64 and can be observed on other architectures as well (e.g. [1] contains data for POWER from 2010). (c) Using AArch32 (assuming that any given ARMv8 processor supports it), is not a real alternative, as 64bit arithmetic is not supported on AArch32 and the AArch32 register set is significantly smaller. Our experience shows that the benefit of having 64bit registers, of a larger register file and of using 64bit arithmetic makes ILP32 a worthwhile improvement over AArch32. In summary, we believe that the need for ILP32 will never disappear on ARM64. In fact, I rather expect the AArch32 compatibility to eventually disapper from further processor designs… which will turn ILP32 into the only option for legacy software. > 2. The ABI follows what x86 has their "x32" ABI. This never saw a lot of > adoption and in retrospect the decision to have separate system calls seems > to not have helped them. My feeling now is that if we add support for the > ARM64 ILP32 ELF ABI, we should better stick to the existing system call ABI > as close as possible and reuse the existing system call table. I realize > that this is a bit controversial, but please let's talk about this now. I see benefits and drawback to merging the system tables. Our philosophy is already somewhat different from x32 and from the original patch-series, as you can see from the changes dealing with stack_t in the ‘sys_rt_sigreturn' and ‘setup_rt_frame’ functions. While these could have been duplicated and specialized for each ABI (as on x32), the attempt was made to keep these changes localized. However, this approach can not always work: if you consider cases like ‘sys_msgsnd’ and ‘compat_sys_msgsnd’, there’s little to no benefit in having just a ‘aarch64_sys_msgsnd’, which then calls either the LP64 or the compat version of the underlying system call. Having a second system call table helps to reduce the overheads in this case and keeps things readable. This comes down to the fact, that a few calls will always be different due to historical baggage in data structures shared between userspace and kernel: 'struct msgbuf’ immediatly comes to mind. I would liken the situation with ARM64 more of MIPS64 with its 64bit ABI and its n32 ABI than to x32… but even there it’s two separate system call tables (although sequentially concatenated). In other words: I fail to see the benefit from keeping the existing table. I you elaborate on how such a solution should look, I might be better able to follow. > The most important aspect here I think is time_t, and while it means starting > out with a system call ABI that is not ready for y2038, at the same time the > purpose of ILP32 support is to support legacy source code that is not 64-bit > safe now, and using 32-bit time_t will make that easier in a lot of ways. > Note that I am also leading the effort to make 32-bit Linux ready for using > 64-bit time_t on all architectures, so ARM64 ILP32 will be fixed as well, it > just won't be any better or worse than the others. The decision to use the 64bit time_t actually came out of Andrew’s earliest patch-set from late 2013… we based the kernel-side of ILP32 on that one, while we focussed on getting all the other components into a working shape. Breaking the C specification (by redefining time_t) always remained a controversial issue on our end, as we knew that the day of switching back to a 32-bit time_t would eventually have to come. Cheers, Phil. [1] https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=meissner2.pdf-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http:/
Re: [PATCH v4 00/24] ILP32 for ARM64
More comments below. > On 17 Apr 2015, at 16:46, Catalin Marinas wrote: > > Even in this case, we could enable AArch32 compat knowing that ioctls > wouldn't work. If this is important, we can add an option to enable > ioctl support for ILP32 and re-target the asm/compat.h definitions. > >> g) create a new ABI that does things in exactly the way that we >> would use as the native syscall interface if we had an ilp32 >> kernel running on aarch64 with the asm-generic/unistd.h. >> This would mean a 32-bit __kernel_long_t and time_t, but extending >> time_t in the long run, together with aarch32 and i386. >> This one is particularly interesting for people that are interested >> in maximum posix compliance and in having a "nice" ABI, in particular >> if there is a slight chance that within the next decade we have >> reason to support building an arch/arm64 kernel itself in >> aarch64-ilp32 mode. I don’t believe that an ILP32 kernel wouldn’t use an uint64_t for time_t, as it has full support for 64bit arithmetic anyway. I also believe that other kernel internals (e.g. filesystems and inode-numbering) would use native 64bit types. The differences on the kernel side would mainly rest in that only a 32bit address space could reasonably be managed. So a native ILP32 ABI would differ from the LP64 ABI mainly in how sizeof(long) is represented in the user-space. In other works: a native ILP32 ABI on an ILP32 kernel would have a 64bit time_t. However, it would be nice to get agreement on the normal 32-bit ABI for time_t and timespec first, and then use the same thing everywhere. >>> >>> Do you mean for native 32-bit architectures? I think OpenBSD uses a >>> 64-bit time_t already on 32-bit arches, it's doable in Linux as well. >> >> Yes, and I'm working on that for Linux. The first step involves fixing >> the kernel, one file at a time, changing all users of time_t to use >> some other type (ktime_t or time64_t in most cases) instead, and introducing >> additional system calls to handle the boundary to user space without >> breaking stuff. See my presentation at >> http://elinux.org/ELC_2015_Presentations >> for more detail. > > The approach here is primarily to fix the problem for existing 32-bit > architectures by adding a new syscall and that's fine. But what if we > enforce 64-bit time_t for all _new_ architectures? This boils down to whether we can define all the new syscalls _right now_ and get the new (extended) compat-layer set up. In this case we could have a userspace implementation that already conforms to this for ILP32. Otherwise, we can just put a (MIPS64) N32-alike (AArch64) ILP32 in and migrate with everyone else. Although it feels wrong to add another ABI that has a known limitation, this may in fact be the easiest way, as any fix to ILP32 would be done together with the fixes to all other 32bit ABIs. So, while I would like to have a 64bit time_t for ILP32 based on principle, I do see the 32bit time_t path as the most pragmatic way forward… especially, as this unlinks getting “some form of” ILP32 merged from resolving the 64bit time_t issue across all architectures. Phil.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64
Yury & Pavel, > On 24 May 2018, at 14:15, Yury Norov wrote: > > Hi Pavel, > > On Wed, May 23, 2018 at 04:06:20PM +0200, Pavel Machek wrote: >> On Wed 2018-05-16 11:18:52, Yury Norov wrote: >>> Based on Andrew Pinski's patch-series. >>> >>> Signed-off-by: Yury Norov >> >> So Andrew's signoff should be here? > > Yes it should, but it lost since v4. I'll restore it. > >>> --- >>> Documentation/arm64/ilp32.txt | 45 +++ >>> 1 file changed, 45 insertions(+) >>> create mode 100644 Documentation/arm64/ilp32.txt >>> >>> diff --git a/Documentation/arm64/ilp32.txt b/Documentation/arm64/ilp32.txt >>> new file mode 100644 >>> index ..d0fd5109c4b2 >>> --- /dev/null >>> +++ b/Documentation/arm64/ilp32.txt >>> @@ -0,0 +1,45 @@ >>> +ILP32 AARCH64 SYSCALL ABI >>> += >>> + >>> +This document describes the ILP32 syscall ABI and where it differs >>> +from the generic compat linux syscall interface. >> >> I was hoping to learn what ILP32 is / what is it good for, but no, >> this does not tell me... it would be good to do a short explanation >> here, and maybe reference it from cover letter of the series... >> Pavel > > ILP32 is ABI acronym that means "Integers, Longs and Pointers are 32-bit". > And LP64 means "Longs and Pointers are 64-bit”. Just a nitpick: ILP32 is in fact just the memory model, but calling from ILP32 code into the Linux kernel requires modifications to the syscall-ABI due to datastructure layout changing (every time a pointer or a ‘long’ is present in a structure). As such structures are passed between the userspace and the kernel (and also due to the fact that time_t is an ‘unsigned long’ in the C language standard), modifications to the syscall ABI in Linux are needed to support ILP32 processes calling into the kernel. Things get a bit more involved, as the final consensus was to pass 64bit quantities in the lower half of 2 64bit registers instead of as a single register: this makes the way (on AArch64) that an ILP32 process calls into the kernel more dissimilar from a LP64 process calling the same syscall. What this rambling boils down to is: “ILP32" is the memory model, whereas this series deals with the “Linux/AArch64 syscall ABI for ILP32 processes”. Thanks, Phil. > > There's AN490 - "ILP32 for AArch64 Whitepaper" from ARM which covers > the topic: > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html > > And some talks: > http://connect.linaro.org/resource/bkk16/bkk16-305b/ > > Briefly, ILP32 is 32-bit ABI that works with AARCH64 instruction set. It looks > better in some performance tests, and is useful for compatibility with 32-bit > legacy code. > > If you're more familiar with x86 terminology, in ARM world LP64 corresponds > to x86_64, AARCH32_EL0 corresponds to x86_32, and ILP32 corresponds to x32 > ABI. > > I'll add link to AN490 in next submission. > > Yury > >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [Question] New mmap64 syscall?
Catalin, > On 07 Dec 2016, at 17:32, Catalin Marinas wrote: > >>> In other words: Why not keep ILP32 simple an ask users that need a 16TB+ >>> offset >>> to use LP64? It seems much more consistent with the other choices takes so >>> far. >> >> If user can switch to lp64, he doesn't need ilp32 at all, right? :) >> Also, I don't understand how true 64-bit offset in mmap64() would >> complicate this port. > > It's more like the user wanting a quick transition from code that was > only ever compiled for AArch32 (or other 32-bit architecture) with a > goal of full LP64 transition on the long run. I have yet to see > convincing benchmarks showing ILP32 as an advantage over LP64 (of > course, I hear the argument of reading a pointer a loop is twice as fast > with a half-size pointer but I don't consider such benchmarks relevant). Most of the performance advantage in benchmarks comes from a reduction in the size of data-structures and/or tighter packing of arrays. In other words, we can make slightly better use of the caches and push the memory subsystem a little further when running multiple instances of benchmarks. Most of these advantages should eventually go away, when struct-reorg makes it way into the compiler. That said, it’s a marginal (but real) improvement for a subset of SPEC. In the real world, the importance of ILP32 as an aid to transition legacy code that is not 64bit clean… and this should drive the ILP32 discussion. That we get a boost in our SPEC scores is just a nice extra that we get from it ;-) Regards, Philipp.
Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64
> On 17 Aug 2016, at 14:48, Yury Norov wrote: > > On Wed, Aug 17, 2016 at 02:28:50PM +0200, Alexander Graf wrote: >> >>> On 17 Aug 2016, at 13:46, Yury Norov wrote: >>> >>> This series enables aarch64 with ilp32 mode, and as supporting work, >>> introduces ARCH_32BIT_OFF_T configuration option that is enabled for >>> existing 32-bit architectures but disabled for new arches (so 64-bit >>> off_t is is used by new userspace). >>> >>> This version is based on kernel v4.8-rc2. >>> It works with glibc-2.23, and tested with LTP. >>> >>> This is RFC because there is still no solid understanding what type of >>> registers >>> top-halves delousing we prefer. In this patchset, w0-w7 are cleared for each >>> syscall in assembler entry. The alternative approach is in introducing >>> compat >>> wrappers which is little faster for natively routed syscalls (~2.6% for >>> syscall >>> with no payload) but much more complicated. >> >> So you’re saying there are 2 options: >> >> 1) easy to get right, slightly slower, same ABI to user space as 2 >> 2) harder to get right, minor performance benefit > > No, ABI is little different. If 1) we pass off_t in a pair to syscalls, > if 2) - in a single register. So if 1, we 'd take some wrappers from aarch32. > See patch 12 here. >From our experience with ILP32, I’d prefer to have off_t (and similar) in a >single register whenever possible (i.e. option #2). It feels more natural to use the full 64bit registers whenever possible, as ILP32 on ARMv8 should really be understood as a 64bit ABI with a 32bit memory model. Cheers, Philipp.
Re: [RFC2 nowrap: PATCH v7 00/18] ILP32 for ARM64
> On 17 Aug 2016, at 16:29, Catalin Marinas wrote: > > On Wed, Aug 17, 2016 at 02:54:59PM +0200, Dr. Philipp Tomsich wrote: >> On 17 Aug 2016, at 14:48, Yury Norov wrote: >>> On Wed, Aug 17, 2016 at 02:28:50PM +0200, Alexander Graf wrote: >>>> On 17 Aug 2016, at 13:46, Yury Norov wrote: >>>>> This series enables aarch64 with ilp32 mode, and as supporting work, >>>>> introduces ARCH_32BIT_OFF_T configuration option that is enabled for >>>>> existing 32-bit architectures but disabled for new arches (so 64-bit >>>>> off_t is is used by new userspace). >>>>> >>>>> This version is based on kernel v4.8-rc2. >>>>> It works with glibc-2.23, and tested with LTP. >>>>> >>>>> This is RFC because there is still no solid understanding what type of >>>>> registers >>>>> top-halves delousing we prefer. In this patchset, w0-w7 are cleared for >>>>> each >>>>> syscall in assembler entry. The alternative approach is in introducing >>>>> compat >>>>> wrappers which is little faster for natively routed syscalls (~2.6% for >>>>> syscall >>>>> with no payload) but much more complicated. >>>> >>>> So you’re saying there are 2 options: >>>> >>>> 1) easy to get right, slightly slower, same ABI to user space as 2 >>>> 2) harder to get right, minor performance benefit >>> >>> No, ABI is little different. If 1) we pass off_t in a pair to syscalls, >>> if 2) - in a single register. So if 1, we 'd take some wrappers from >>> aarch32. >>> See patch 12 here. >> >> From our experience with ILP32, I’d prefer to have off_t (and similar) >> in a single register whenever possible (i.e. option #2). It feels >> more natural to use the full 64bit registers whenever possible, as >> ILP32 on ARMv8 should really be understood as a 64bit ABI with a 32bit >> memory model. > > I think we are well past the point where we considered ILP32 a 64-bit > ABI. It would have been nice but we decided that breaking POSIX > compatibility is a bad idea, so we went back (again) to a 32-bit ABI for > ILP32. While there are 64-bit arguments that, at a first look, would > make sense to be passed in 64-bit registers, the kernel maintenance cost > is significant with changes to generic files. > > Allowing 64-bit wide registers at the ILP32 syscall interface means that > the kernel would have to zero/sign-extend the upper half of the 32-bit > arguments for the cases where they are passed directly to a native > syscall that expects a 64-bit argument. This (a) adds a significant > number of wrappers to the generic code together additional annotations > to the generic unistd.h and (b) it adds a small overhead to the AArch32 > (compat) ABI since it doesn't need such generic wrapping (the upper half > of 64-bit registers is guaranteed to be zero/preserved by the > architecture when coming from the AArch32 mode). Yes, I remember the discussions and just wanted to put option #2 in context again. Everything points to just going with the pair-of-registers and getting this merged quickly then, I suppose. Cheers, Philipp.
Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return
Yury,
this patch has been based on an earlier version of vdso and mainly adjusted to
match
the requirements of commit 601255ae3c98fd3a8bb4696425e4f868b4f1.
As these are mainly style-changes, please feel free to revise and adjust as
needed.
Regards,
Philipp.
> On 01 Oct 2015, at 21:44, Yury Norov wrote:
>
> On Tue, Sep 29, 2015 at 11:06:13PM -0500, Nathan Lynch wrote:
>> On 09/29/2015 05:14 PM, Yury Norov wrote:
>>> From: Philipp Tomsich
>>>
>>> Adjusted to move the move data page before code pages in sync with
>>> commit 601255ae3c98fd3a8bb4696425e4f868b4f1
>>
>> This commit message needs more information about how the ilp32 VDSO uses
>> the existing arm64 code. I had to really hunt through the Makefile to
>> figure out what's going on.
>>
>> The commit message should also identify the APIs that are supported.
>> The subject line mentions signal return, but gettimeofday, clock_gettime
>> and clock_getres are being added here too, and it is not obvious.
>>
>>
>>> Signed-off-by: Philipp Tomsich
>>> Signed-off-by: Christoph Muellner
>>> Signed-off-by: Yury Norov
>>>
>>> create mode 100644 arch/arm64/kernel/vdso-ilp32/.gitignore
>>> create mode 100644 arch/arm64/kernel/vdso-ilp32/Makefile
>>> copy arch/arm64/{include/asm/vdso.h => kernel/vdso-ilp32/vdso-ilp32.S} (56%)
>>> create mode 100644 arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
>>
>> How are you invoking git-format-patch? The copy detection in this case
>> is not conducive to review.
>>
>> It looks like the existing arm64 vdso Makefile has been copied to
>> vdso-ilp32/ and adjusted for paths and naming. While the gettimeofday
>> assembly implementation is reused, the build logic is duplicated. x86
>> produces VDSOs for multiple ABIs with a single Makefile; is a similar
>> approach not appropriate for arm64?
>>
>>
>>> diff --git a/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
>>> b/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
>>> new file mode 100644
>>> index 000..ac8029b
>>> --- /dev/null
>>> +++ b/arch/arm64/kernel/vdso-ilp32/vdso-ilp32.lds.S
>>> @@ -0,0 +1,98 @@
>>
>> [...]
>>
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +/*OUTPUT_FORMAT("elf32-littleaarch64", "elf32-bigaarch64",
>>> "elf32-littleaarch64")
>>> +OUTPUT_ARCH(aarch64)
>>> +*/
>>
>> If these lines aren't needed then omit them.
>>
>> [...]
>>
>>
>>> +/*
>>> + * This controls what symbols we export from the DSO.
>>> + */
>>> +VERSION
>>> +{
>>> + LINUX_2.6.39 {
>>> + global:
>>> + __kernel_rt_sigreturn;
>>> + __kernel_gettimeofday;
>>> + __kernel_clock_gettime;
>>> + __kernel_clock_getres;
>>> + local: *;
>>> + };
>>> +}
>>
>> Something that came up during review of arch/arm's VDSO code: consider
>> using version and names that match x86, i.e. LINUX_2.6, __vdso_gettimeofday.
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267940.html
>>
>> Using LINUX_2.6.39 for this code is nonsensical.
>>
>>
>>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>>> index b239b9b..bed6cf1 100644
>>> --- a/arch/arm64/kernel/vdso.c
>>> +++ b/arch/arm64/kernel/vdso.c
>>> @@ -40,6 +40,12 @@ extern char vdso_start, vdso_end;
>>> static unsigned long vdso_pages;
>>> static struct page **vdso_pagelist;
>>>
>>> +#ifdef CONFIG_ARM64_ILP32
>>> +extern char vdso_ilp32_start, vdso_ilp32_end;
>>> +static unsigned long vdso_ilp32_pages;
>>> +static struct page **vdso_ilp32_pagelist;
>>> +#endif
>>> +
>>> /*
>>> * The vDSO data page.
>>> */
>>> @@ -117,24 +123,29 @@ int aarch32_setup_vectors_page(struct linux_binprm
>>> *bprm, int uses_interp)
>>> }
>>> #endif /* CONFIG_AARCH32_EL0 */
>>>
>>> -static struct vm_special_mapping vdso_spec[2];
>>> -
>>> -static int __init vdso_init(void)
>>> +static inline int __init vdso_init_common(char *vdso_start, char *vdso_end,
>>
>> No inline please.
>>
>>
>>> + unsigned long *vdso_pagesp,
>>> + struct page ***vdso_pagelistp,
>>> + struct vm_special_mapping* vdso_spec)
>>> {
>>
>> [...]
>>
>>> int arch_setup_additional_pages(struct linux_binprm *bprm,
>>> int uses_interp)
>>> {
>>> struct mm_struct *mm = current->mm;
>>> unsigned long vdso_base, vdso_text_len, vdso_mapping_len;
>>> - void *ret;
>>> + void* ret;
>>
>> Gratuitous (and incorrect) style change.
>>
>>
>>> + unsigned long pages = vdso_pages;
>>> + struct vm_special_mapping* spec = vdso_spec;
>>
>> Incorrect style: *spec
>
> Hi Nathan,
>
> If Philipp Philipp Tomsich will not answer soon, I'll fix all this.
>
> BR,
> Yury.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 18/19] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32
Yury, We had implemented gdb-support against the the earlier ILP32 incarnation. I’ll take a look with the latest patch-set and see whether these still apply. Best, Philipp. > On 18 Nov 2015, at 21:25, Yury Norov wrote: > > On Wed, Nov 18, 2015 at 03:21:05AM -0800, pins...@gmail.com wrote: >> >> >>> On Nov 18, 2015, at 12:11 AM, Zhangjian (Bamvor) >>> wrote: >>> >>> Hi, Yury >>> >>>> On 2015/11/18 5:16, Yury Norov wrote: >>>> From: Philipp Tomsich >>>> >>>> To make life for tools (such as gdb) easier when dealing with ILP32 >>>> processes, >>>> we report a proper subarchitecture for ILP32 in the ELF auxiliary vectors. >>> I saw some ilp32 relative patches in binutils mailing list. Does gdb >>> fully support ilp32? >> >> I have a patch set but I have not tested them with the latest kernel patch >> set yet. The branch is located in the binutils-gdb git is >> https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/pinskia/gdb-aarch64-ilp32 >> . >> I think it will mostly work except for core support might need to be changed >> slightly. >> >> Thanks, >> Andrew >>> > > Yes, it works mostly. I can read and modify text/data, set breakpoints > etc. > >>> Regards >>> >>> Bamvor >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
> On 18 Dec 2015, at 13:47, Arnd Bergmann wrote: > >> 3. Follow the PCS up to glibc but always pass syscall arguments in W >> registers, like AArch32 compat support (the least preferred option, >> the only advantage is a single wrapper for all syscalls but it would >> be doing unnecessary zeroing even for syscalls where it isn't needed) > > This would mean we cannot pass 64-bit arguments in registers, right? Note that there’s no 32bit registers (the ‘w’-form always refers to the lower 32bits of a 64bit register, with implicit zero-extension)… and load/store instructions always use the full base-register (‘x’-form) for address calculation. I.e. a load/store would inadvertently pickup “random garbage” in the upper 32bits, if no explicit zero-extension is applied. In other words: all zero-extensions for 32bit arguments should be explicit on the kernel side. Regards, Philipp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 05/19] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
Catalin, > Quick question: IIRC, earlier aarch64 gcc versions did not generate > __ILP32__ when -mabi=ilp32, they only removed __LP64__. When did the > change happen? Could we assume that all compiler versions used to > generate ILP32 would define this? The __ILP32__ define has been supported since > commit b01b37f5768911598640cf8a8c82beacb4200c13 > Author: yufeng > Date: Tue Jul 23 12:26:33 2013 + > > [AArch64, ILP32] 4/6 Define _ILP32 and __ILP32__. > > gcc/ > > * config/aarch64/aarch64.h (TARGET_CPU_CPP_BUILTINS): Define _ILP32 > and __ILP32__ when the ILP32 model is in use. > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@201167 > 138bc75d-0d04-0410-961f-82ee72b054a4 Best regards, Philipp.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] arm64: dts: add RK3399-Q7 (Puma) SoM
> On 28 Jun 2017, at 12:26, Heiko Stübner wrote:
>
> Hi Klaus,
>
> [added Kever from Rockchip concerning the cluster1-opps below]
>
>
> Am Montag, 26. Juni 2017, 21:18:54 CEST schrieb Klaus Goger:
>> The RK3399-Q7 SoM is a Qseven-compatible (70mm x 70mm, MXM-230
>> connector) system-on-module from Theobroma Systems, featuring the
>> Rockchip RK3399.
>>
>> It provides the following feature set:
>> * up to 4GB DDR3
>> * on-module SPI-NOR flash
>> * on-module eMMC (with 8-bit 1.8V interface)
>> * SD card (on a baseboad) via edge connector
>> * Gigabit Ethernet with on-module Micrel KSZ9031 GbE PHY
>> * HDMI/eDP/2x MIPI-DSI
>> * 2x MIPI-CSI
>> * USB
>> - 1x USB 3.0 dual-role (direct connection)
>> - 2x USB 3.0 host + 1x USB 2.0 (on-module USB 3.0 hub)
>> * on-module STM32 Cortex-M0 companion controller, implementing:
>> - low-power RTC functionality (ISL1208 emulation)
>> - fan controller (AMC6821 emulation)
>> - USB<->CAN bridge controller
>>
>> Signed-off-by: Klaus Goger
>>
>> ---
>
> [...]
>
>> +leds {
>> +compatible = "gpio-leds";
>> +pinctrl-names = "default";
>> +
>> +module_led {
>
> phandles use underscores, node names are supposed to use dashes "-"
>
>> +label = "module_led";
>> +gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_HIGH>;
>> +linux,default-trigger = "heartbeat";
>> +panic-indicator;
>> +};
>> +
>> +sd_card_led {
>> +label = "sd_card_led";
>> +gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;
>> +linux,default-trigger = "mmc0";
>> +};
>> +};
>> +
>> +cluster1_opp: opp-table1 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <40800>;
>> +opp-microvolt = <80>;
>> +clock-latency-ns = <4>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <6>;
>> +opp-microvolt = <80>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <81600>;
>> +opp-microvolt = <83>;
>
> this is 5mV higher than the "official" OPPs used by Rockchip, so
> I'd like to know its background :-) . Especially as I really would like
> to keep the number of per-board OPPs minimal.
The on-board regulators differ and can’t hit the voltages specified
in the original OPP table… this is the next closest value we can
set and is at least what Rockchip uses in the ref-design.
> So does this make the board run more stable or something else?
> And might this be applicable for all "standard" rk3399 boards?
> Especially as other OPPs in your list use the regular voltages.
It avoids ugly issues with OPPs being deactivated due to the the
exact voltage used in the “official” OPPs not being supported by
our regulator.
We decided against reusing the original OPP table and modifying it
(to use ranges) as that was likely to cause even more harm in the
long term.
>> +opp-suspend;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <100800>;
>> +opp-microvolt = <88>;
>
> same as above
>
>> +};
>> +opp04 {
>> +opp-hz = /bits/ 64 <12>;
>> +opp-microvolt = <95>;
>> +};
>> +opp05 {
>> +opp-hz = /bits/ 64 <141600>;
>> +opp-microvolt = <103>;
>
> same as above
>
>> +};
>> +opp06 {
>> +opp-hz = /bits/ 64 <160800>;
>> +opp-microvolt = <110>;
>> +};
>> +opp07 {
>> +opp-hz = /bits/ 64 <18>;
>> +opp-microvolt = <120>;
>> +};
>> +opp08 {
>> +opp-hz = /bits/ 64 <199200>;
>> +opp-microvolt = <123>;
>> +turbo-mode;
>
> Is this part of the soc-spec or more like wishful thinking? :-)
> Again with the question in mind if this applies to all rk3399.
Tested in our lab on a decent population of boards using various
forms of stress-testing (incl. a 6-way and 8-way SPEC).
This one is marked ‘turbo-mode’ as we do recommend to only
enable it if a (Qseven-style) heat-sink is mounted.
>> +};
>> +};
>> +
>> +clkin_gmac: external-gmac-clock {
>> +compatible = "fixed-clock";
>> +clock-frequency = <12500>;
>> +clock-output-names = "clkin_gmac";
>> +#clock-cells = <0>;
>> +};
>> +
>> +vcc3v3_sys: vcc3v3-sys {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vcc3v3_sys";
>> +regulator-a
