Skip to contentSkip to conversation

arm64: Scalable Vector Extension core support

RFC PATCH Superseded Dave Martin 8 participants 61 messages Nov 25, 2016 – Dec 6, 2016

Subsystems (4)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

cover arm64: Scalable Vector Extension core support

The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which adds extra SIMD functionality and supports much larger vectors.

This series implements core Linux support for SVE.

Recipents not copied on the whole series can find the rest of the patches in the linux-arm-kernel archives [2].

The first 5 patches "arm64: signal: ..." factor out the allocation and placement of state information in the signal frame. The first three are prerequisites for the SVE support patches.

Patches 04-05 implement expansion of the signal frame, and may remain controversial due to ABI break issues:

* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.

The remaining patches implement initial SVE support for Linux, with the following limitations:

* No KVM/virtualisation support for guests.

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

* As a temporary workaround for the signal frame size issue, vector length is software-limited to 512 bits (see patch 29), with a build-time kernel configuration option to relax this.

Discussion is needed on how to smooth address the signal ABI issues so that this workaround can be removed.

* A fair number of development BUG_ON()s are still present, which will be demoted or removed for merge.

* There is a context-switch race condition lurking somewhere which fires in certain situations with my development KVM hacks (not part of this posting) -- the underlying bug might or might not be in this series.

Review and comments welcome.

Cheers
---Dave

[1] https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture

[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/thread.html

Alan Hayward (1):
arm64/sve: ptrace support

Dave Martin (28):
arm64: signal: Refactor sigcontext parsing in rt_sigreturn
arm64: signal: factor frame layout and population into separate passes
arm64: signal: factor out signal frame record allocation
arm64: signal: Allocate extra sigcontext space as needed
arm64: signal: Parse extra_context during sigreturn
arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON arm64/sve: Allow kernel-mode NEON to be disabled in Kconfig arm64/sve: Low-level save/restore code
arm64/sve: Boot-time feature detection and reporting arm64/sve: Boot-time feature enablement
arm64/sve: Expand task_struct for Scalable Vector Extension state arm64/sve: Save/restore SVE state on context switch paths arm64/sve: Basic support for KERNEL_MODE_NEON
Revert "arm64/sve: Allow kernel-mode NEON to be disabled in Kconfig" arm64/sve: Restore working FPSIMD save/restore around signals arm64/sve: signal: Add SVE state record to sigcontext arm64/sve: signal: Dump Scalable Vector Extension registers to user
stack
arm64/sve: signal: Restore FPSIMD/SVE state in rt_sigreturn arm64/sve: Avoid corruption when replacing the SVE state arm64/sve: traps: Add descriptive string for SVE exceptions arm64/sve: Enable SVE on demand for userspace
arm64/sve: Implement FPSIMD-only context for tasks not using SVE arm64/sve: Move ZEN handling to the common task_fpsimd_load() path arm64/sve: Discard SVE state on system call
arm64/sve: Avoid preempt_disable() during sigreturn arm64/sve: Avoid stale user register state after SVE access exception
arm64: KVM: Treat SVE use by guests as undefined instruction execution arm64/sve: Limit vector length to 512 bits by default

 arch/arm64/Kconfig                       |  48 +++
 arch/arm64/include/asm/esr.h             |   3 +-
 arch/arm64/include/asm/fpsimd.h          |  37 +++
 arch/arm64/include/asm/fpsimdmacros.h    | 145 +++++++++
 arch/arm64/include/asm/kvm_arm.h         |   1 +
 arch/arm64/include/asm/sysreg.h          |  11 +
 arch/arm64/include/asm/thread_info.h     |   2 +
 arch/arm64/include/uapi/asm/hwcap.h      |   1 +
 arch/arm64/include/uapi/asm/ptrace.h     | 125 ++++++++
 arch/arm64/include/uapi/asm/sigcontext.h | 117 ++++++++
 arch/arm64/kernel/cpufeature.c           |   3 +
 arch/arm64/kernel/cpuinfo.c              |   1 +
 arch/arm64/kernel/entry-fpsimd.S         |  17 ++
 arch/arm64/kernel/entry.S                |  18 +-
 arch/arm64/kernel/fpsimd.c               | 301 ++++++++++++++++++-
 arch/arm64/kernel/head.S                 |  16 +-
 arch/arm64/kernel/process.c              |   2 +-
 arch/arm64/kernel/ptrace.c               | 254 +++++++++++++++-
 arch/arm64/kernel/setup.c                |   3 +
 arch/arm64/kernel/signal.c               | 497 +++++++++++++++++++++++++++++--
 arch/arm64/kernel/signal32.c             |   2 +-
 arch/arm64/kernel/traps.c                |   1 +
 arch/arm64/kvm/handle_exit.c             |   9 +
 arch/arm64/mm/proc.S                     |  27 +-
 include/uapi/linux/elf.h                 |   1 +
 25 files changed, 1583 insertions(+), 59 deletions(-)
Signature · 1 line
2.1.4
#1 lore raw

RFC PATCH 1/29 arm64: signal: Refactor sigcontext parsing in rt_sigreturn

Currently, rt_sigreturn does very limited checking on the sigcontext coming from userspace.

Future additions of extra dynamic sigcontext data will increase the potential for surprises. Also, it is not clear whether the sigcontext extension records are supposed to occur in a particular order.

This patch factors out the sigcontext parsing into a separate function, and adds extra checks to validate the well-formedness of the sigcontext structure.

To help with this, an abstraction for the signal frame layout is also added, using offsets to track the location of different records in the frame. Although trivial, this provides a base to extend upon in order to track more complex layouts.

---
 arch/arm64/kernel/signal.c | 121 +++++++++++++++++++++++++++++++++++++--------
 1 file changed, 101 insertions(+), 20 deletions(-)
arch/arm64/kernel/signal.c +101 -20
index 404dd67..4f8dbe0 100644
@@ -19,9 +19,11 @@
 
 #include <linux/compat.h>
 #include <linux/errno.h>
+#include <linux/kernel.h>
 #include <linux/signal.h>
 #include <linux/personality.h>
 #include <linux/freezer.h>
+#include <linux/stddef.h>
 #include <linux/uaccess.h>
 #include <linux/tracehook.h>
 #include <linux/ratelimit.h>
@@ -45,6 +47,10 @@ struct rt_sigframe {
 	u64 lr;
 };
 
+struct rt_sigframe_user_layout {
+	struct rt_sigframe __user *sigframe;
+};
+
 static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
 {
 	struct fpsimd_state *fpsimd = &current->thread.fpsimd_state;
@@ -92,12 +98,86 @@ static int restore_fpsimd_context(struct fpsimd_context __user *ctx)
 	return err ? -EFAULT : 0;
 }
 
+struct user_ctxs {
+	struct fpsimd_context __user *fpsimd;
+};
+
+static int parse_user_sigframe(struct user_ctxs *user,
+			       struct rt_sigframe __user *sf)
+{
+	struct sigcontext __user *sc = &sf->uc.uc_mcontext;
+	struct _aarch64_ctx __user *head =
+		(struct _aarch64_ctx __user *)&sc->__reserved;
+	size_t offset = 0;
+
+	user->fpsimd = NULL;
+
+	while (1) {
+		int err;
+		u32 magic, size;
+
+		head = (struct _aarch64_ctx __user *)&sc->__reserved[offset];
+		if (!IS_ALIGNED((unsigned long)head, 16))
+			goto invalid;
+
+		err = 0;
+		__get_user_error(magic, &head->magic, err);
+		__get_user_error(size, &head->size, err);
+		if (err)
+			return err;
+
+		switch (magic) {
+		case 0:
+			if (size)
+				goto invalid;
+
+			goto done;
+
+		case FPSIMD_MAGIC:
+			if (user->fpsimd)
+				goto invalid;
+
+			if (offset > sizeof(sc->__reserved) -
+					sizeof(*user->fpsimd) ||
+			    size < sizeof(*user->fpsimd))
+				goto invalid;
+
+			user->fpsimd = (struct fpsimd_context __user *)head;
+			break;
+
+		case ESR_MAGIC:
+			/* ignore */
+			break;
+
+		default:
+			goto invalid;
+		}
+
+		if (size < sizeof(*head))
+			goto invalid;
+
+		if (size > sizeof(sc->__reserved) - (sizeof(*head) + offset))
+			goto invalid;
+
+		offset += size;
+	}
+
+done:
+	if (!user->fpsimd)
+		goto invalid;
+
+	return 0;
+
+invalid:
+	return -EINVAL;
+}
+
 static int restore_sigframe(struct pt_regs *regs,
 			    struct rt_sigframe __user *sf)
 {
 	sigset_t set;
 	int i, err;
-	void *aux = sf->uc.uc_mcontext.__reserved;
+	struct user_ctxs user;
 
 	err = __copy_from_user(&set, &sf->uc.uc_sigmask, sizeof(set));
 	if (err == 0)
@@ -116,12 +196,11 @@ static int restore_sigframe(struct pt_regs *regs,
 	regs->syscallno = ~0UL;
 
 	err |= !valid_user_regs(&regs->user_regs, current);
+	if (err == 0)
+		err = parse_user_sigframe(&user, sf);
 
-	if (err == 0) {
-		struct fpsimd_context *fpsimd_ctx =
-			container_of(aux, struct fpsimd_context, head);
-		err |= restore_fpsimd_context(fpsimd_ctx);
-	}
+	if (err == 0)
+		err = restore_fpsimd_context(user.fpsimd);
 
 	return err;
 }
@@ -162,10 +241,11 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
 	return 0;
 }
 
-static int setup_sigframe(struct rt_sigframe __user *sf,
+static int setup_sigframe(struct rt_sigframe_user_layout *user,
 			  struct pt_regs *regs, sigset_t *set)
 {
 	int i, err = 0;
+	struct rt_sigframe __user *sf = user->sigframe;
 	void *aux = sf->uc.uc_mcontext.__reserved;
 	struct _aarch64_ctx *end;
 
@@ -209,33 +289,32 @@ static int setup_sigframe(struct rt_sigframe __user *sf,
 	return err;
 }
 
-static struct rt_sigframe __user *get_sigframe(struct ksignal *ksig,
-					       struct pt_regs *regs)
+static int get_sigframe(struct rt_sigframe_user_layout *user,
+			 struct ksignal *ksig, struct pt_regs *regs)
 {
 	unsigned long sp, sp_top;
-	struct rt_sigframe __user *frame;
 
 	sp = sp_top = sigsp(regs->sp, ksig);
 
 	sp = (sp - sizeof(struct rt_sigframe)) & ~15;
-	frame = (struct rt_sigframe __user *)sp;
+	user->sigframe = (struct rt_sigframe __user *)sp;
 
 	/*
 	 * Check that we can actually write to the signal frame.
 	 */
-	if (!access_ok(VERIFY_WRITE, frame, sp_top - sp))
-		frame = NULL;
+	if (!access_ok(VERIFY_WRITE, user->sigframe, sp_top - sp))
+		return -EFAULT;
 
-	return frame;
+	return 0;
 }
 
 static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
-			 void __user *frame, int usig)
+			 struct rt_sigframe_user_layout *user, int usig)
 {
 	__sigrestore_t sigtramp;
 
 	regs->regs[0] = usig;
-	regs->sp = (unsigned long)frame;
+	regs->sp = (unsigned long)user->sigframe;
 	regs->regs[29] = regs->sp + offsetof(struct rt_sigframe, fp);
 	regs->pc = (unsigned long)ka->sa.sa_handler;
 
@@ -250,20 +329,22 @@ static void setup_return(struct pt_regs *regs, struct k_sigaction *ka,
 static int setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
 			  struct pt_regs *regs)
 {
+	struct rt_sigframe_user_layout user;
 	struct rt_sigframe __user *frame;
 	int err = 0;
 
-	frame = get_sigframe(ksig, regs);
-	if (!frame)
+	if (get_sigframe(&user, ksig, regs))
 		return 1;
 
+	frame = user.sigframe;
+
 	__put_user_error(0, &frame->uc.uc_flags, err);
 	__put_user_error(NULL, &frame->uc.uc_link, err);
 
 	err |= __save_altstack(&frame->uc.uc_stack, regs->sp);
-	err |= setup_sigframe(frame, regs, set);
+	err |= setup_sigframe(&user, regs, set);
 	if (err == 0) {
-		setup_return(regs, &ksig->ka, frame, usig);
+		setup_return(regs, &ksig->ka, &user, usig);
 		if (ksig->ka.sa.sa_flags & SA_SIGINFO) {
 			err |= copy_siginfo_to_user(&frame->info, &ksig->info);
 			regs->regs[1] = (unsigned long)&frame->info;
Signature · 1 line
2.1.4
#2 lore raw

RFC PATCH 2/29 arm64: signal: factor frame layout and population into separate passes

In reply to Dave Martin

In preparation for expanding the signal frame, this patch refactors the signal frame setup code in setup_sigframe() into two separate passes.

The first pass, setup_sigframe_layout(), determines the sizeof the signal frame and its internal layout, including the presence and location of optional records. The resulting knowledge is used to allocate and locate the user stack space required for the signal frame and to determine which optional records to include.

The second pass, setup_sigframe(), is called once the stack frame is allocated in order to populate it with the necessary context information.

This change has no effect on the signal ABI, but will make it easier to expand the signal frame in future patches.

---
 arch/arm64/kernel/signal.c | 112 +++++++++++++++++++++++++++++++++++----------
 1 file changed, 88 insertions(+), 24 deletions(-)
arch/arm64/kernel/signal.c +88 -24
index 4f8dbe0..fc08371 100644
@@ -25,6 +25,7 @@
 #include <linux/freezer.h>
 #include <linux/stddef.h>
 #include <linux/uaccess.h>
+#include <linux/string.h>
 #include <linux/tracehook.h>
 #include <linux/ratelimit.h>
 
@@ -49,8 +50,39 @@ struct rt_sigframe {
 
 struct rt_sigframe_user_layout {
 	struct rt_sigframe __user *sigframe;
+
+	unsigned long size;	/* size of allocated sigframe data */
+	unsigned long limit;	/* largest allowed size */
+
+	unsigned long fpsimd_offset;
+	unsigned long esr_offset;
+	unsigned long end_offset;
 };
 
+static void init_user_layout(struct rt_sigframe_user_layout *user)
+{
+	memset(user, 0, sizeof(*user));
+	user->size = offsetof(struct rt_sigframe, uc.uc_mcontext.__reserved);
+
+	user->limit = user->size +
+		sizeof(user->sigframe->uc.uc_mcontext.__reserved) -
+		round_up(sizeof(struct _aarch64_ctx), 16);
+		/* ^ reserve space for terminator */
+}
+
+static size_t sigframe_size(struct rt_sigframe_user_layout const *user)
+{
+	return round_up(max(user->size, sizeof(struct rt_sigframe)), 16);
+}
+
+static void __user *apply_user_offset(
+	struct rt_sigframe_user_layout const *user, unsigned long offset)
+{
+	char __user *base = (char __user *)user->sigframe;
+
+	return base + offset;
+}
+
 static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
 {
 	struct fpsimd_state *fpsimd = &current->thread.fpsimd_state;
@@ -106,26 +138,35 @@ static int parse_user_sigframe(struct user_ctxs *user,
 			       struct rt_sigframe __user *sf)
 {
 	struct sigcontext __user *sc = &sf->uc.uc_mcontext;
-	struct _aarch64_ctx __user *head =
-		(struct _aarch64_ctx __user *)&sc->__reserved;
+	struct _aarch64_ctx __user *head;
+	char __user *base = (char __user *)&sc->__reserved;
 	size_t offset = 0;
+	size_t limit = sizeof(sc->__reserved);
 
 	user->fpsimd = NULL;
 
+	if (!IS_ALIGNED((unsigned long)base, 16))
+		goto invalid;
+
 	while (1) {
-		int err;
+		int err = 0;
 		u32 magic, size;
 
-		head = (struct _aarch64_ctx __user *)&sc->__reserved[offset];
-		if (!IS_ALIGNED((unsigned long)head, 16))
+		if (limit - offset < sizeof(*head))
 			goto invalid;
 
-		err = 0;
+		if (!IS_ALIGNED(offset, 16))
+			goto invalid;
+
+		head = (struct _aarch64_ctx __user *)(base + offset);
 		__get_user_error(magic, &head->magic, err);
 		__get_user_error(size, &head->size, err);
 		if (err)
 			return err;
 
+		if (limit - offset < size)
+			goto invalid;
+
 		switch (magic) {
 		case 0:
 			if (size)
@@ -137,9 +178,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
 			if (user->fpsimd)
 				goto invalid;
 
-			if (offset > sizeof(sc->__reserved) -
-					sizeof(*user->fpsimd) ||
-			    size < sizeof(*user->fpsimd))
+			if (size < sizeof(*user->fpsimd))
 				goto invalid;
 
 			user->fpsimd = (struct fpsimd_context __user *)head;
@@ -156,7 +195,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
 		if (size < sizeof(*head))
 			goto invalid;
 
-		if (size > sizeof(sc->__reserved) - (sizeof(*head) + offset))
+		if (limit - offset < size)
 			goto invalid;
 
 		offset += size;
@@ -241,13 +280,30 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
 	return 0;
 }
 
+/* Determine the layout of optional records in the signal frame */
+static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
+{
+	user->fpsimd_offset = user->size;
+	user->size += round_up(sizeof(struct fpsimd_context), 16);
+
+	/* fault information, if valid */
+	if (current->thread.fault_code) {
+		user->esr_offset = user->size;
+		user->size += round_up(sizeof(struct esr_context), 16);
+	}
+
+	/* set the "end" magic */
+	user->end_offset = user->size;
+
+	return 0;
+}
+
+
 static int setup_sigframe(struct rt_sigframe_user_layout *user,
 			  struct pt_regs *regs, sigset_t *set)
 {
 	int i, err = 0;
 	struct rt_sigframe __user *sf = user->sigframe;
-	void *aux = sf->uc.uc_mcontext.__reserved;
-	struct _aarch64_ctx *end;
 
 	/* set up the stack frame for unwinding */
 	__put_user_error(regs->regs[29], &sf->fp, err);
@@ -265,26 +321,29 @@ static int setup_sigframe(struct rt_sigframe_user_layout *user,
 	err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(*set));
 
 	if (err == 0) {
-		struct fpsimd_context *fpsimd_ctx =
-			container_of(aux, struct fpsimd_context, head);
+		struct fpsimd_context __user *fpsimd_ctx =
+			apply_user_offset(user, user->fpsimd_offset);
 		err |= preserve_fpsimd_context(fpsimd_ctx);
-		aux += sizeof(*fpsimd_ctx);
 	}
 
 	/* fault information, if valid */
-	if (current->thread.fault_code) {
-		struct esr_context *esr_ctx =
-			container_of(aux, struct esr_context, head);
+	if (err == 0 && user->esr_offset) {
+		struct esr_context __user *esr_ctx =
+			apply_user_offset(user, user->esr_offset);
+
 		__put_user_error(ESR_MAGIC, &esr_ctx->head.magic, err);
 		__put_user_error(sizeof(*esr_ctx), &esr_ctx->head.size, err);
 		__put_user_error(current->thread.fault_code, &esr_ctx->esr, err);
-		aux += sizeof(*esr_ctx);
 	}
 
 	/* set the "end" magic */
-	end = aux;
-	__put_user_error(0, &end->magic, err);
-	__put_user_error(0, &end->size, err);
+	if (err == 0) {
+		struct _aarch64_ctx __user *end =
+			apply_user_offset(user, user->end_offset);
+
+		__put_user_error(0, &end->magic, err);
+		__put_user_error(0, &end->size, err);
+	}
 
 	return err;
 }
@@ -293,10 +352,15 @@ static int get_sigframe(struct rt_sigframe_user_layout *user,
 			 struct ksignal *ksig, struct pt_regs *regs)
 {
 	unsigned long sp, sp_top;
+	int err;
 
-	sp = sp_top = sigsp(regs->sp, ksig);
+	init_user_layout(user);
+	err = setup_sigframe_layout(user);
+	if (err)
+		return err;
 
-	sp = (sp - sizeof(struct rt_sigframe)) & ~15;
+	sp = sp_top = sigsp(regs->sp, ksig);
+	sp = (sp & ~15) - sigframe_size(user);
 	user->sigframe = (struct rt_sigframe __user *)sp;
 
 	/*
Signature · 1 line
2.1.4
#3 lore raw

RFC PATCH 3/29 arm64: signal: factor out signal frame record allocation

In reply to Dave Martin

Factor out the allocator for signal frame optional records into a separate function, to ensure consistency and facilitate later expansion of the signal frame.

---
 arch/arm64/kernel/signal.c | 43 ++++++++++++++++++++++++++++++++++++-------
 1 file changed, 36 insertions(+), 7 deletions(-)
arch/arm64/kernel/signal.c +36 -7
index fc08371..653b614 100644
@@ -75,6 +75,22 @@ static size_t sigframe_size(struct rt_sigframe_user_layout const *user)
 	return round_up(max(user->size, sizeof(struct rt_sigframe)), 16);
 }
 
+/*
+ * Allocate space for an optional record of <size> bytes in the user
+ * signal frame.  The offset from the signal frame base address to the
+ * allocated block is assigned to *offset.
+ */
+static int sigframe_alloc(struct rt_sigframe_user_layout *user,
+			  unsigned long *offset, size_t size)
+{
+	size_t padded_size = round_up(size, 16);
+
+	*offset = user->size;
+	user->size += padded_size;
+
+	return 0;
+}
+
 static void __user *apply_user_offset(
 	struct rt_sigframe_user_layout const *user, unsigned long offset)
 {
@@ -283,19 +299,32 @@ asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
 /* Determine the layout of optional records in the signal frame */
 static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
 {
-	user->fpsimd_offset = user->size;
-	user->size += round_up(sizeof(struct fpsimd_context), 16);
+	int err;
+
+	err = sigframe_alloc(user, &user->fpsimd_offset,
+			     sizeof(struct fpsimd_context));
+	if (err)
+		return err;
 
 	/* fault information, if valid */
 	if (current->thread.fault_code) {
-		user->esr_offset = user->size;
-		user->size += round_up(sizeof(struct esr_context), 16);
+		err = sigframe_alloc(user, &user->esr_offset,
+				     sizeof(struct esr_context));
+		if (err)
+			return err;
 	}
 
-	/* set the "end" magic */
-	user->end_offset = user->size;
+	/*
+	 * Allocate space for the terminator record.
+	 * HACK: here we undo the reservation of space for the end record.
+	 * This bodge should be replaced with a cleaner approach later on.
+	 */
+	user->limit = offsetof(struct rt_sigframe, uc.uc_mcontext.__reserved) +
+		sizeof(user->sigframe->uc.uc_mcontext.__reserved);
 
-	return 0;
+	err = sigframe_alloc(user, &user->end_offset,
+			     sizeof(struct _aarch64_ctx));
+	return err;
 }
 
 
Signature · 1 line
2.1.4
#4 lore raw

RFC PATCH 4/29 arm64: signal: Allocate extra sigcontext space as needed

In reply to Dave Martin

This patch modifies the context block allocator to create an extra_context expansion block as necessary, and adds the necessary code to populate, parse and decode this block.

---
 arch/arm64/include/uapi/asm/sigcontext.h |  27 ++++++++
 arch/arm64/kernel/signal.c               | 112 +++++++++++++++++++++++++------
 2 files changed, 120 insertions(+), 19 deletions(-)
arch/arm64/include/uapi/asm/sigcontext.h +27 -0
index ee469be..1af8437 100644
@@ -61,4 +61,31 @@ struct esr_context {
 	__u64 esr;
 };
 
+/*
+ * Pointer to extra space for additional structures that don't fit in
+ * sigcontext.__reserved[].  Note:
+ *
+ * 1) fpsimd_context, esr_context and extra_context must be placed in
+ * sigcontext.__reserved[] if present.  They cannot be placed in the
+ * extra space.  Any other record can be placed either in the extra
+ * space or in sigcontext.__reserved[].
+ *
+ * 2) There must not be more than one extra_context.
+ *
+ * 3) If extra_context is present, it must be followed immediately in
+ * sigcontext.__reserved[] by the terminating null _aarch64_ctx (i.e.,
+ * extra_context must be the last record in sigcontext.__reserved[]
+ * except for the terminator).
+ *
+ * 4) The extra space must itself be terminated with a null
+ * _aarch64_ctx.
+ */
+#define EXTRA_MAGIC	0x45585401
+
+struct extra_context {
+	struct _aarch64_ctx head;
+	void *data;	/* 16-byte aligned pointer to the extra space */
+	__u32 size;	/* size in bytes of the extra space */
+};
+
 #endif /* _UAPI__ASM_SIGCONTEXT_H */
arch/arm64/kernel/signal.c +93 -19

157 lines not on this page · raw message

Signature · 1 line
2.1.4
#5 lore raw

RFC PATCH 5/29 arm64: signal: Parse extra_context during sigreturn

In reply to Dave Martin

If extra_context is present, parse it.

To avoid abuse by userspace, this patch attempts to ensure that:
* that no more than one extra_context is accepted;
* that the extra_context is a sensible size;
* that the extra context data is properly aligned.

This patch relies on the user accessors in order to ensure that the user-supplied extra context data pointer is an honest userspace address.

Other than that, the kernel doesn't care specially whether the pointer supplied is sensible (e.g., not garbage, doesn't overlap sigcontext.__reserved[], etc.) since this cannot harm the kernel.

More checks may be added later in order to aid debugging of botched sigreturns from userspace.

---
 arch/arm64/kernel/signal.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)
arch/arm64/kernel/signal.c +40 -0
index ea3f6bf..c7175a3 100644
@@ -221,6 +221,7 @@ static int parse_user_sigframe(struct user_ctxs *user,
 	char __user *base = (char __user *)&sc->__reserved;
 	size_t offset = 0;
 	size_t limit = sizeof(sc->__reserved);
+	bool have_extra_context = false;
 
 	user->fpsimd = NULL;
 
@@ -230,6 +231,9 @@ static int parse_user_sigframe(struct user_ctxs *user,
 	while (1) {
 		int err = 0;
 		u32 magic, size;
+		struct extra_context const __user *extra;
+		void __user *extra_data;
+		u32 extra_size;
 
 		if (limit - offset < sizeof(*head))
 			goto invalid;
@@ -267,6 +271,42 @@ static int parse_user_sigframe(struct user_ctxs *user,
 			/* ignore */
 			break;
 
+		case EXTRA_MAGIC:
+			if (have_extra_context)
+				goto invalid;
+
+			if (size < sizeof(*extra))
+				goto invalid;
+
+			extra = (struct extra_context const __user *)head;
+			__get_user_error(extra_data, &extra->data, err);
+			__get_user_error(extra_size, &extra->size, err);
+			if (err)
+				return err;
+
+			/* Prevent looping/repeated parsing of extra_conext */
+			have_extra_context = true;
+
+			/*
+			 * Rely on the __user accessors to reject bogus
+			 * pointers.
+			 */
+			base = extra_data;
+			if (!IS_ALIGNED((unsigned long)base, 16))
+				goto invalid;
+
+			/* Reject "unreasonably large" frames: */
+			limit = extra_size;
+			if (limit > SIGFRAME_MAXSZ - sizeof(sc->__reserved))
+				goto invalid;
+
+			/*
+			 * Ignore trailing terminator in __reserved[]
+			 * and start parsing extra_data:
+			 */
+			offset = 0;
+			continue;
+
 		default:
 			goto invalid;
 		}
Signature · 1 line
2.1.4
#6 lore raw

RFC PATCH 6/29 arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON

In reply to Dave Martin

The EFI runtime services ABI permits calls to EFI to clobber certain FPSIMD/NEON registers, as per the AArch64 procedure call standard.

Saving/restoring the clobbered registers around such calls needs KERNEL_MODE_NEON, but the dependency is missing from Kconfig.

This patch adds the missing dependency.

This will aid bisection of the patches implementing support for the ARM Scalable Vector Extension (SVE).

---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm64/Kconfig +1 -0
index 969ef88..d008bb6 100644
@@ -963,6 +963,7 @@ config EFI_STUB
 config EFI
 	bool "UEFI runtime support"
 	depends on OF && !CPU_BIG_ENDIAN
+	depends on KERNEL_MODE_NEON
 	select LIBFDT
 	select UCS2_STRING
 	select EFI_PARAMS_FROM_FDT
Signature · 1 line
2.1.4
#7 lore raw

RFC PATCH 6/29 arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON

Quoted 7 lines · Dave Martin

The EFI runtime services ABI permits calls to EFI to clobber certain FPSIMD/NEON registers, as per the AArch64 procedure call standard.

Saving/restoring the clobbered registers around such calls needs KERNEL_MODE_NEON, but the dependency is missing from Kconfig.

Quoted 6 lines

This patch adds the missing dependency.

This will aid bisection of the patches implementing support for the ARM Scalable Vector Extension (SVE).

Quoted 19 lines
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm64/Kconfig +1 -1
index 969ef88..d008bb6 100644
@@ -963,6 +963,7 @@ config EFI_STUB
 config EFI
        bool "UEFI runtime support"
        depends on OF && !CPU_BIG_ENDIAN
+       depends on KERNEL_MODE_NEON
        select LIBFDT
        select UCS2_STRING
        select EFI_PARAMS_FROM_FDT
--

2.1.4

#8 lore raw

RFC PATCH 7/29 arm64/sve: Allow kernel-mode NEON to be disabled in Kconfig

In reply to Dave Martin

Currently, support for kernel-mode NEON alongside the Scalable Vector Extension doesn't work, so allow KERNEL_MODE_NEON to be disabled.

This is only needed for bisectability of the SVE patches and will be removed later.

---
 arch/arm64/Kconfig | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
arch/arm64/Kconfig +4 -3
index d008bb6..1bdcaf1 100644
@@ -223,9 +223,6 @@ config SWIOTLB
 config IOMMU_HELPER
 	def_bool SWIOTLB
 
-config KERNEL_MODE_NEON
-	def_bool y
-
 config FIX_EARLYCON_MEM
 	def_bool y
 
@@ -268,6 +265,10 @@ endmenu
 
 menu "Kernel Features"
 
+config KERNEL_MODE_NEON
+	bool "Support NEON/FPSIMD code in the kernel"
+	default y
+
 menu "ARM errata workarounds via the alternatives framework"
 
 config ARM64_ERRATUM_826319
Signature · 1 line
2.1.4
#9 lore raw

RFC PATCH 8/29 arm64/sve: Low-level save/restore code

In reply to Dave Martin

This patch adds low-level save/restore for the Scalable Vector Extension.

This is helper code only, and is not used for anything yet.

---
 arch/arm64/Kconfig                    |  12 +++
 arch/arm64/include/asm/fpsimd.h       |   3 +
 arch/arm64/include/asm/fpsimdmacros.h | 145 ++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/entry-fpsimd.S      |  17 ++++
 4 files changed, 177 insertions(+)
arch/arm64/Kconfig +12 -0
index 1bdcaf1..cd6c846 100644
@@ -876,6 +876,18 @@ config ARM64_UAO
 
 endmenu
 
+config ARM64_SVE
+	bool "ARM Scalable Vector Extension support"
+	default y
+	depends on !KERNEL_MODE_NEON	# until it works with SVE
+	help
+	  The Scalable Vector Extension (SVE) is an extension to the AArch64
+	  execution state which complements and extends the SIMD functionality
+	  of the base architecture to support much larger vectors and to enable
+	  additional vectorisation opportunities.
+
+	  To enable use of this extension on CPUs that implement it, say Y.
+
 config ARM64_MODULE_CMODEL_LARGE
 	bool
 
arch/arm64/include/asm/fpsimd.h +3 -0
index 50f559f..92f45ee 100644
@@ -81,6 +81,9 @@ extern void fpsimd_save_partial_state(struct fpsimd_partial_state *state,
 				      u32 num_regs);
 extern void fpsimd_load_partial_state(struct fpsimd_partial_state *state);
 
+extern void sve_save_state(void *state, u32 *pfpsr);
+extern void sve_load_state(void const *state, u32 const *pfpsr);
+
 #endif
 
 #endif
arch/arm64/include/asm/fpsimdmacros.h +145 -0

148 lines not on this page · raw message

arch/arm64/kernel/entry-fpsimd.S +17 -0
index c44a82f..5dcec55 100644
@@ -65,3 +65,20 @@ ENTRY(fpsimd_load_partial_state)
 ENDPROC(fpsimd_load_partial_state)
 
 #endif
+
+#ifdef CONFIG_ARM64_SVE
+ENTRY(sve_save_state)
+	sve_save 0, x1, 2
+	ret
+ENDPROC(sve_save_state)
+
+ENTRY(sve_load_state)
+	sve_load 0, x1, 2
+	ret
+ENDPROC(sve_load_state)
+
+ENTRY(sve_get_vl)
+	_zrdvl	0, 1
+	ret
+ENDPROC(sve_get_vl)
+#endif /* CONFIG_ARM64_SVE */
Signature · 1 line
2.1.4
#10 lore raw

RFC PATCH 9/29 arm64/sve: Boot-time feature detection and reporting

In reply to Dave Martin

This patch adds feature detection for the ARM Scalable Vector Extension, and adds basic informative feature reporting via /proc/cpuinfo.

---
 arch/arm64/include/asm/sysreg.h     | 1 +
 arch/arm64/include/uapi/asm/hwcap.h | 1 +
 arch/arm64/kernel/cpufeature.c      | 3 +++
 arch/arm64/kernel/cpuinfo.c         | 1 +
 4 files changed, 6 insertions(+)
arch/arm64/include/asm/sysreg.h +1 -0
index 6c80b36..ccce9ad 100644
@@ -113,6 +113,7 @@
 #define ID_AA64ISAR0_AES_SHIFT		4
 
 /* id_aa64pfr0 */
+#define ID_AA64PFR0_SVE_SHIFT		32
 #define ID_AA64PFR0_GIC_SHIFT		24
 #define ID_AA64PFR0_ASIMD_SHIFT		20
 #define ID_AA64PFR0_FP_SHIFT		16
arch/arm64/include/uapi/asm/hwcap.h +1 -0
index a739287..f0de828 100644
@@ -30,5 +30,6 @@
 #define HWCAP_ATOMICS		(1 << 8)
 #define HWCAP_FPHP		(1 << 9)
 #define HWCAP_ASIMDHP		(1 << 10)
+#define HWCAP_SVE		(1 << 11)
 
 #endif /* _UAPI__ASM_HWCAP_H */
arch/arm64/kernel/cpufeature.c +3 -0
index c02504e..5126288 100644
@@ -856,6 +856,9 @@ static const struct arm64_cpu_capabilities arm64_elf_hwcaps[] = {
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
 	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_ASIMDHP),
+#ifdef CONFIG_ARM64_SVE
+	HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_SVE_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SVE),
+#endif
 	{},
 };
 
arch/arm64/kernel/cpuinfo.c +1 -0
index b3d5b3e..53e9fe2 100644
@@ -63,6 +63,7 @@ static const char *const hwcap_str[] = {
 	"atomics",
 	"fphp",
 	"asimdhp",
+	"sve",
 	NULL
 };
 
Signature · 1 line
2.1.4
#11 lore raw

RFC PATCH 10/29 arm64/sve: Boot-time feature enablement

In reply to Dave Martin

This patch enables Scalable Vector Extension access for the kernel on boot.

---
 arch/arm64/include/asm/kvm_arm.h |  1 +
 arch/arm64/include/asm/sysreg.h  | 10 ++++++++++
 arch/arm64/kernel/head.S         | 16 +++++++++++++++-
 arch/arm64/mm/proc.S             | 22 +++++++++++++++++++++-
 4 files changed, 47 insertions(+), 2 deletions(-)
arch/arm64/include/asm/kvm_arm.h +1 -0
index 2a2752b..ae7afb2 100644
@@ -185,6 +185,7 @@
 #define CPTR_EL2_TCPAC	(1 << 31)
 #define CPTR_EL2_TTA	(1 << 20)
 #define CPTR_EL2_TFP	(1 << CPTR_EL2_TFP_SHIFT)
+#define CPTR_EL2_TZ	(1 << 8)
 #define CPTR_EL2_DEFAULT	0x000033ff
 
 /* Hyp Debug Configuration Register bits */
arch/arm64/include/asm/sysreg.h +10 -0
index ccce9ad..09a44b3 100644
@@ -302,4 +302,14 @@ static inline void config_sctlr_el1(u32 clear, u32 set)
 
 #endif
 
+#define ZIDR_EL1	sys_reg(3, 0, 0, 0, 7)
+#define ZCR_EL1		sys_reg(3, 0, 1, 2, 0)
+#define ZCR_EL2		sys_reg(3, 4, 1, 2, 0)
+
+#define ZCR_EL1_LEN_MASK	0x1ff
+
+#define CPACR_EL1_ZEN_EL1EN	(1 << 16)
+#define CPACR_EL1_ZEN_EL0EN	(1 << 17)
+#define CPACR_EL1_ZEN		(CPACR_EL1_ZEN_EL1EN | CPACR_EL1_ZEN_EL0EN)
+
 #endif	/* __ASM_SYSREG_H */
arch/arm64/kernel/head.S +15 -1
index 332e331..ae4448f 100644
@@ -572,9 +572,23 @@ CPU_LE(	movk	x0, #0x30d0, lsl #16	)	// Clear EE and E0E on LE systems
 
 	/* Coprocessor traps. */
 	mov	x0, #0x33ff
+
+	/* SVE register access */
+	mrs	x1, id_aa64pfr0_el1
+	ubfx	x1, x1, #ID_AA64PFR0_SVE_SHIFT, #4
+	cbz	x1, 4f
+
+	bic	x0, x0, #CPTR_EL2_TZ		// Disable SVE traps to EL2
 	msr	cptr_el2, x0			// Disable copro. traps to EL2
-1:
+	isb
+
+	mrs_s	x1, ZIDR_EL1			// Scalable Vector Extension:
+	and	x1, x1, #ZCR_EL1_LEN_MASK	// Enable full vector length
+	msr_s	ZCR_EL2, x1			// for EL1.
+	b	1f
 
+4:	msr	cptr_el2, x0			// Disable copro. traps to EL2
+1:
 #ifdef CONFIG_COMPAT
 	msr	hstr_el2, xzr			// Disable CP15 traps to EL2
 #endif
arch/arm64/mm/proc.S +21 -1
index 352c73b..1da8160 100644
@@ -27,6 +27,7 @@
 #include <asm/pgtable-hwdef.h>
 #include <asm/cpufeature.h>
 #include <asm/alternative.h>
+#include <asm/sysreg.h>
 
 #ifdef CONFIG_ARM64_64K_PAGES
 #define TCR_TG_FLAGS	TCR_TG0_64K | TCR_TG1_64K
@@ -184,12 +185,31 @@ ENTRY(__cpu_setup)
 	dsb	nsh
 
 	mov	x0, #3 << 20
+
+	/* SVE */
+	mrs	x5, id_aa64pfr0_el1
+	ubfx	x5, x5, #ID_AA64PFR0_SVE_SHIFT, #4
+	cbz	x5, 1f
+
+	bic	x0, x0, #CPACR_EL1_ZEN
+	orr	x0, x0, #CPACR_EL1_ZEN_EL1EN	// SVE: trap for EL0, not EL1
 	msr	cpacr_el1, x0			// Enable FP/ASIMD
-	mov	x0, #1 << 12			// Reset mdscr_el1 and disable
+	isb
+
+	mrs_s	x5, ZIDR_EL1			// SVE: Enable full vector len
+	and	x5, x5, #ZCR_EL1_LEN_MASK	// initially
+	msr_s	ZCR_EL1, x5
+
+	b	2f
+
+1:	msr	cpacr_el1, x0			// Enable FP/ASIMD
+
+2:	mov	x0, #1 << 12			// Reset mdscr_el1 and disable
 	msr	mdscr_el1, x0			// access to the DCC from EL0
 	isb					// Unmask debug exceptions now,
 	enable_dbg				// since this is per-cpu
 	reset_pmuserenr_el0 x0			// Disable PMU access from EL0
+
 	/*
 	 * Memory region attributes for LPAE:
 	 *
Signature · 1 line
2.1.4
#12 lore raw

RFC PATCH 11/29 arm64/sve: Expand task_struct for Scalable Vector Extension state

In reply to Dave Martin

This patch expands task_struct to accommodate the Scalable Vector Extension state.

The extra space is not used for anything yet.

---
 arch/arm64/Kconfig              |  1 +
 arch/arm64/include/asm/fpsimd.h | 12 +++++++
 arch/arm64/kernel/fpsimd.c      | 71 ++++++++++++++++++++++++++++++++++++++++-
 arch/arm64/kernel/process.c     |  2 +-
 arch/arm64/kernel/setup.c       |  3 ++
 5 files changed, 87 insertions(+), 2 deletions(-)
arch/arm64/Kconfig +1 -0
index cd6c846..e8d04dd 100644
@@ -19,6 +19,7 @@ config ARM64
 	select ARCH_SUPPORTS_NUMA_BALANCING
 	select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
 	select ARCH_WANT_FRAME_POINTERS
+	select ARCH_WANTS_DYNAMIC_TASK_STRUCT
 	select ARCH_HAS_UBSAN_SANITIZE_ALL
 	select ARM_AMBA
 	select ARM_ARCH_TIMER
arch/arm64/include/asm/fpsimd.h +12 -0
index 92f45ee..1c41259 100644
@@ -51,6 +51,15 @@ struct fpsimd_partial_state {
 	__uint128_t	vregs[32];
 };
 
+/*
+ * Scalable Vector Extension state structure template.
+ * The layout is vector length dependent, with vector length = vl * 16 bytes.
+ */
+#define fpsimd_sve_state(vl) {		\
+	__uint128_t	zregs[32][vl];		\
+	u16		pregs[16][vl];		\
+	u16		ffr[vl];		\
+}
 
 #if defined(__KERNEL__) && defined(CONFIG_COMPAT)
 /* Masks for extracting the FPSR and FPCR from the FPSCR */
@@ -81,8 +90,11 @@ extern void fpsimd_save_partial_state(struct fpsimd_partial_state *state,
 				      u32 num_regs);
 extern void fpsimd_load_partial_state(struct fpsimd_partial_state *state);
 
+extern void __init fpsimd_init_task_struct_size(void);
+
 extern void sve_save_state(void *state, u32 *pfpsr);
 extern void sve_load_state(void const *state, u32 const *pfpsr);
+extern unsigned int sve_get_vl(void);
 
 #endif
 
arch/arm64/kernel/fpsimd.c +70 -1

96 lines not on this page · raw message

arch/arm64/kernel/process.c +1 -1
index 01753cd..7e19c3c 100644
@@ -242,7 +242,7 @@ int arch_dup_task_struct(struct task_struct *dst, struct task_struct *src)
 {
 	if (current->mm)
 		fpsimd_preserve_current_state();
-	*dst = *src;
+	memcpy(dst, src, arch_task_struct_size);
 	return 0;
 }
 
arch/arm64/kernel/setup.c +3 -0
index f534f49..f0f551e 100644
@@ -234,6 +234,9 @@ void __init setup_arch(char **cmdline_p)
 	pr_info("Boot CPU: AArch64 Processor [%08x]\n", read_cpuid_id());
 
 	sprintf(init_utsname()->machine, UTS_MACHINE);
+
+	fpsimd_init_task_struct_size();
+
 	init_mm.start_code = (unsigned long) _text;
 	init_mm.end_code   = (unsigned long) _etext;
 	init_mm.end_data   = (unsigned long) _edata;
Signature · 1 line
2.1.4
#13 lore raw

RFC PATCH 12/29 arm64/sve: Save/restore SVE state on context switch paths

In reply to Dave Martin

This patch implements basic handling of the Scalable Vector Extension state on the primary context switch paths.

This does *not* (correctly) handle the signal path, and doesn't do save/restore for SVE-only accesses that don't affect the FPSIMD state (i.e., FFR).

---
 arch/arm64/kernel/fpsimd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
arch/arm64/kernel/fpsimd.c +4 -4
index 05eca45..81cfdb5 100644
@@ -175,7 +175,7 @@ void fpsimd_thread_switch(struct task_struct *next)
 	 * 'current'.
 	 */
 	if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
-		fpsimd_save_state(&current->thread.fpsimd_state);
+		task_fpsimd_save(current);
 
 	if (next->mm) {
 		/*
@@ -224,7 +224,7 @@ void fpsimd_preserve_current_state(void)
 {
 	preempt_disable();
 	if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
-		fpsimd_save_state(&current->thread.fpsimd_state);
+		task_fpsimd_save(current);
 	preempt_enable();
 }
 
@@ -239,7 +239,7 @@ void fpsimd_restore_current_state(void)
 	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
 		struct fpsimd_state *st = &current->thread.fpsimd_state;
 
-		fpsimd_load_state(st);
+		task_fpsimd_load(current);
 		this_cpu_write(fpsimd_last_state, st);
 		st->cpu = smp_processor_id();
 	}
@@ -325,7 +325,7 @@ static int fpsimd_cpu_pm_notifier(struct notifier_block *self,
 	switch (cmd) {
 	case CPU_PM_ENTER:
 		if (current->mm && !test_thread_flag(TIF_FOREIGN_FPSTATE))
-			fpsimd_save_state(&current->thread.fpsimd_state);
+			task_fpsimd_save(current);
 		this_cpu_write(fpsimd_last_state, NULL);
 		break;
 	case CPU_PM_EXIT:
Signature · 1 line
2.1.4
#14 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

In reply to Dave Martin

In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on it to be configured together with Scalable Vector Extension support in the same kernel, this patch implements basic support for saving/restoring the SVE state around kernel_neon_begin()... kernel_neon_end().

This patch is not optimal and will generally save more state than necessary, more often than necessary. Further optimisations can be implemented in future patches.

This patch is not intended to allow general-purpose _SVE_ code to execute in the kernel safely. That functionality may also follow in later patches.

---
 arch/arm64/Kconfig         |  1 -
 arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
 2 files changed, 18 insertions(+), 5 deletions(-)
arch/arm64/Kconfig +0 -1
index e8d04dd..7266761 100644
@@ -880,7 +880,6 @@ endmenu
 config ARM64_SVE
 	bool "ARM Scalable Vector Extension support"
 	default y
-	depends on !KERNEL_MODE_NEON	# until it works with SVE
 	help
 	  The Scalable Vector Extension (SVE) is an extension to the AArch64
 	  execution state which complements and extends the SIMD functionality
arch/arm64/kernel/fpsimd.c +18 -4
index 81cfdb5..cb947dd 100644
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+	preempt_disable();
+
+	/*
+	 * For now, we have no special storage for SVE registers in
+	 * interrupt context, so always save the userland SVE state
+	 * if there is any, even for interrupts.
+	 */
+	if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+	    current->mm &&
+	    !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+		fpsimd_save_state(&current->thread.fpsimd_state);
+		this_cpu_write(fpsimd_last_state, NULL);
+	}
+
 	if (in_interrupt()) {
 		struct fpsimd_partial_state *s = this_cpu_ptr(
 			in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
-
 		BUG_ON(num_regs > 32);
+
+		/* Save partial state for interrupted kernel-mode NEON code: */
 		fpsimd_save_partial_state(s, roundup(num_regs, 2));
 	} else {
 		/*
@@ -295,7 +310,6 @@ void kernel_neon_begin_partial(u32 num_regs)
 		 * that there is no longer userland FPSIMD state in the
 		 * registers.
 		 */
-		preempt_disable();
 		if (current->mm &&
 		    !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
 			fpsimd_save_state(&current->thread.fpsimd_state);
@@ -310,9 +324,9 @@ void kernel_neon_end(void)
 		struct fpsimd_partial_state *s = this_cpu_ptr(
 			in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
 		fpsimd_load_partial_state(s);
-	} else {
-		preempt_enable();
 	}
+
+	preempt_enable();
 }
 EXPORT_SYMBOL(kernel_neon_end);
 
Signature · 1 line
2.1.4
#15 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 44 lines · Dave Martin

In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on it to be configured together with Scalable Vector Extension support in the same kernel, this patch implements basic support for saving/restoring the SVE state around kernel_neon_begin()... kernel_neon_end().

This patch is not optimal and will generally save more state than necessary, more often than necessary. Further optimisations can be implemented in future patches.

This patch is not intended to allow general-purpose _SVE_ code to execute in the kernel safely. That functionality may also follow in later patches.

---
 arch/arm64/Kconfig         |  1 -
 arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
 2 files changed, 18 insertions(+), 5 deletions(-)
arch/arm64/Kconfig +0 -1
index e8d04dd..7266761 100644
@@ -880,7 +880,6 @@ endmenu
 config ARM64_SVE
        bool "ARM Scalable Vector Extension support"
        default y
-       depends on !KERNEL_MODE_NEON    # until it works with SVE
        help
          The Scalable Vector Extension (SVE) is an extension to the AArch64
          execution state which complements and extends the SIMD functionality
arch/arm64/kernel/fpsimd.c +4 -0
index 81cfdb5..cb947dd 100644
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 10 lines
arch/arm64/kernel/fpsimd.c +10 -0
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Quoted 33 lines
arch/arm64/kernel/fpsimd.c +4 -5
        if (in_interrupt()) {
                struct fpsimd_partial_state *s = this_cpu_ptr(
                        in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
-
                BUG_ON(num_regs > 32);
+
+               /* Save partial state for interrupted kernel-mode NEON code: */
                fpsimd_save_partial_state(s, roundup(num_regs, 2));
        } else {
                /*
@@ -295,7 +310,6 @@ void kernel_neon_begin_partial(u32 num_regs)
                 * that there is no longer userland FPSIMD state in the
                 * registers.
                 */
-               preempt_disable();
                if (current->mm &&
                    !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
                        fpsimd_save_state(&current->thread.fpsimd_state);
@@ -310,9 +324,9 @@ void kernel_neon_end(void)
                struct fpsimd_partial_state *s = this_cpu_ptr(
                        in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
                fpsimd_load_partial_state(s);
-       } else {
-               preempt_enable();
        }
+
+       preempt_enable();
 }
 EXPORT_SYMBOL(kernel_neon_end);
 
--

2.1.4

maintainer
#16 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 50 lines · Ard Biesheuvel
Quoted 49 lines · Dave Martin

In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on it to be configured together with Scalable Vector Extension support in the same kernel, this patch implements basic support for saving/restoring the SVE state around kernel_neon_begin()... kernel_neon_end().

This patch is not optimal and will generally save more state than necessary, more often than necessary. Further optimisations can be implemented in future patches.

This patch is not intended to allow general-purpose _SVE_ code to execute in the kernel safely. That functionality may also follow in later patches.

---
 arch/arm64/Kconfig         |  1 -
 arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
 2 files changed, 18 insertions(+), 5 deletions(-)
arch/arm64/Kconfig +0 -1
index e8d04dd..7266761 100644
@@ -880,7 +880,6 @@ endmenu
 config ARM64_SVE
        bool "ARM Scalable Vector Extension support"
        default y
-       depends on !KERNEL_MODE_NEON    # until it works with SVE
        help
          The Scalable Vector Extension (SVE) is an extension to the AArch64
          execution state which complements and extends the SIMD functionality
arch/arm64/kernel/fpsimd.c +9 -0
index 81cfdb5..cb947dd 100644
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
Quoted 8 lines

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 5 lines
arch/arm64/kernel/fpsimd.c +5 -0
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Dave knows all the details but a reason is that touching a Neon register zeros the upper SVE state in the same vector register. So we can't safely save/restore just the Neon part without corrupting the SVE state.

Signature · 1 line
Catalin
#17 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 60 lines · Catalin Marinas
Quoted 50 lines · Ard Biesheuvel
Quoted 49 lines · Dave Martin

In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on it to be configured together with Scalable Vector Extension support in the same kernel, this patch implements basic support for saving/restoring the SVE state around kernel_neon_begin()... kernel_neon_end().

This patch is not optimal and will generally save more state than necessary, more often than necessary. Further optimisations can be implemented in future patches.

This patch is not intended to allow general-purpose _SVE_ code to execute in the kernel safely. That functionality may also follow in later patches.

---
 arch/arm64/Kconfig         |  1 -
 arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
 2 files changed, 18 insertions(+), 5 deletions(-)
arch/arm64/Kconfig +0 -1
index e8d04dd..7266761 100644
@@ -880,7 +880,6 @@ endmenu
 config ARM64_SVE
        bool "ARM Scalable Vector Extension support"
        default y
-       depends on !KERNEL_MODE_NEON    # until it works with SVE
        help
          The Scalable Vector Extension (SVE) is an extension to the AArch64
          execution state which complements and extends the SIMD functionality
arch/arm64/kernel/fpsimd.c +9 -0
index 81cfdb5..cb947dd 100644
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
Quoted 8 lines

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 5 lines
arch/arm64/kernel/fpsimd.c +5 -0
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Quoted 3 lines

Dave knows all the details but a reason is that touching a Neon register zeros the upper SVE state in the same vector register. So we can't safely save/restore just the Neon part without corrupting the SVE state.

This is right -- this also means that EFI services can trash the upper bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).

It's overkill to save/restore absolutely everything -- I ignore num_regs for example -- but I wanted to keep things as simple as possible initially.

Cheers
---Dave

maintainer
#18 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 31 lines · Dave P Martin
Quoted 26 lines · Catalin Marinas
Quoted 16 lines · Ard Biesheuvel
Quoted 15 lines · Dave Martin
arch/arm64/kernel/fpsimd.c +9 -0
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
Quoted 8 lines

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 5 lines
arch/arm64/kernel/fpsimd.c +5 -0
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Quoted 3 lines

Dave knows all the details but a reason is that touching a Neon register zeros the upper SVE state in the same vector register. So we can't safely save/restore just the Neon part without corrupting the SVE state.

Quoted 6 lines

This is right -- this also means that EFI services can trash the upper bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).

It's overkill to save/restore absolutely everything -- I ignore num_regs for example -- but I wanted to keep things as simple as possible initially.

Without looking at your patches in detail, could we mandate in the ABI that the SVE state is lost on the user/kernel syscall boundary? I guess even for the PCS, the SVE state is caller-saved, so there shouldn't be an additional cost to user. On interrupts, however, we'd have to preserve the SVE state but if we do this on entry/exit points, the kernel_neon_*() functions would not have to deal with any SVE state (and even ignore it completely if in interrupt).

BTW, we will need an SVE ABI document in Documentation/arm64/ to specify the requirements for syscall and sigcontext modifications.

Signature · 1 line
Catalin
#19 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 39 lines · Catalin Marinas
Quoted 31 lines · Dave P Martin
Quoted 26 lines · Catalin Marinas
Quoted 16 lines · Ard Biesheuvel
Quoted 15 lines · Dave Martin
arch/arm64/kernel/fpsimd.c +9 -0
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
Quoted 8 lines

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 5 lines
arch/arm64/kernel/fpsimd.c +5 -0
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Quoted 3 lines

Dave knows all the details but a reason is that touching a Neon register zeros the upper SVE state in the same vector register. So we can't safely save/restore just the Neon part without corrupting the SVE state.

Quoted 6 lines

This is right -- this also means that EFI services can trash the upper bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).

It's overkill to save/restore absolutely everything -- I ignore num_regs for example -- but I wanted to keep things as simple as possible initially.

Quoted 7 lines

Without looking at your patches in detail, could we mandate in the ABI that the SVE state is lost on the user/kernel syscall boundary? I guess even for the PCS, the SVE state is caller-saved, so there shouldn't be an additional cost to user. On interrupts, however, we'd have to preserve the SVE state but if we do this on entry/exit points, the kernel_neon_*() functions would not have to deal with any SVE state (and even ignore it completely if in interrupt).

See [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call.

Currently, kernel_neon_begin_partial() doesn't take advandage of this -- discarding the state is deferred until sched-out, and anyway I don't check for TIF_SVE in kernel_neon_begin_partial(). There's definitely some room for improvement.

Quoted 1 line

the requirements for syscall and sigcontext modifications.

Agreed -- I wanted to get this series posted so skipped that for now, but I plan to include a Documentation patch alongside the final series.

Cheers
---Dave

#20 lore raw

RFC PATCH 13/29 arm64/sve: Basic support for KERNEL_MODE_NEON

Quoted 33 lines · Dave Martin
Quoted 32 lines · Catalin Marinas
Quoted 31 lines · Dave P Martin
Quoted 29 lines · Catalin Marinas
Quoted 16 lines · Ard Biesheuvel
Quoted 15 lines · Dave Martin
arch/arm64/kernel/fpsimd.c +9 -0
@@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
  */
 void kernel_neon_begin_partial(u32 num_regs)
 {
+       preempt_disable();
+
+       /*
+        * For now, we have no special storage for SVE registers in
+        * interrupt context, so always save the userland SVE state
+        * if there is any, even for interrupts.
+        */
+       if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
+           current->mm &&
Quoted 8 lines

arch/arm64/kernel/fpsimd.c static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate); · line 298

Quoted 5 lines
arch/arm64/kernel/fpsimd.c +5 -0
+           !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
+               fpsimd_save_state(&current->thread.fpsimd_state);
+               this_cpu_write(fpsimd_last_state, NULL);
+       }
+

I am having trouble understanding why we need all of this if we don't support SVE in the kernel. Could you elaborate?

Dave knows all the details but a reason is that touching a Neon register zeros the upper SVE state in the same vector register. So we can't safely save/restore just the Neon part without corrupting the SVE state.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

This is right -- this also means that EFI services can trash the upper bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).

It's overkill to save/restore absolutely everything -- I ignore num_regs for example -- but I wanted to keep things as simple as possible initially.

Actually, I think we could simplify this even further by always preserving the userland state, instead of having two copies of the statements above. The reason is that stacking and unstacking, as we do for softirq/hardirq context, is only required if we happen to be interrupting a thread while it is executing in the kernel *and* using the NEON, in all other cases we can simply preserve the userland context, and let the exit code take care of restoring the state upon exit to userland (unless we're interrupting kernel mode NEON executing in softirq context from an interrupt handler).

i will send out a separate RFC with a proposal to optimize this, which I think will remove the need for this patch entirely.

#21 lore raw

RFC PATCH 14/29 Revert "arm64/sve: Allow kernel-mode NEON to be disabled in Kconfig"

In reply to Dave Martin

Now that KERNEL_MODE_NEON works for SVE, we can just default it back to y.

---
 arch/arm64/Kconfig | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
arch/arm64/Kconfig +3 -4
index 7266761..bf9915cb 100644
@@ -224,6 +224,9 @@ config SWIOTLB
 config IOMMU_HELPER
 	def_bool SWIOTLB
 
+config KERNEL_MODE_NEON
+	def_bool y
+
 config FIX_EARLYCON_MEM
 	def_bool y
 
@@ -266,10 +269,6 @@ endmenu
 
 menu "Kernel Features"
 
-config KERNEL_MODE_NEON
-	bool "Support NEON/FPSIMD code in the kernel"
-	default y
-
 menu "ARM errata workarounds via the alternatives framework"
 
 config ARM64_ERRATUM_826319
Signature · 1 line
2.1.4
#22 lore raw

RFC PATCH 15/29 arm64/sve: Restore working FPSIMD save/restore around signals

In reply to Dave Martin

Because fpsimd_state and the SVE state are not magically synchronised in the task_struct, stale FPSIMD data may be saved on signal handler entry, and restored data my be lost on sigreturn.

This patch converts between SVE and FPSIMD views around the signal, restoring working FPSIMD save/restore.

This will not save/restore the SVE state properly, but it should restore a working FPSIMD ABI.

---
 arch/arm64/include/asm/fpsimd.h |  1 +
 arch/arm64/kernel/fpsimd.c      | 92 ++++++++++++++++++++++++++++++++++++++++-
 arch/arm64/kernel/signal.c      |  2 +-
 arch/arm64/kernel/signal32.c    |  2 +-
 4 files changed, 94 insertions(+), 3 deletions(-)
arch/arm64/include/asm/fpsimd.h +1 -0
index 1c41259..aa82b38 100644
@@ -80,6 +80,7 @@ extern void fpsimd_load_state(struct fpsimd_state *state);
 extern void fpsimd_thread_switch(struct task_struct *next);
 extern void fpsimd_flush_thread(void);
 
+extern void fpsimd_signal_preserve_current_state(void);
 extern void fpsimd_preserve_current_state(void);
 extern void fpsimd_restore_current_state(void);
 extern void fpsimd_update_current_state(struct fpsimd_state *state);
arch/arm64/kernel/fpsimd.c +91 -1

116 lines not on this page · raw message

arch/arm64/kernel/signal.c +1 -1
index c7175a3..1e430b4 100644
@@ -168,7 +168,7 @@ static int preserve_fpsimd_context(struct fpsimd_context __user *ctx)
 	int err;
 
 	/* dump the hardware registers to the fpsimd_state structure */
-	fpsimd_preserve_current_state();
+	fpsimd_signal_preserve_current_state();
 
 	/* copy the FP and status/control registers */
 	err = __copy_to_user(ctx->vregs, fpsimd->vregs, sizeof(fpsimd->vregs));
arch/arm64/kernel/signal32.c +1 -1
index b7063de..08ca0dd 100644
@@ -244,7 +244,7 @@ static int compat_preserve_vfp_context(struct compat_vfp_sigframe __user *frame)
 	 * Note that this also saves V16-31, which aren't visible
 	 * in AArch32.
 	 */
-	fpsimd_preserve_current_state();
+	fpsimd_signal_preserve_current_state();
 
 	/* Place structure header on the stack */
 	__put_user_error(magic, &frame->magic, err);
Signature · 1 line
2.1.4
#23 lore raw

RFC PATCH 16/29 arm64/sve: signal: Add SVE state record to sigcontext

In reply to Dave Martin

This patch adds a record to sigcontext that will contain the SVE state.

Subsequent patches will implement the actual register dumping.

---
 arch/arm64/include/uapi/asm/sigcontext.h | 86 ++++++++++++++++++++++++++++++++
 arch/arm64/kernel/signal.c               | 62 +++++++++++++++++++++++
 2 files changed, 148 insertions(+)
arch/arm64/include/uapi/asm/sigcontext.h +86 -0
index 1af8437..11c915d 100644
@@ -88,4 +88,90 @@ struct extra_context {
 	__u32 size;	/* size in bytes of the extra space */
 };
 
+#define SVE_MAGIC	0x53564501
+
+struct sve_context {
+	struct _aarch64_ctx head;
+	__u16 vl;
+	__u16 __reserved[3];
+};
+
+/*
+ * The SVE architecture leaves space for future expansion of the
+ * vector length beyond its initial architectural limit of 2048 bits
+ * (16 quadwords).
+ */
+#define SVE_VQ_MIN		1
+#define SVE_VQ_MAX		0x200
+
+#define SVE_VL_MIN		(SVE_VQ_MIN * 0x10)
+#define SVE_VL_MAX		(SVE_VQ_MAX * 0x10)
+
+#define SVE_NUM_ZREGS		32
+#define SVE_NUM_PREGS		16
+
+#define sve_vl_valid(vl) \
+	((vl) % 0x10 == 0 && (vl) >= SVE_VL_MIN && (vl) <= SVE_VL_MAX)
+#define sve_vq_from_vl(vl)	((vl) / 0x10)
+
+/*
+ * The total size of meaningful data in the SVE context in bytes,
+ * including the header, is given by SVE_SIG_CONTEXT_SIZE(vq).
+ *
+ * Note: for all these macros, the "vq" argument denotes the SVE
+ * vector length in quadwords (i.e., units of 128 bits).
+ *
+ * The correct way to obtain vq is to use sve_vq_from_vl(vl).  The
+ * result is valid if and only if sve_vl_valid(vl) is true.  This is
+ * guaranteed for a struct sve_context written by the kernel.
+ *
+ *
+ * Additional macros describe the contents and layout of the payload.
+ * For each, SVE_SIG_x_OFFSET(args) is the start offset relative to
+ * the start of struct sve_context, and SVE_SIG_x_SIZE(args) is the
+ * size in bytes:
+ *
+ *	x	type				description
+ *	-	----				-----------
+ *	REGS					the entire SVE context
+ *
+ *	ZREGS	__uint128_t[SVE_NUM_ZREGS][vq]	all Z-registers
+ *	ZREG	__uint128_t[vq]			individual Z-register Zn
+ *
+ *	PREGS	uint16_t[SVE_NUM_PREGS][vq]	all P-registers
+ *	PREG	uint16_t[vq]			individual P-register Pn
+ *
+ *	FFR	uint16_t[vq]			first-fault status register
+ *
+ * Additional data might be appended in the future.
+ */
+
+#define SVE_SIG_ZREG_SIZE(vq)	((__u32)(vq) * 16)
+#define SVE_SIG_PREG_SIZE(vq)	((__u32)(vq) * 2)
+#define SVE_SIG_FFR_SIZE(vq)	SVE_SIG_PREG_SIZE(vq)
+
+#define SVE_SIG_REGS_OFFSET	((sizeof(struct sve_context) + 15) / 16 * 16)
+
+#define SVE_SIG_ZREGS_OFFSET	SVE_SIG_REGS_OFFSET
+#define SVE_SIG_ZREG_OFFSET(vq, n) \
+	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREG_SIZE(vq) * (n))
+#define SVE_SIG_ZREGS_SIZE(vq) \
+	(SVE_SIG_ZREG_OFFSET(vq, SVE_NUM_ZREGS) - SVE_SIG_ZREGS_OFFSET)
+
+#define SVE_SIG_PREGS_OFFSET(vq) \
+	(SVE_SIG_ZREGS_OFFSET + SVE_SIG_ZREGS_SIZE(vq))
+#define SVE_SIG_PREG_OFFSET(vq, n) \
+	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREG_SIZE(vq) * (n))
+#define SVE_SIG_PREGS_SIZE(vq) \
+	(SVE_SIG_PREG_OFFSET(vq, SVE_NUM_PREGS) - SVE_SIG_PREGS_OFFSET(vq))
+
+#define SVE_SIG_FFR_OFFSET(vq) \
+	(SVE_SIG_PREGS_OFFSET(vq) + SVE_SIG_PREGS_SIZE(vq))
+
+#define SVE_SIG_REGS_SIZE(vq) \
+	(SVE_SIG_FFR_OFFSET(vq) + SVE_SIG_FFR_SIZE(vq) - SVE_SIG_REGS_OFFSET)
+
+#define SVE_SIG_CONTEXT_SIZE(vq) (SVE_SIG_REGS_OFFSET + SVE_SIG_REGS_SIZE(vq))
+
+
 #endif /* _UAPI__ASM_SIGCONTEXT_H */
arch/arm64/kernel/signal.c +62 -0

100 lines not on this page · raw message

Signature · 1 line
2.1.4
#24 lore raw

RFC PATCH 17/29 arm64/sve: signal: Dump Scalable Vector Extension registers to user stack

In reply to Dave Martin

This patch populates the sve_regs() area reserved on the user stack with the actual register context.

---
 arch/arm64/include/asm/fpsimd.h | 1 +
 arch/arm64/kernel/fpsimd.c      | 5 ++---
 arch/arm64/kernel/signal.c      | 8 ++++++++
 3 files changed, 11 insertions(+), 3 deletions(-)
arch/arm64/include/asm/fpsimd.h +1 -0
index aa82b38..e39066a 100644
@@ -93,6 +93,7 @@ extern void fpsimd_load_partial_state(struct fpsimd_partial_state *state);
 
 extern void __init fpsimd_init_task_struct_size(void);
 
+extern void *__task_sve_state(struct task_struct *task);
 extern void sve_save_state(void *state, u32 *pfpsr);
 extern void sve_load_state(void const *state, u32 const *pfpsr);
 extern unsigned int sve_get_vl(void);
arch/arm64/kernel/fpsimd.c +2 -3
index 9a90921..4ef2e37 100644
@@ -128,7 +128,7 @@ void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
 
 #ifdef CONFIG_ARM64_SVE
 
-static void *__task_sve_state(struct task_struct *task)
+void *__task_sve_state(struct task_struct *task)
 {
 	return (char *)task + ALIGN(sizeof(*task), 16);
 }
@@ -143,8 +143,7 @@ static void *__task_pffr(struct task_struct *task)
 
 #else /* !CONFIG_ARM64_SVE */
 
-/* Turn any non-optimised out attempts to use these into a link error: */
-extern void *__task_sve_state(struct task_struct *task);
+/* Turn any non-optimised out attempts to use this into a link error: */
 extern void *__task_pffr(struct task_struct *task);
 
 #endif /* !CONFIG_ARM64_SVE */
arch/arm64/kernel/signal.c +8 -0
index 7418237..038e7338 100644
@@ -229,6 +229,14 @@ static int preserve_sve_context(struct sve_context __user *ctx)
 	BUILD_BUG_ON(sizeof(ctx->__reserved) != sizeof(reserved));
 	err |= copy_to_user(&ctx->__reserved, reserved, sizeof(reserved));
 
+	/*
+	 * This assumes that the SVE state has already been saved to
+	 * the task struct by calling preserve_fpsimd_context().
+	 */
+	err |= copy_to_user((char __user *)ctx + SVE_SIG_REGS_OFFSET,
+			    __task_sve_state(current),
+			    SVE_SIG_REGS_SIZE(vq));
+
 	return err ? -EFAULT : 0;
 }
 
Signature · 1 line
2.1.4
#25 lore raw

RFC PATCH 18/29 arm64/sve: signal: Restore FPSIMD/SVE state in rt_sigreturn

In reply to Dave Martin

This patch adds the missing logic to restore the SVE state in rt_sigreturn.

Because the FPSIMD and SVE state alias, this code replaces the existing fpsimd restore code when there is SVE state to restore.

For Zn[127:0], the saved FPSIMD state in Vn takes precedence.

Since __task_fpsimd_to_sve() is used to merge the FPSIMD and SVE state back together, and only for this purpose, we don't want it to zero out the SVE state -- hence delete the memset() from there.

---
 arch/arm64/kernel/fpsimd.c |  4 ---
 arch/arm64/kernel/signal.c | 87 ++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 76 insertions(+), 15 deletions(-)
arch/arm64/kernel/fpsimd.c +0 -4
index 4ef2e37..b1a8d3e 100644
@@ -266,9 +266,6 @@ static void task_sve_to_fpsimd(struct task_struct *task __always_unused) { }
 
 void fpsimd_signal_preserve_current_state(void)
 {
-	WARN_ONCE(elf_hwcap & HWCAP_SVE,
-		  "SVE state save/restore around signals doesn't work properly, expect userspace corruption!\n");
-
 	fpsimd_preserve_current_state();
 	task_sve_to_fpsimd(current);
 }
@@ -301,7 +298,6 @@ static void __task_fpsimd_to_sve(struct task_struct *task, unsigned int vq)
 	struct fpsimd_state *fst = &task->thread.fpsimd_state;
 	unsigned int i;
 
-	memset(sst, 0, sizeof(*sst));
 	for (i = 0; i < 32; ++i)
 		sst->zregs[i][0] = fst->vregs[i];
 }
arch/arm64/kernel/signal.c +76 -11

124 lines not on this page · raw message

Signature · 1 line
2.1.4
#26 lore raw

RFC PATCH 19/29 arm64/sve: Avoid corruption when replacing the SVE state

In reply to Dave Martin

If preemption occurs during replacement of the whole SVE state, as occurs during execve() or rt_sigreturn(), then some or all of the new state for the thread can be lost, due to erroneous saving of the pre-existing state over the new data.

This patch disables preemption around the affected operations to avoid this failure mode.

This should be reexamined later if the impact on preemption latency proves to be excessive.

---
 arch/arm64/kernel/fpsimd.c | 4 ++++
 arch/arm64/kernel/signal.c | 9 ++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)
arch/arm64/kernel/fpsimd.c +4 -0
index b1a8d3e..cda079e 100644
@@ -198,6 +198,8 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 void fpsimd_flush_thread(void)
 {
+	preempt_disable();
+
 	fpsimd_flush_task_state(current);
 
 	memset(&current->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
@@ -213,6 +215,8 @@ void fpsimd_flush_thread(void)
 	}
 
 	set_thread_flag(TIF_FOREIGN_FPSTATE);
+
+	preempt_enable();
 }
 
 /*
arch/arm64/kernel/signal.c +8 -1
index 2697d09..129b016 100644
@@ -256,6 +256,10 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 	if (vl != sve_get_vl())
 		return -EINVAL;
 
+	preempt_disable();
+
+	set_thread_flag(TIF_FOREIGN_FPSTATE);
+
 	BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
 	BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
 	BUG_ON(SVE_SIG_FFR_OFFSET(vq) - SVE_SIG_REGS_OFFSET !=
@@ -265,7 +269,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 					SVE_SIG_REGS_OFFSET,
 			       SVE_SIG_REGS_SIZE(vq));
 	if (err)
-		return err;
+		goto out_preempt;
 
 	/* copy the FP and status/control registers */
 	/* restore_sigframe() already checked that user->fpsimd != NULL. */
@@ -278,6 +282,9 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 	if (!err)
 		fpsimd_update_current_state(&fpsimd);
 
+out_preempt:
+	preempt_enable();
+
 	return err;
 }
 
Signature · 1 line
2.1.4
#27 lore raw

RFC PATCH 20/29 arm64/sve: traps: Add descriptive string for SVE exceptions

In reply to Dave Martin

In preparation for SVE trapping in userspace, let's print something relevant instead of "UNREGOCNIZED EC" when an unhandled SVE exception occurs.

---
 arch/arm64/include/asm/esr.h | 3 ++-
 arch/arm64/kernel/traps.c    | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)
arch/arm64/include/asm/esr.h +2 -1
index d14c478..87729f3 100644
@@ -42,7 +42,8 @@
 #define ESR_ELx_EC_HVC64	(0x16)
 #define ESR_ELx_EC_SMC64	(0x17)
 #define ESR_ELx_EC_SYS64	(0x18)
-/* Unallocated EC: 0x19 - 0x1E */
+#define ESR_ELx_EC_SVE		(0x19)
+/* Unallocated EC: 0x1A - 0x1E */
 #define ESR_ELx_EC_IMP_DEF	(0x1f)
 #define ESR_ELx_EC_IABT_LOW	(0x20)
 #define ESR_ELx_EC_IABT_CUR	(0x21)
arch/arm64/kernel/traps.c +1 -0
index c9986b3..aaab1dd 100644
@@ -569,6 +569,7 @@ static const char *esr_class_str[] = {
 	[ESR_ELx_EC_HVC64]		= "HVC (AArch64)",
 	[ESR_ELx_EC_SMC64]		= "SMC (AArch64)",
 	[ESR_ELx_EC_SYS64]		= "MSR/MRS (AArch64)",
+	[ESR_ELx_EC_SVE]		= "SVE",
 	[ESR_ELx_EC_IMP_DEF]		= "EL3 IMP DEF",
 	[ESR_ELx_EC_IABT_LOW]		= "IABT (lower EL)",
 	[ESR_ELx_EC_IABT_CUR]		= "IABT (current EL)",
Signature · 1 line
2.1.4
#28 lore raw

RFC PATCH 21/29 arm64/sve: Enable SVE on demand for userspace

In reply to Dave Martin

This patch tracks whether a task has ever attempted to use the Scalable Vector Extension. If and only if SVE is in use by a task, it will be enabled for userspace when scheduling the task in. For other tasks, SVE is disabled when scheduling in.

---
 arch/arm64/include/asm/thread_info.h |  1 +
 arch/arm64/kernel/entry.S            | 18 +++++++++++++++++-
 arch/arm64/kernel/fpsimd.c           | 30 ++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 1 deletion(-)
arch/arm64/include/asm/thread_info.h +1 -0
index e9ea5a6..2deac86 100644
@@ -117,6 +117,7 @@ static inline struct thread_info *current_thread_info(void)
 #define TIF_SYSCALL_AUDIT	9
 #define TIF_SYSCALL_TRACEPOINT	10
 #define TIF_SECCOMP		11
+#define TIF_SVE			17	/* Scalable Vector Extension in use */
 #define TIF_MEMDIE		18	/* is terminating due to OOM killer */
 #define TIF_FREEZE		19
 #define TIF_RESTORE_SIGMASK	20
arch/arm64/kernel/entry.S +17 -1
index 223d54a..fe20560 100644
@@ -465,6 +465,10 @@ el0_sync:
 	b.eq	el0_ia
 	cmp	x24, #ESR_ELx_EC_FP_ASIMD	// FP/ASIMD access
 	b.eq	el0_fpsimd_acc
+#ifdef CONFIG_ARM64_SVE
+	cmp	x24, #ESR_ELx_EC_SVE		// SVE access
+	b.eq	el0_sve_acc
+#endif
 	cmp	x24, #ESR_ELx_EC_FP_EXC64	// FP/ASIMD exception
 	b.eq	el0_fpsimd_exc
 	cmp	x24, #ESR_ELx_EC_SYS64		// configurable trap
@@ -563,9 +567,21 @@ el0_fpsimd_acc:
 	mov	x1, sp
 	bl	do_fpsimd_acc
 	b	ret_to_user
+#ifdef CONFIG_ARM64_SVE
+	/*
+	 * Scalable Vector Extension access
+	 */
+el0_sve_acc:
+	enable_dbg
+	ct_user_exit
+	mov	x0, x25
+	mov	x1, sp
+	bl	do_sve_acc
+	b	ret_to_user
+#endif
 el0_fpsimd_exc:
 	/*
-	 * Floating Point or Advanced SIMD exception
+	 * Floating Point, Advanced SIMD or SVE exception
 	 */
 	enable_dbg
 	ct_user_exit
arch/arm64/kernel/fpsimd.c +30 -0
index cda079e..40566a9 100644
@@ -99,6 +99,20 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
 	WARN_ON(1);
 }
 
+#ifdef CONFIG_ARM64_SVE
+void do_sve_acc(unsigned int esr, struct pt_regs *regs)
+{
+	unsigned long tmp;
+
+	if (test_and_set_thread_flag(TIF_SVE))
+		BUG();
+
+	asm ("mrs %0, cpacr_el1" : "=r" (tmp));
+	asm volatile ("msr cpacr_el1, %0" :: "r" (tmp | (1 << 17)));
+	/* Serialised by exception return to user */
+}
+#endif
+
 /*
  * Raise a SIGFPE for the current process.
  */
@@ -283,11 +297,27 @@ void fpsimd_restore_current_state(void)
 {
 	preempt_disable();
 	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
+		unsigned long tmp;
+		unsigned long flags;
+
 		struct fpsimd_state *st = &current->thread.fpsimd_state;
 
 		task_fpsimd_load(current);
 		this_cpu_write(fpsimd_last_state, st);
 		st->cpu = smp_processor_id();
+
+		if (IS_ENABLED(CONFIG_ARM64_SVE)) {
+			/*
+			 * Flip SVE enable for userspace if it doesn't
+			 * match the current_task.
+			 */
+			asm ("mrs %0, cpacr_el1" : "=r" (tmp));
+			flags = current_thread_info()->flags;
+			if ((tmp ^ (unsigned long)flags) & (1 << 17)) {
+				tmp ^= 1 << 17;
+				asm volatile ("msr cpacr_el1, %0" :: "r" (tmp));
+			}
+		}
 	}
 	preempt_enable();
 }
Signature · 1 line
2.1.4
#29 lore raw

RFC PATCH 22/29 arm64/sve: Implement FPSIMD-only context for tasks not using SVE

In reply to Dave Martin

To reduce unnecessary context switch overhead, we don't need to switch the whole SVE state for tasks that are not using it.

This patch restores the FPSIMD-only behaviour for tasks that have never used SVE.

Note that coredumps and ptrace may see FPSIMD/SVE out of sync at present -- this will be fixed later.

SVE state is saved on signal delivery only for tasks that have used SVE. However, it should be possible to add SVE state on return from a signal handler when the task didn't have any SVE state previously. The caller may need to add its own SVE record to the signal frame in this case.

---
 arch/arm64/kernel/fpsimd.c | 34 +++++++++++++++++++++++-----------
 arch/arm64/kernel/signal.c |  5 ++++-
 2 files changed, 27 insertions(+), 12 deletions(-)
arch/arm64/kernel/fpsimd.c +23 -11
index 40566a9..cad86e5 100644
@@ -100,6 +100,9 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
 }
 
 #ifdef CONFIG_ARM64_SVE
+
+static void task_fpsimd_to_sve(struct task_struct *task);
+
 void do_sve_acc(unsigned int esr, struct pt_regs *regs)
 {
 	unsigned long tmp;
@@ -107,11 +110,16 @@ void do_sve_acc(unsigned int esr, struct pt_regs *regs)
 	if (test_and_set_thread_flag(TIF_SVE))
 		BUG();
 
+	BUG_ON(is_compat_task());
+
+	task_fpsimd_to_sve(current);
+
 	asm ("mrs %0, cpacr_el1" : "=r" (tmp));
 	asm volatile ("msr cpacr_el1, %0" :: "r" (tmp | (1 << 17)));
 	/* Serialised by exception return to user */
 }
-#endif
+
+#endif /* CONFIG_ARM64_SVE */
 
 /*
  * Raise a SIGFPE for the current process.
@@ -164,7 +172,8 @@ extern void *__task_pffr(struct task_struct *task);
 
 static void task_fpsimd_load(struct task_struct *task)
 {
-	if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE))
+	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+	    test_tsk_thread_flag(task, TIF_SVE))
 		sve_load_state(__task_pffr(task),
 			       &task->thread.fpsimd_state.fpsr);
 	else
@@ -173,7 +182,8 @@ static void task_fpsimd_load(struct task_struct *task)
 
 static void task_fpsimd_save(struct task_struct *task)
 {
-	if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE))
+	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+	    test_tsk_thread_flag(task, TIF_SVE))
 		sve_save_state(__task_pffr(task),
 			       &task->thread.fpsimd_state.fpsr);
 	else
@@ -202,11 +212,9 @@ void fpsimd_thread_switch(struct task_struct *next)
 
 		if (__this_cpu_read(fpsimd_last_state) == st
 		    && st->cpu == smp_processor_id())
-			clear_ti_thread_flag(task_thread_info(next),
-					     TIF_FOREIGN_FPSTATE);
+			clear_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
 		else
-			set_ti_thread_flag(task_thread_info(next),
-					   TIF_FOREIGN_FPSTATE);
+			set_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE);
 	}
 }
 
@@ -285,7 +293,8 @@ static void task_sve_to_fpsimd(struct task_struct *task __always_unused) { }
 void fpsimd_signal_preserve_current_state(void)
 {
 	fpsimd_preserve_current_state();
-	task_sve_to_fpsimd(current);
+	if (test_thread_flag(TIF_SVE))
+		task_sve_to_fpsimd(current);
 }
 
 /*
@@ -367,7 +376,7 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 {
 	preempt_disable();
 
-	if (IS_ENABLED(CONFIG_ARM64_SVE)) {
+	if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) {
 		current->thread.fpsimd_state = *state;
 		task_fpsimd_to_sve(current);
 	}
@@ -408,8 +417,8 @@ void kernel_neon_begin_partial(u32 num_regs)
 	 * interrupt context, so always save the userland SVE state
 	 * if there is any, even for interrupts.
 	 */
-	if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
-	    current->mm &&
+	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+	    test_thread_flag(TIF_SVE) && current->mm &&
 	    !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
 		fpsimd_save_state(&current->thread.fpsimd_state);
 		this_cpu_write(fpsimd_last_state, NULL);
@@ -532,6 +541,9 @@ static int __init fpsimd_init(void)
 	if (!(elf_hwcap & HWCAP_ASIMD))
 		pr_notice("Advanced SIMD is not implemented\n");
 
+	if (!(elf_hwcap & HWCAP_SVE))
+		pr_info("Scalable Vector Extension available\n");
+
 	return 0;
 }
 late_initcall(fpsimd_init);
arch/arm64/kernel/signal.c +4 -1
index 129b016..2528ec1 100644
@@ -259,6 +259,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 	preempt_disable();
 
 	set_thread_flag(TIF_FOREIGN_FPSTATE);
+	set_thread_flag(TIF_SVE);
 
 	BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
 	BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
@@ -543,9 +544,11 @@ static int setup_sigframe_layout(struct rt_sigframe_user_layout *user)
 			return err;
 	}
 
-	if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE)) {
+	if (IS_ENABLED(CONFIG_ARM64_SVE) && test_thread_flag(TIF_SVE)) {
 		unsigned int vq = sve_vq_from_vl(sve_get_vl());
 
+		BUG_ON(!(elf_hwcap & HWCAP_SVE));
+
 		err = sigframe_alloc(user, &user->sve_offset,
 				     SVE_SIG_CONTEXT_SIZE(vq));
 		if (err)
Signature · 1 line
2.1.4
#30 lore raw

RFC PATCH 23/29 arm64/sve: Move ZEN handling to the common task_fpsimd_load() path

In reply to Dave Martin

Currently, ZEN is handled only in fpsimd_restore_current_state(), which is not sufficient since it applies only in certain situations.

Since all the relevant paths call task_fpsimd_load(), this patch moves the ZEN handling there.

---
 arch/arm64/include/asm/thread_info.h |  1 +
 arch/arm64/kernel/fpsimd.c           | 48 +++++++++++++++++++-----------------
 2 files changed, 27 insertions(+), 22 deletions(-)
arch/arm64/include/asm/thread_info.h +1 -0
index 2deac86..6819d08 100644
@@ -133,6 +133,7 @@ static inline struct thread_info *current_thread_info(void)
 #define _TIF_SYSCALL_AUDIT	(1 << TIF_SYSCALL_AUDIT)
 #define _TIF_SYSCALL_TRACEPOINT	(1 << TIF_SYSCALL_TRACEPOINT)
 #define _TIF_SECCOMP		(1 << TIF_SECCOMP)
+#define _TIF_SVE		(1 << TIF_SVE)
 #define _TIF_32BIT		(1 << TIF_32BIT)
 
 #define _TIF_WORK_MASK		(_TIF_NEED_RESCHED | _TIF_SIGPENDING | \
arch/arm64/kernel/fpsimd.c +26 -22

80 lines not on this page · raw message

Signature · 1 line
2.1.4
#31 lore raw

RFC PATCH 24/29 arm64/sve: Discard SVE state on system call

In reply to Dave Martin

The base procedure call standard for the Scalable Vector Extension defines all of the SVE programmer's model state (Z0-31, P0-15, FFR) as caller-save, except for that subset of the state that aliases FPSIMD state.

System calls from userspace will almost always be made through C library wrappers -- as a consequence of the PCS there will thus rarely if ever be any live SVE state at syscall entry in practice.

This gives us an opportinity to make SVE explicitly caller-save around SVC and so stop carrying around the SVE state for tasks that use SVE only occasionally (say, by calling a library).

Note that FPSIMD state will still be preserved around SVC.

As a crude heuristic to avoid pathological cases where a thread that uses SVE frequently has to fault back into the kernel again to re-enable SVE after a syscall, we switch the thread back to FPSIMD-only context tracking only if the context is actually switched out before returning to userspace.

---
 arch/arm64/kernel/fpsimd.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
arch/arm64/kernel/fpsimd.c +17 -0
index 5834f81..2e1056e 100644
@@ -203,6 +203,23 @@ static void task_fpsimd_load(struct task_struct *task)
 static void task_fpsimd_save(struct task_struct *task)
 {
 	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
+	    task_pt_regs(task)->syscallno != ~0UL &&
+	    test_tsk_thread_flag(task, TIF_SVE)) {
+		unsigned long tmp;
+
+		clear_tsk_thread_flag(task, TIF_SVE);
+
+		/* Trap if the task tries to use SVE again: */
+		asm volatile (
+			"mrs	%[tmp], cpacr_el1\n\t"
+			"bic	%[tmp], %[tmp], %[mask]\n\t"
+			"msr	cpacr_el1, %[tmp]"
+			: [tmp] "=r" (tmp)
+			: [mask] "i" (CPACR_EL1_ZEN_EL0EN)
+		);
+	}
+
+	if (IS_ENABLED(CONFIG_ARM64_SVE) &&
 	    test_tsk_thread_flag(task, TIF_SVE))
 		sve_save_state(__task_pffr(task),
 			       &task->thread.fpsimd_state.fpsr);
Signature · 1 line
2.1.4
#32 lore raw

RFC PATCH 25/29 arm64/sve: Avoid preempt_disable() during sigreturn

In reply to Dave Martin

Currently the sigreturn implementation for SVE relies on preempt_disable() to avoid an intervening context switch from corrupting the SVE state in the task_struct.

Unforunately, __get_user() and friends are not safe under preempt_disable().

As an alternative, this patch removes preempt_disable() and sets TIF_FOREIGN_FPSTATE instead: this will inform the context switch code that the current CPU registers don't contain the SVE/FPSIMD state of the current task, preventing writeback to the task_struct during context switch.

---
 arch/arm64/kernel/signal.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)
arch/arm64/kernel/signal.c +5 -7
index 2528ec1..942d66f 100644
@@ -256,10 +256,8 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 	if (vl != sve_get_vl())
 		return -EINVAL;
 
-	preempt_disable();
-
 	set_thread_flag(TIF_FOREIGN_FPSTATE);
-	set_thread_flag(TIF_SVE);
+	barrier();
 
 	BUG_ON(SVE_SIG_REGS_SIZE(vq) > sizeof(*task_sve_regs));
 	BUG_ON(round_up(SVE_SIG_REGS_SIZE(vq), 16) < sizeof(*task_sve_regs));
@@ -270,7 +268,7 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 					SVE_SIG_REGS_OFFSET,
 			       SVE_SIG_REGS_SIZE(vq));
 	if (err)
-		goto out_preempt;
+		return err;
 
 	/* copy the FP and status/control registers */
 	/* restore_sigframe() already checked that user->fpsimd != NULL. */
@@ -279,13 +277,13 @@ static int __restore_sve_fpsimd_context(struct user_ctxs *user,
 	__get_user_error(fpsimd.fpsr, &user->fpsimd->fpsr, err);
 	__get_user_error(fpsimd.fpcr, &user->fpsimd->fpcr, err);
 
+	barrier();
+	set_thread_flag(TIF_SVE);
+
 	/* load the hardware registers from the fpsimd_state structure */
 	if (!err)
 		fpsimd_update_current_state(&fpsimd);
 
-out_preempt:
-	preempt_enable();
-
 	return err;
 }
 
Signature · 1 line
2.1.4
#33 lore raw

RFC PATCH 26/29 arm64/sve: Avoid stale user register state after SVE access exception

In reply to Dave Martin

Currently, when an SVE access exception is taken from userspace, the FPSIMD state in the task_struct is converted to SVE state and reloaded as SVE state.

Unfortunately, since we've been executing in userspace there's no guarantee that the FPSIMD state saved will actually be up to date with respect to the registers, so updates may be lost.

This patch saves the FPSIMD state back to the task_struct first, to ensure that the task_struct copy of the data is up to date.

Also, the CPACR handling logic is removed since task_fpsimd_load() handles it anyway.

---
 arch/arm64/kernel/fpsimd.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)
arch/arm64/kernel/fpsimd.c +6 -10
index 2e1056e..1750301 100644
@@ -103,22 +103,18 @@ void do_fpsimd_acc(unsigned int esr, struct pt_regs *regs)
 
 static void task_fpsimd_to_sve(struct task_struct *task);
 static void task_fpsimd_load(struct task_struct *task);
+static void task_fpsimd_save(struct task_struct *task);
 
 void do_sve_acc(unsigned int esr, struct pt_regs *regs)
 {
-	if (test_and_set_thread_flag(TIF_SVE)) {
-		unsigned long tmp;
-
-		asm ("mrs %0, cpacr_el1" : "=r" (tmp));
-
-		printk(KERN_INFO "%s: Strange, ZEN=%u\n",
-		       __func__, (unsigned int)((tmp >> 16) & 3));
-		BUG();
-	}
-
 	BUG_ON(is_compat_task());
 
+	task_fpsimd_save(current);
+
 	task_fpsimd_to_sve(current);
+	if (test_and_set_thread_flag(TIF_SVE))
+		BUG(); /* We shouldn't trap if SVE was already enabled! */
+
 	task_fpsimd_load(current);
 }
 
Signature · 1 line
2.1.4
#34 lore raw

RFC PATCH 27/29 arm64/sve: ptrace support

In reply to Dave Martin

From: Alan Hayward <[email protected]>

This patch adds support for accessing a task's SVE registers via ptrace.

Some additional helpers are added in order to support the SVE/ FPSIMD register view synchronisation operations that are required in order to make the NT_PRFPREG and NT_ARM_SVE regsets interact correctly.

fpr_set()/fpr_get() are refactored into backend/frontend functions, so that the core can be reused by sve_set()/sve_get() for the case where no SVE registers are stored for a thread.

---
 arch/arm64/include/asm/fpsimd.h          |  20 +++
 arch/arm64/include/uapi/asm/ptrace.h     | 125 +++++++++++++++
 arch/arm64/include/uapi/asm/sigcontext.h |   4 +
 arch/arm64/kernel/fpsimd.c               |  42 +++++
 arch/arm64/kernel/ptrace.c               | 254 ++++++++++++++++++++++++++++++-
 include/uapi/linux/elf.h                 |   1 +
 6 files changed, 440 insertions(+), 6 deletions(-)
arch/arm64/include/asm/fpsimd.h +20 -0
index e39066a..88bcf69 100644
@@ -35,6 +35,10 @@ struct fpsimd_state {
 			__uint128_t vregs[32];
 			u32 fpsr;
 			u32 fpcr;
+			/*
+			 * For ptrace compatibility, pad to next 128-bit
+			 * boundary here if extending this struct.
+			 */
 		};
 	};
 	/* the id of the last cpu to have restored this state */
@@ -98,6 +102,22 @@ extern void sve_save_state(void *state, u32 *pfpsr);
 extern void sve_load_state(void const *state, u32 const *pfpsr);
 extern unsigned int sve_get_vl(void);
 
+/*
+ * FPSIMD/SVE synchronisation helpers for ptrace:
+ * For use on stopped tasks only
+ */
+
+extern void fpsimd_sync_to_sve(struct task_struct *task);
+
+#ifdef CONFIG_ARM64_SVE
+extern void fpsimd_sync_to_fpsimd(struct task_struct *task);
+extern void fpsimd_sync_from_fpsimd_zeropad(struct task_struct *task);
+#else /* !CONFIG_ARM64_SVE */
+static void __maybe_unused fpsimd_sync_to_fpsimd(struct task_struct *task) { }
+static void __maybe_unused fpsimd_sync_from_fpsimd_zeropad(
+	struct task_struct *task) { }
+#endif /* !CONFIG_ARM64_SVE */
+
 #endif
 
 #endif
arch/arm64/include/uapi/asm/ptrace.h +125 -0

143 lines not on this page · raw message

arch/arm64/include/uapi/asm/sigcontext.h +4 -0
index 11c915d..91e55de 100644
@@ -16,6 +16,8 @@
 #ifndef _UAPI__ASM_SIGCONTEXT_H
 #define _UAPI__ASM_SIGCONTEXT_H
 
+#ifndef __ASSEMBLY__
+
 #include <linux/types.h>
 
 /*
@@ -96,6 +98,8 @@ struct sve_context {
 	__u16 __reserved[3];
 };
 
+#endif /* !__ASSEMBLY__ */
+
 /*
  * The SVE architecture leaves space for future expansion of the
  * vector length beyond its initial architectural limit of 2048 bits
arch/arm64/kernel/fpsimd.c +42 -0

48 lines not on this page · raw message

arch/arm64/kernel/ptrace.c +248 -6

300 lines not on this page · raw message

include/uapi/linux/elf.h +1 -0
index b59ee07..23c6585 100644
@@ -414,6 +414,7 @@ typedef struct elf64_shdr {
 #define NT_ARM_HW_BREAK	0x402		/* ARM hardware breakpoint registers */
 #define NT_ARM_HW_WATCH	0x403		/* ARM hardware watchpoint registers */
 #define NT_ARM_SYSTEM_CALL	0x404	/* ARM system call number */
+#define NT_ARM_SVE	0x405		/* ARM Scalable Vector Extension registers */
 #define NT_METAG_CBUF	0x500		/* Metag catch buffer registers */
 #define NT_METAG_RPIPE	0x501		/* Metag read pipeline state */
 #define NT_METAG_TLS	0x502		/* Metag TLS pointer */
Signature · 1 line
2.1.4
#35 lore raw

RFC PATCH 28/29 arm64: KVM: Treat SVE use by guests as undefined instruction execution

In reply to Dave Martin

We don't currently support context-switching of Scalable Vector Extension context between vcpus, and the SVE access exception is thus left masked by default at EL2 when running a vcpu.

However, there's nothing to stop a guest trying to use SVE. If it does, we'll get an SVE access exception to EL2 which will cause KVM to panic since this exception isn't yet recognised.

This patch adds knowledge to KVM about the SVE access exception, translating it into an undefined instruction exception injected to the vcpu.

This prevents a malicious guest from panicking the host by attempted SVE use.

SVE-enabled guests will still not work properly for now, but they won't take the host down.

---
 arch/arm64/kvm/handle_exit.c | 9 +++++++++
 1 file changed, 9 insertions(+)
arch/arm64/kvm/handle_exit.c +9 -0
index a204adf..f43b6d0 100644
@@ -125,6 +125,14 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
 	return ret;
 }
 
+static int handle_sve(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+	/* Until SVE is supported for guests: */
+	kvm_inject_undefined(vcpu);
+
+	return 1;
+}
+
 static exit_handle_fn arm_exit_handlers[] = {
 	[ESR_ELx_EC_WFx]	= kvm_handle_wfx,
 	[ESR_ELx_EC_CP15_32]	= kvm_handle_cp15_32,
@@ -137,6 +145,7 @@ static exit_handle_fn arm_exit_handlers[] = {
 	[ESR_ELx_EC_HVC64]	= handle_hvc,
 	[ESR_ELx_EC_SMC64]	= handle_smc,
 	[ESR_ELx_EC_SYS64]	= kvm_handle_sys_reg,
+	[ESR_ELx_EC_SVE]	= handle_sve,
 	[ESR_ELx_EC_IABT_LOW]	= kvm_handle_guest_abort,
 	[ESR_ELx_EC_DABT_LOW]	= kvm_handle_guest_abort,
 	[ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
Signature · 1 line
2.1.4
#36 lore raw

RFC PATCH 29/29 arm64/sve: Limit vector length to 512 bits by default

In reply to Dave Martin

As a transitional workaround for userspace incompatibilities caused by enlargement of the signal frame, this patch adds a new config option CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH, which default to n.

Unless this option is set to y, the vector length for SVE will be limited to 512 bits. This leaves a bit of free space for other architecture extensions just in case we need it.

This option will be removed and replaced with a user/kernel control interface in the future.

---
 arch/arm64/Kconfig   | 35 +++++++++++++++++++++++++++++++++++
 arch/arm64/mm/proc.S |  5 +++++
 2 files changed, 40 insertions(+)
arch/arm64/Kconfig +35 -0
index bf9915cb..7cd9812 100644
@@ -887,6 +887,41 @@ config ARM64_SVE
 
 	  To enable use of this extension on CPUs that implement it, say Y.
 
+if ARM64_SVE
+
+config ARM64_SVE_FULL_VECTOR_LENGTH
+	bool "Enable full hardware vector length for userspace"
+	default n
+	help
+	  SVE vector lengths greater than 512 bits impact the size of signal
+	  frames and therefore the size requirements for any userspace stack
+	  onto which a signal may be delivered.  Using larger vector lengths
+	  may therefore cause problems for some software.  For this reason, the
+	  kernel currently limits the maximum vector length for userspace
+	  software to 512 bits by default.
+
+	  Enabling this option removes the limit, so that the full vector
+	  length implemented by the hardware is made available to userspace.
+
+	  Be aware: in general, software that (a) does not use SVE (including
+	  via libraries), or (b) does not handle signals, or (c) uses default
+	  process/thread stack sizes and does not use sigaltstack(2) should be
+	  unaffected by enabling larger vectors.  Software that does not meet
+	  these criteria or that relies on certain legacy uses of the ucontext
+	  API may be affected however.
+
+	  This is a transitional compatibility option only and will be replaced
+	  by a userspace ABI extension in the future.  Do not assume that this
+	  option will be available with compatible effect in future Linux
+	  releases.
+
+	  If you are developing software that uses SVE and understand the
+	  implications, you can consider saying Y here.
+
+	  If unsure, say N.
+
+endif
+
 config ARM64_MODULE_CMODEL_LARGE
 	bool
 
arch/arm64/mm/proc.S +5 -0
index 1da8160..a2839e6 100644
@@ -198,6 +198,11 @@ ENTRY(__cpu_setup)
 
 	mrs_s	x5, ZIDR_EL1			// SVE: Enable full vector len
 	and	x5, x5, #ZCR_EL1_LEN_MASK	// initially
+#ifndef CONFIG_ARM64_SVE_FULL_VECTOR_LENGTH
+	mov	x6, #(512 / 128 - 1)		// Clamp VL to 512 bits
+	cmp	x5, x6
+	csel	x5, x5, x6, lo
+#endif
 	msr_s	ZCR_EL1, x5
 
 	b	2f
Signature · 1 line
2.1.4
#37 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin

Hi, Dave,

Quoted 2 lines · Dave Martin

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

If I read "independent SVE vector length configuration per thread" correctly, SVE vector length can be different in each thread, so the size of vector registers is different too. In GDB, we describe registers by "target description" which is per process, not per thread.

Signature · 1 line
Yao (??)
#38 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin
Quoted 13 lines · Dave Martin

The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which adds extra SIMD functionality and supports much larger vectors.

This series implements core Linux support for SVE.

Recipents not copied on the whole series can find the rest of the patches in the linux-arm-kernel archives [2].

The first 5 patches "arm64: signal: ..." factor out the allocation and placement of state information in the signal frame. The first three are prerequisites for the SVE support patches.

Quoted 5 lines

Patches 04-05 implement expansion of the signal frame, and may remain controversial due to ABI break issues:

* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.

I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to disable really wide vector registers in case this causes problems with old binaries.

A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to its complexity.

Quoted 7 lines

The remaining patches implement initial SVE support for Linux, with the following limitations:

* No KVM/virtualisation support for guests.

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable functions/executors quite challenging.

Can you detail your plans in this area?

Thanks,
Florian

#39 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 14 lines · Florian Weimer
Quoted 13 lines · Dave Martin

The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which adds extra SIMD functionality and supports much larger vectors.

This series implements core Linux support for SVE.

Recipents not copied on the whole series can find the rest of the patches in the linux-arm-kernel archives [2].

The first 5 patches "arm64: signal: ..." factor out the allocation and placement of state information in the signal frame. The first three are prerequisites for the SVE support patches.

Quoted 9 lines
Quoted 5 lines

Patches 04-05 implement expansion of the signal frame, and may remain controversial due to ABI break issues:

* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.

I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to disable really wide vector registers in case this causes problems with old binaries.

if the kernel does not increase the size and libc does not add size checks then old binaries would work with new libc just fine..
but that's non-conforming, posix requires the check.

if the kernel increases the size then it has to be changed in bionic and musl as well and old binaries may break.

Quoted 6 lines

A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to its complexity.

Quoted 3 lines

The remaining patches implement initial SVE support for Linux, with the following limitations:

Quoted 8 lines
Quoted 4 lines

* No KVM/virtualisation support for guests.

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable functions/executors quite challenging.

i'd assume it's undefined to context switch to a different thread or to resume a function on a different thread (because the implementation can cache thread local state on the stack: e.g. errno pointer).. of course this does not stop ppl from doing it, but the practice is questionable.

Quoted 4 lines

Can you detail your plans in this area?

Thanks,
Florian

#40 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 2 lines · Szabolcs Nagy
Quoted 1 line · Florian Weimer

On 11/25/2016 08:38 PM, Dave Martin wrote:

[...]

Quoted 7 lines
Quoted 6 lines
Quoted 2 lines

* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.

I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to disable really wide vector registers in case this causes problems with old binaries.

Quoted 8 lines

if the kernel does not increase the size and libc does not add size checks then old binaries would work with new libc just fine..
but that's non-conforming, posix requires the check.

if the kernel increases the size then it has to be changed in bionic and musl as well and old binaries may break.

Or we need a personality flag or similar to distinguish the two cases.

[...]

Quoted 15 lines
Quoted 6 lines

A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to its complexity.

Quoted 3 lines

The remaining patches implement initial SVE support for Linux, with the following limitations:

Quoted 8 lines
Quoted 4 lines

* No KVM/virtualisation support for guests.

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable functions/executors quite challenging.

Quoted 5 lines

i'd assume it's undefined to context switch to a different thread or to resume a function on a different thread (because the implementation can cache thread local state on the stack: e.g. errno pointer).. of course this does not stop ppl from doing it, but the practice is questionable.

I don't have a view on this.

Cheers
---Dave

#41 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Florian Weimer
Quoted 17 lines · Florian Weimer
Quoted 16 lines · Dave Martin

The Scalable Vector Extension (SVE) [1] is an extension to AArch64 which adds extra SIMD functionality and supports much larger vectors.

This series implements core Linux support for SVE.

Recipents not copied on the whole series can find the rest of the patches in the linux-arm-kernel archives [2].

The first 5 patches "arm64: signal: ..." factor out the allocation and placement of state information in the signal frame. The first three are prerequisites for the SVE support patches.

Patches 04-05 implement expansion of the signal frame, and may remain controversial due to ABI break issues:

Quoted 6 lines
Quoted 2 lines

* Discussion is needed on how userspace should detect/negotiate signal frame size in order for this expansion mechanism to be workable.

I'm leaning towards a simple increase in the glibc headers (despite the ABI risk), plus a personality flag to disable really wide vector registers in case this causes problems with old binaries.

I'm concerned here that there may be no sensible fixed size for the signal frame. We would make it ridiculously large in order to minimise the chance of hitting this problem again -- but then it would be ridiculously large, which is a potential problem for massively threaded workloads.

Or we could be more conservative, but risk a re-run of similar ABI breaks in the future.

A personality flag may also discourage use of larger vectors, even though the vast majority of software will work fine with them.

Quoted 2 lines

A more elaborate mechanism will likely introduce more bugs than it makes existing applications working, due to its complexity.

Yes, I was a bit concerned about this when I tried to sketch something out.

[...]

Quoted 10 lines
Quoted 2 lines

* No independent SVE vector length configuration per thread. This is planned, but will follow as a separate add-on series.

Per-thread register widths will likely make coroutine switching (setcontext) and C++ resumable functions/executors quite challenging.

Can you detail your plans in this area?

Thanks,
Florian

I'll also respond to Yao's question here, since it's closely related:

On Wed, Nov 30, 2016 at 09:56:14AM +0000, Yao Qi wrote:

[...]

Quoted 7 lines

If I read "independent SVE vector length configuration per thread" correctly, SVE vector length can be different in each thread, so the size of vector registers is different too. In GDB, we describe registers by "target description" which is per process, not per thread.

Signature · 1 line
Yao (??)

So, my key goal is to support _per-process_ vector length control.

Quoted 1 line

From the kernel perspective, it is easiest to achieve this by providing

per-thread control since that is the unit that context switching acts on.

How useful it really is to have threads with different VLs in the same process is an open question. It's theoretically useful for runtime environments, which may want to dispatch code optimised for different VLs -- changing the VL on-the-fly within a single thread is not something I want to encourage, due to overhead and ABI issues, but switching between threads of different VLs would be more manageable.

However, I expect mixing different VLs within a single process to be very much a special case -- it's not something I'd expect to work with general-purpose code.

Since the need for indepent VLs per thread is not proven, we could

* forbid it -- i.e., only a thread-group leader with no children is
permitted to change the VL, which is then inherited by any child threads that are subsequently created

* permit it only if a special flag is specified when requesting the VL
change

* permit it and rely on userspace to be sensible -- easiest option for
the kernel.

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

Thoughts?

---Dave

#42 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 4 lines · Dave Martin

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

the problem is not changing VL within a thread, but that setcontext can resume a context of a different thread which had different VL and there might be SVE regs spilled on the stack according to that.

(i consider this usage undefined, but at least the gccgo runtime does this)

#43 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 6 lines · Szabolcs Nagy
Quoted 4 lines · Dave Martin

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

Quoted 8 lines

the problem is not changing VL within a thread, but that setcontext can resume a context of a different thread which had different VL and there might be SVE regs spilled on the stack according to that.

(i consider this usage undefined, but at least the gccgo runtime does this)

Understood -- which is part of the reason for the argument that although the kernel may permit different threads to have different VLs, whether this actually works usefully also depends on your userspace runtime environment.

This again leads me to the conclusion that the request to create threads with different VLs within a single process should be explicit, in order to avoid accidents.

Cheers
---Dave

#44 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin
Quoted 5 lines · Dave Martin

I'm concerned here that there may be no sensible fixed size for the signal frame. We would make it ridiculously large in order to minimise the chance of hitting this problem again -- but then it would be ridiculously large, which is a potential problem for massively threaded workloads.

What's ridiculously large?

We could add a system call to get the right stack size. But as it depends on VL, I'm not sure what it looks like. Particularly if you need determine the stack size before creating a thread that uses a specific VL setting.

Quoted 4 lines

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

Okay, so we'd potentially set it on thread creation only? That might not be too bad.

I really want to avoid a repeat of the setxid fiasco, where we need to run code on all threads to get something that approximates the POSIX-mandated behavior (process attribute) from what the kernel provides (thread/task attribute).

Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

There are different ways to implement coroutines. Stack switching (like setcontext) is obviously impacted by non-uniform register sizes. But even the most conservative variant, rather similar to switch-based emulation you sometimes see in C coroutine implementations, might have trouble restoring the state if it just cannot restore the saved state due to register size reductions.

Thanks,
Florian

#45 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 9 lines · Florian Weimer
Quoted 5 lines · Dave Martin

I'm concerned here that there may be no sensible fixed size for the signal frame. We would make it ridiculously large in order to minimise the chance of hitting this problem again -- but then it would be ridiculously large, which is a potential problem for massively threaded workloads.

What's ridiculously large?

The SVE architecture permits VLs up to 2048 bits per vector initially -- but it makes space for future architecture revisions to expand up to 65536 bits per vector, which would result in a signal frame > 270 KB.

It's far from certain we'll ever see such large vectors, but it's hard to know where to draw the line.

Quoted 3 lines

We could add a system call to get the right stack size. But as it depends on VL, I'm not sure what it looks like. Particularly if you need determine the stack size before creating a thread that uses a specific VL setting.

I think that the most likely time to set the VL is libc startup or ld.so startup -- so really a process considers the VL fixed, and a hypothetical getsigstksz() function would return a constant value depending on the VL that was set.

I'd expect that only specialised code such as libc/ld.so itself or fancy runtimes would need to cope with the need to synchronise stack allocation with VL setting.

The initial stack after exec is determined by RLIMIT_STACK -- we can expect that to be easily large enough for the initial thread, under any remotely normal scenario.

Quoted 7 lines
Quoted 4 lines

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

Okay, so we'd potentially set it on thread creation only? That might not be too bad.

Basically, yes. A runtime _could_ set it at other times, and my view is that the kernel shouldn't arbitrarily forbid this -- but it's up to userspace to determine when it's safe to do it, ensure that there's no VL-dependent data live in memory, and to arrange to reallocate stacks or pre-arrange that allocations were already big enough etc.

Quoted 4 lines

I really want to avoid a repeat of the setxid fiasco, where we need to run code on all threads to get something that approximates the POSIX-mandated behavior (process attribute) from what the kernel provides (thread/task attribute).

Yeah, that would suck.

However, for the proposed ABI there is no illusion to preserve here, since the VL is proposed as a per-thread property everywhere, and this is outside the scope of POSIX.

If we do have distinct "set process VL" and "set thread VL" interfaces, then my view is that the former should fail if there are already multiple threads, rather than just setting the VL of a single thread or (worse) asynchronously changing the VL of threads other than the caller...

Quoted 6 lines
Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

Quoted 6 lines

There are different ways to implement coroutines. Stack switching (like setcontext) is obviously impacted by non-uniform register sizes. But even the most conservative variant, rather similar to switch-based emulation you sometimes see in C coroutine implementations, might have trouble restoring the state if it just cannot restore the saved state due to register size reductions.

Which is not a problem if the variably-sized state is not part of the switched context?

Because the SVE procedure call standard determines that the SVE registers are caller-save, they are not live at any external function boundary -- so in cooperative switching it is useless to save/restore this state unless the coroutine framework is defined to have a special procedure call standard.

Similarly, my view is that we don't attempt to magically save and restore VL itself either. Code that changes VL after startup would be expected to be aware of and deal with the consequences itself.

Cheers
---Dave

#46 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 5 lines · Dave Martin

If we do have distinct "set process VL" and "set thread VL" interfaces, then my view is that the former should fail if there are already multiple threads, rather than just setting the VL of a single thread or (worse) asynchronously changing the VL of threads other than the caller...

Yes, looks feasible to me.

Quoted 13 lines
Quoted 6 lines
Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

Quoted 6 lines

There are different ways to implement coroutines. Stack switching (like setcontext) is obviously impacted by non-uniform register sizes. But even the most conservative variant, rather similar to switch-based emulation you sometimes see in C coroutine implementations, might have trouble restoring the state if it just cannot restore the saved state due to register size reductions.

Quoted 2 lines

Which is not a problem if the variably-sized state is not part of the switched context?

The VL value is implicitly thread-local data, and the encoded state may have an implicit dependency on it, although it does not contain vector registers as such.

Quoted 2 lines

Because the SVE procedure call standard determines that the SVE registers are caller-save,

By the way, how is this implemented? Some of them overlap existing callee-saved registers.

Quoted 4 lines

they are not live at any external function
boundary -- so in cooperative switching it is useless to save/restore this state unless the coroutine framework is defined to have a special procedure call standard.

It can use the standard calling convention, but it may have selected a particular implementation based on the VL value before suspension.

Florian

#47 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 9 lines · Florian Weimer
Quoted 5 lines · Dave Martin

If we do have distinct "set process VL" and "set thread VL" interfaces, then my view is that the former should fail if there are already multiple threads, rather than just setting the VL of a single thread or (worse) asynchronously changing the VL of threads other than the caller...

Yes, looks feasible to me.

OK, I'll try to hack up something along these lines.

Quoted 13 lines
Quoted 13 lines
Quoted 12 lines
Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

There are different ways to implement coroutines. Stack switching (like setcontext) is obviously impacted by non-uniform register sizes. But even the most conservative variant, rather similar to switch-based emulation you sometimes see in C coroutine implementations, might have trouble restoring the state if it just cannot restore the saved state due to register size reductions.

Quoted 6 lines
Quoted 2 lines

Which is not a problem if the variably-sized state is not part of the switched context?

The VL value is implicitly thread-local data, and the encoded state may have an implicit dependency on it, although it does not contain vector registers as such.

This doesn't sound like an absolute requirement to me.

If we presume that the SVE registers never need to get saved or restored, what stops the context data format being VL-independent?

The setcontext()/getcontext() implementation for example will not change at all for SVE.

Quoted 5 lines
Quoted 2 lines

Because the SVE procedure call standard determines that the SVE registers are caller-save,

By the way, how is this implemented? Some of them overlap existing callee-saved registers.

Basically, all the *new* state is caller-save.

The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view Zn[bits 127:0] is callee-save for all n = 8..15.

Quoted 7 lines
Quoted 4 lines

they are not live at any external function
boundary -- so in cooperative switching it is useless to save/restore this state unless the coroutine framework is defined to have a special procedure call standard.

It can use the standard calling convention, but it may have selected a particular implementation based on the VL value before suspension.

If the save/restore logic doesn't touch SVE, which would its implementation be VL-dependent?

Cheers
---Dave

#48 lore raw

cover arm64: Scalable Vector Extension core support

On Thu, Dec 01, 2016 at 10:30:51AM +0000, Dave Martin wrote:

[...]

Quoted 4 lines

Basically, all the *new* state is caller-save.

The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view Zn[bits 127:0] is callee-save for all n = 8..15.

Ramana is right -- the current procedure call standard (ARM IHI 0055B) only requires the bottom _64_ bits of V8-V15 to be preserved (not all 128 bits as I stated).

[...]

Cheers
---Dave

#49 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin
Quoted 8 lines · Dave Martin
Quoted 3 lines

The VL value is implicitly thread-local data, and the encoded state may have an implicit dependency on it, although it does not contain vector registers as such.

This doesn't sound like an absolute requirement to me.

If we presume that the SVE registers never need to get saved or restored, what stops the context data format being VL-independent?

I'm concerned the suspended computation has code which has been selected to fit a particular VL value.

Quoted 2 lines

If the save/restore logic doesn't touch SVE, which would its implementation be VL-dependent?

Because it has been optimized for a certain vector length?

Quoted 10 lines
Quoted 5 lines
Quoted 2 lines

Because the SVE procedure call standard determines that the SVE registers are caller-save,

By the way, how is this implemented? Some of them overlap existing callee-saved registers.

Basically, all the *new* state is caller-save.

The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view Zn[bits 127:0] is callee-save for all n = 8..15.

Are the extension parts of registers v8 to v15 used for argument passing?

If not, we should be able to use the existing dynamic linker trampoline.

Thanks,
Florian

#50 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 12 lines · Florian Weimer
Quoted 7 lines
Quoted 2 lines

By the way, how is this implemented? Some of them overlap existing callee-saved registers.

Basically, all the *new* state is caller-save.

The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view Zn[bits 127:0] is callee-save for all n = 8..15.

Are the extension parts of registers v8 to v15 used for argument passing?

If not, we should be able to use the existing dynamic linker trampoline.

if sve arguments are passed to a function then it has special call abi (which is probably not yet documented), this call abi requires that such a call does not go through plt to avoid requiring sve aware libc.

same for tls access: the top part of sve regs have to be saved by the caller before accessing tls so the tlsdesc entry does not have to save them.

so current trampolines should be fine.

#51 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Florian Weimer
Quoted 11 lines · Florian Weimer
Quoted 8 lines · Dave Martin
Quoted 3 lines

The VL value is implicitly thread-local data, and the encoded state may have an implicit dependency on it, although it does not contain vector registers as such.

This doesn't sound like an absolute requirement to me.

If we presume that the SVE registers never need to get saved or restored, what stops the context data format being VL-independent?

Quoted 7 lines

I'm concerned the suspended computation has code which has been selected to fit a particular VL value.

Quoted 2 lines

If the save/restore logic doesn't touch SVE, which would its implementation be VL-dependent?

Because it has been optimized for a certain vector length?

I'll respond to these via Szabolcs' reply.

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines

Because the SVE procedure call standard determines that the SVE registers are caller-save,

By the way, how is this implemented? Some of them overlap existing callee-saved registers.

Quoted 6 lines
Quoted 4 lines

Basically, all the *new* state is caller-save.

The Neon/FPSIMD regs V8-V15 are callee-save, so in the SVE view Zn[bits 127:0] is callee-save for all n = 8..15.

Are the extension parts of registers v8 to v15 used for argument passing?

No -- the idea is to be directly compatible with the existing PCS.

Quoted 1 line

If not, we should be able to use the existing dynamic linker trampoline.

Yes, I believe so.

Cheers
---Dave

#52 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Florian Weimer

On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:

[...]

Quoted 3 lines

We could add a system call to get the right stack size. But as it depends on VL, I'm not sure what it looks like. Particularly if you need determine the stack size before creating a thread that uses a specific VL setting.

I missed this point previously -- apologies for that.

What would you think of:

	set_vl(vl_for_new_thread);
	minsigstksz = get_minsigstksz();
	set_vl(my_vl);

This avoids get_minsigstksz() requiring parameters -- which is mainly a concern because the parameters tomorrow might be different from the parameters today.

If it is possible to create the new thread without any SVE-dependent code, then we could

	set_vl(vl_for_new_thread);
	new_thread_stack = malloc(get_minsigstksz());
	new_thread = create_thread(..., new_thread_stack);
	set_vl(my_vl);

which has the nice property that the new thread directly inherits the configuration that was used for get_minsigstksz().

However, it would be necessary to prevent GCC from moving any code across these statements -- in particular, SVE code that access VL- dependent data spilled on the stack is liable to go wrong if reordered with the above. So the sequence would need to go in an external function (or a single asm...)

Failing that, we could maybe define some extensible struct to get_minsigstksz().

Thoughts?

Cheers
---Dave

#53 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 23 lines · Dave Martin

On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:

[...]

Quoted 3 lines

We could add a system call to get the right stack size. But as it depends on VL, I'm not sure what it looks like. Particularly if you need determine the stack size before creating a thread that uses a specific VL setting.

I missed this point previously -- apologies for that.

What would you think of:

	set_vl(vl_for_new_thread);
	minsigstksz = get_minsigstksz();
	set_vl(my_vl);

This avoids get_minsigstksz() requiring parameters -- which is mainly a concern because the parameters tomorrow might be different from the parameters today.

If it is possible to create the new thread without any SVE-dependent code, then we could

Quoted 7 lines
	set_vl(vl_for_new_thread);
	new_thread_stack = malloc(get_minsigstksz());
	new_thread = create_thread(..., new_thread_stack);
	set_vl(my_vl);

which has the nice property that the new thread directly inherits the configuration that was used for get_minsigstksz().

Because all SVE registers are caller-saved, it's acceptable to temporarily reduce the VL value, I think. So this should work.

One complication is that both the kernel and the libc need to reserve stack space, so the kernel-returned value and the one which has to be used in reality will be different.

Quoted 5 lines

However, it would be necessary to prevent GCC from moving any code across these statements -- in particular, SVE code that access VL- dependent data spilled on the stack is liable to go wrong if reordered with the above. So the sequence would need to go in an external function (or a single asm...)

I would talk to GCC folks?we have similar issues with changing the FPU rounding mode, I assume.

Thanks,
Florian

#54 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 8 lines · Florian Weimer
Quoted 5 lines

However, it would be necessary to prevent GCC from moving any code across these statements -- in particular, SVE code that access VL- dependent data spilled on the stack is liable to go wrong if reordered with the above. So the sequence would need to go in an external function (or a single asm...)

I would talk to GCC folks?we have similar issues with changing the FPU rounding mode, I assume.

In general, GCC doesn't track the implicit uses of thread-local state involved in floating-point exceptions and rounding modes, and so doesn't avoid moving code across manipulations of such state; there are various open bugs in this area (though many of the open bugs are for local rather than global issues with code generation or local optimizations not respecting exceptions and rounding modes, which are easier to fix). Hence glibc using various macros such as math_opt_barrier and math_force_eval which use asms to prevent such motion.

I'm not familiar enough with the optimizers to judge the right way to address such issues with implicit use of thread-local state. And I haven't thought much yet about how to implement TS 18661-1 constant rounding modes, which would involve the compiler implicitly inserting rounding modes changes, though I think it would be fairly straightforward given underlying support for avoiding inappropriate code motion.

Signature · 2 lines
Joseph S. Myers
joseph at codesourcery.com
#55 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 11 lines · Joseph Myers
Quoted 8 lines · Florian Weimer
Quoted 5 lines

However, it would be necessary to prevent GCC from moving any code across these statements -- in particular, SVE code that access VL- dependent data spilled on the stack is liable to go wrong if reordered with the above. So the sequence would need to go in an external function (or a single asm...)

I would talk to GCC folks?we have similar issues with changing the FPU rounding mode, I assume.

Quoted 8 lines

In general, GCC doesn't track the implicit uses of thread-local state involved in floating-point exceptions and rounding modes, and so doesn't avoid moving code across manipulations of such state; there are various open bugs in this area (though many of the open bugs are for local rather than global issues with code generation or local optimizations not respecting exceptions and rounding modes, which are easier to fix). Hence glibc using various macros such as math_opt_barrier and math_force_eval which use asms to prevent such motion.

Presumably the C language specs specify that fenv manipulations cannot be reordered with respect to evaluation or floating-point expressions? Sanity would seem to require this, though I've not dug into the specs myself yet.

This doesn't get us off the hook for prctl() -- the C specs can only define constraints on reordering for things that appear in the C spec. prctl() is just an external function call in this context, and doesn't enjoy the same guarantees.

Quoted 6 lines

I'm not familiar enough with the optimizers to judge the right way to address such issues with implicit use of thread-local state. And I haven't thought much yet about how to implement TS 18661-1 constant rounding modes, which would involve the compiler implicitly inserting rounding modes changes, though I think it would be fairly straightforward given underlying support for avoiding inappropriate code motion.

My concern is that the compiler has no clue about what code motions are appropriate or not with respect to a system call, beyond what applies to a system call in general (i.e., asm volatile ( ::: "memory" ) for GCC).

?

Cheers
---Dave

#56 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 2 lines · Dave Martin

Presumably the C language specs specify that fenv manipulations cannot be reordered with respect to evaluation or floating-point expressions?

Yes (in the context of #pragma STDC FENV_ACCESS ON). And you need to presume that an arbitrary function call might manipulate the environment unless you know it doesn't.

Signature · 2 lines
Joseph S. Myers
joseph at codesourcery.com
#57 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin
Quoted 6 lines · Dave Martin

So, my key goal is to support _per-process_ vector length control.

From the kernel perspective, it is easiest to achieve this by providing per-thread control since that is the unit that context switching acts on.

Hi, Dave,
Thanks for the explanation.

Quoted 6 lines

How useful it really is to have threads with different VLs in the same process is an open question. It's theoretically useful for runtime environments, which may want to dispatch code optimised for different VLs -- changing the VL on-the-fly within a single thread is not something I want to encourage, due to overhead and ABI issues, but switching between threads of different VLs would be more manageable.

This is a weird programming model.

Quoted 10 lines

However, I expect mixing different VLs within a single process to be very much a special case -- it's not something I'd expect to work with general-purpose code.

Since the need for indepent VLs per thread is not proven, we could

* forbid it -- i.e., only a thread-group leader with no children is
permitted to change the VL, which is then inherited by any child threads that are subsequently created

Quoted 5 lines

* permit it only if a special flag is specified when requesting the VL
change

* permit it and rely on userspace to be sensible -- easiest option for
the kernel.

Both the first and the third one is reasonable to me, but the first one fit well in existing GDB design. I don't know how useful it is to have per-thread VL, there may be some workloads can be implemented that way. GDB needs some changes to support "per-thread" target description.

Signature · 1 line
Yao 
#58 lore raw

cover arm64: Scalable Vector Extension core support

Quoted 11 lines · Yao Qi
Quoted 6 lines · Dave Martin

So, my key goal is to support _per-process_ vector length control.

From the kernel perspective, it is easiest to achieve this by providing per-thread control since that is the unit that context switching acts on.

Hi, Dave,
Thanks for the explanation.

Quoted 8 lines
Quoted 6 lines

How useful it really is to have threads with different VLs in the same process is an open question. It's theoretically useful for runtime environments, which may want to dispatch code optimised for different VLs -- changing the VL on-the-fly within a single thread is not something I want to encourage, due to overhead and ABI issues, but switching between threads of different VLs would be more manageable.

This is a weird programming model.

I may not have explained that very well.

What I meant is, you have two threads communicating with one another, say. Providing that they don't exchange data using a VL-dependent representation, it should not matter that the two threads are running with different VLs.

This may make sense if a particular piece of work was optimised for a particular VL: you can pick a worker thread with the correct VL and dispatch the job there for best performance.

I wouldn't expect this ability to be exploited except by specialised frameworks.

Quoted 13 lines
Quoted 13 lines

However, I expect mixing different VLs within a single process to be very much a special case -- it's not something I'd expect to work with general-purpose code.

Since the need for indepent VLs per thread is not proven, we could

* forbid it -- i.e., only a thread-group leader with no children is
permitted to change the VL, which is then inherited by any child threads that are subsequently created

* permit it only if a special flag is specified when requesting the VL
change

Quoted 7 lines
Quoted 2 lines

* permit it and rely on userspace to be sensible -- easiest option for
the kernel.

Both the first and the third one is reasonable to me, but the first one fit well in existing GDB design. I don't know how useful it is to have per-thread VL, there may be some workloads can be implemented that way. GDB needs some changes to support "per-thread" target description.

OK -- I'll implement for per-thread for now, but this can be clarified later.

Cheers
---Dave

#59 lore raw

cover arm64: Scalable Vector Extension core support

In reply to Dave Martin
Quoted 10 lines · Dave Martin

So, my key goal is to support _per-process_ vector length control.

From the kernel perspective, it is easiest to achieve this by providing per-thread control since that is the unit that context switching acts on.

How useful it really is to have threads with different VLs in the same process is an open question. It's theoretically useful for runtime environments, which may want to dispatch code optimised for different VLs

What would be the primary use case(s)? Vectorization of short vectors (eg, if having an array of structs or sth like that)?

Quoted 3 lines

-- changing the VL on-the-fly within a single thread is not something I want to encourage, due to overhead and ABI issues, but switching between threads of different VLs would be more manageable.

So if on-the-fly switching is probably not useful, that would mean we need special threads for the use cases. Is that a realistic assumption for the use cases? Or do you primarily want to keep it possible to do this, regardless of whether there are real use cases now?
I suppose allowing for a per-thread setting of VL could also be added as a feature in the future without breaking existing code.

Quoted 4 lines

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

Thus, you would basically consider VL changes or per-thread VL as in the realm of compilation internals? So, the specific size for a particular piece of code would not be part of an ABI?

Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

These are not part of the C++ standard yet, but will appear in TSes. There are various features for which implementations would be assumed to use one OS thread for several tasks, coroutines, etc. Some of them switch between these tasks or coroutines while these are running, whereas the ones that will be in C++17 only run more than parallel task on the same OS thread but one after the other (like in a thread pool).

However, if we are careful not to expose VL or make promises about it, this may just end up being a detail similar to, say, register allocation, which isn't exposed beyond the internals of a particular compiler either.
Exposing it as a feature the user can set without messing with the implementation would introduce additional thread-specific state, as Florian said. This might not be a show-stopper by itself, but the more thread-specific state we have the more an implementation has to take care of or switch, and the higher the runtime costs are. C++17 already makes weaker promises for TLS for parallel tasks, so that implementations don't have to run TLS constructors or destructors just because a small parallel task was executed.

#60 lore raw

cover arm64: Scalable Vector Extension core support

On Mon, Dec 05, 2016 at 11:42:19PM +0100, Torvald Riegel wrote:

Hi there,

Quoted 7 lines · Dave Martin
Quoted 6 lines

So, my key goal is to support _per-process_ vector length control.

From the kernel perspective, it is easiest to achieve this by providing per-thread control since that is the unit that context switching acts on.

Quoted 7 lines
Quoted 4 lines

How useful it really is to have threads with different VLs in the same process is an open question. It's theoretically useful for runtime environments, which may want to dispatch code optimised for different VLs

What would be the primary use case(s)? Vectorization of short vectors (eg, if having an array of structs or sth like that)?

I'm not sure exactly what you're asking here.

SVE supports a regular SIMD-type computational model, along with scalable vectors and features for speculative vectorisation of loops whose iteration count is not statically known (or, possibly not known even at loop entry at runtime). It's intended as a compiler target, so any algorithm that involves iterative computation may get some benefit -- though the amount of benefit, and how the benefit scales with vector length, will depend on the algorithm in question.

So some algorithms may get more benefit more from large VLs than others. For jobs where performance tends to saturate at a shorter VL, it may make sense to get the compiler to compile for the shorter VL -- this may enable the same binary code to perform more optimally on a wider range of hardware, but that may also mean you want to run that job with the VL it was compiled for instead of what the hardware supports.

In high-assurance scenarios, you might also want to restrict a particular job to run at the VL that you validated for.

Quoted 10 lines
Quoted 3 lines

-- changing the VL on-the-fly within a single thread is not something I want to encourage, due to overhead and ABI issues, but switching between threads of different VLs would be more manageable.

So if on-the-fly switching is probably not useful, that would mean we need special threads for the use cases. Is that a realistic assumption for the use cases? Or do you primarily want to keep it possible to do this, regardless of whether there are real use cases now?
I suppose allowing for a per-thread setting of VL could also be added as a feature in the future without breaking existing code.

Per-thread VL use cases are hypothetical for now.

It's easy to support per-thread VLs in the kernel, but we could deny it initially and wait for someone to come along with a concrete use case.

Quoted 8 lines
Quoted 4 lines

For setcontext/setjmp, we don't save/restore any SVE state due to the caller-save status of SVE, and I would not consider it necessary to save/restore VL itself because of the no-change-on-the-fly policy for this.

Thus, you would basically consider VL changes or per-thread VL as in the realm of compilation internals? So, the specific size for a particular piece of code would not be part of an ABI?

Basically yes. For most people, this would be hidden in libc/ld.so/some framework. This goes for most prctl()s -- random user code shouldn't normally touch them unless it knows what it's doing.

Quoted 10 lines
Quoted 5 lines

I'm not familiar with resumable functions/executors -- are these in the C++ standards yet (not that that would cause me to be familiar with them... ;) Any implementation of coroutines (i.e., cooperative switching) is likely to fall under the "setcontext" argument above.

These are not part of the C++ standard yet, but will appear in TSes. There are various features for which implementations would be assumed to use one OS thread for several tasks, coroutines, etc. Some of them switch between these tasks or coroutines while these are running,

Is the switching ever preemptive? If not, that these features are unlikely to be a concern for SVE. It's preemptive switching that would require the saving of extra SVE state (which is why we need to care for signals).

Quoted 2 lines

whereas the ones that will be in C++17 only run more than parallel task on the same OS thread but one after the other (like in a thread pool).

If jobs are only run to completion before yielding, that again isn't a concern for SVE.

Quoted 4 lines

However, if we are careful not to expose VL or make promises about it, this may just end up being a detail similar to, say, register allocation, which isn't exposed beyond the internals of a particular compiler either.

Quoted 8 lines

Exposing it as a feature the user can set without messing with the implementation would introduce additional thread-specific state, as Florian said. This might not be a show-stopper by itself, but the more thread-specific state we have the more an implementation has to take care of or switch, and the higher the runtime costs are. C++17 already makes weaker promises for TLS for parallel tasks, so that implementations don't have to run TLS constructors or destructors just because a small parallel task was executed.

There's a difference between a feature that exposed by the kernel, and a feature endorsed by the language / runtime.

For example, random code can enable seccomp via prctl(PR_SET_SECCOMP) -- this may make most of libc unsafe to use, because under strict seccomp most syscalls simply kill the thread. libc doesn't pretend to support this out of the box, but this feature is also not needlessly denied to user code that knows what it's doing.

I tend to put setting the VL into this category: it is safe, and useful or even necessary to change the VL in some situations, but userspace is responsible for managing this for itself. The kernel doesn't have enough information to make these decisions unilaterally.

Cheers
---Dave