linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org,
	Okamoto Takayuki <tokamoto@jp.fujitsu.com>,
	libc-alpha@sourceware.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	kvmarm@lists.cs.columbia.edu
Subject: [PATCH v4 18/28] arm64/sve: Preserve SVE registers around EFI runtime service calls
Date: Fri, 27 Oct 2017 11:51:00 +0100	[thread overview]
Message-ID: <1509101470-7881-19-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1509101470-7881-1-git-send-email-Dave.Martin@arm.com>

The EFI runtime services ABI allows EFI to make free use of the
FPSIMD registers during EFI runtime service calls, subject to the
callee-save requirements of the AArch64 procedure call standard.

However, the SVE architecture allows upper bits of the SVE vector
registers to be zeroed as a side-effect of FPSIMD V-register
writes.  This means that the SVE vector registers must be saved in
their entirety in order to avoid data loss: non-SVE-aware EFI
implementations cannot restore them correctly.

The non-IRQ case is already handled gracefully by
kernel_neon_begin().  For the IRQ case, this patch allocates a
suitable per-CPU stash buffer for the full SVE register state and
uses it to preserve the affected registers around EFI calls.  It is
currently unclear how the EFI runtime services ABI will be
clarified with respect to SVE, so it safest to assume that the
predicate registers and FFR must be saved and restored too.

No attempt is made to restore the restore the vector length after
a call, for now.  It is deemed rather insane for EFI to change it,
and contemporary EFI implementations certainly won't.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/kernel/fpsimd.c | 67 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 61 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index d5108e8..edc27d2 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -121,11 +121,13 @@ static int sve_default_vl = -1;
 int __ro_after_init sve_max_vl = -1;
 /* Set of available vector lengths, as vq_to_bit(vq): */
 static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
+static void __percpu *efi_sve_state;
 
 #else /* ! CONFIG_ARM64_SVE */
 
 /* Dummy declaration for code that will be optimised out: */
 extern __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
+extern void __percpu *efi_sve_state;
 
 #endif /* ! CONFIG_ARM64_SVE */
 
@@ -550,6 +552,30 @@ int sve_verify_vq_map(void)
 	return ret;
 }
 
+static void __init sve_efi_setup(void)
+{
+	if (!IS_ENABLED(CONFIG_EFI))
+		return;
+
+	/*
+	 * alloc_percpu() warns and prints a backtrace if this goes wrong.
+	 * This is evidence of a crippled system and we are returning void,
+	 * so no attempt is made to handle this situation here.
+	 */
+	if (!sve_vl_valid(sve_max_vl))
+		goto fail;
+
+	efi_sve_state = __alloc_percpu(
+		SVE_SIG_REGS_SIZE(sve_vq_from_vl(sve_max_vl)), SVE_VQ_BYTES);
+	if (!efi_sve_state)
+		goto fail;
+
+	return;
+
+fail:
+	panic("Cannot allocate percpu memory for EFI SVE save/restore");
+}
+
 /*
  * Enable SVE for EL1.
  * Intended for use by the cpufeatures code during CPU boot.
@@ -597,6 +623,8 @@ void __init sve_setup(void)
 		sve_max_vl);
 	pr_info("SVE: default vector length %u bytes per vector\n",
 		sve_default_vl);
+
+	sve_efi_setup();
 }
 
 /*
@@ -925,6 +953,7 @@ EXPORT_SYMBOL(kernel_neon_end);
 
 static DEFINE_PER_CPU(struct fpsimd_state, efi_fpsimd_state);
 static DEFINE_PER_CPU(bool, efi_fpsimd_state_used);
+static DEFINE_PER_CPU(bool, efi_sve_state_used);
 
 /*
  * EFI runtime services support functions
@@ -950,10 +979,24 @@ void __efi_fpsimd_begin(void)
 
 	WARN_ON(preemptible());
 
-	if (may_use_simd())
+	if (may_use_simd()) {
 		kernel_neon_begin();
-	else {
-		fpsimd_save_state(this_cpu_ptr(&efi_fpsimd_state));
+	} else {
+		/*
+		 * If !efi_sve_state, SVE can't be in use yet and doesn't need
+		 * preserving:
+		 */
+		if (system_supports_sve() && likely(efi_sve_state)) {
+			char *sve_state = this_cpu_ptr(efi_sve_state);
+
+			__this_cpu_write(efi_sve_state_used, true);
+
+			sve_save_state(sve_state + sve_ffr_offset(sve_max_vl),
+				       &this_cpu_ptr(&efi_fpsimd_state)->fpsr);
+		} else {
+			fpsimd_save_state(this_cpu_ptr(&efi_fpsimd_state));
+		}
+
 		__this_cpu_write(efi_fpsimd_state_used, true);
 	}
 }
@@ -966,10 +1009,22 @@ void __efi_fpsimd_end(void)
 	if (!system_supports_fpsimd())
 		return;
 
-	if (__this_cpu_xchg(efi_fpsimd_state_used, false))
-		fpsimd_load_state(this_cpu_ptr(&efi_fpsimd_state));
-	else
+	if (!__this_cpu_xchg(efi_fpsimd_state_used, false)) {
 		kernel_neon_end();
+	} else {
+		if (system_supports_sve() &&
+		    likely(__this_cpu_read(efi_sve_state_used))) {
+			char const *sve_state = this_cpu_ptr(efi_sve_state);
+
+			sve_load_state(sve_state + sve_ffr_offset(sve_max_vl),
+				       &this_cpu_ptr(&efi_fpsimd_state)->fpsr,
+				       sve_vq_from_vl(sve_get_vl()) - 1);
+
+			__this_cpu_write(efi_sve_state_used, false);
+		} else {
+			fpsimd_load_state(this_cpu_ptr(&efi_fpsimd_state));
+		}
+	}
 }
 
 #endif /* CONFIG_EFI */
-- 
2.1.4

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com>
To: linux-arm-kernel@lists.infradead.org
Cc: "Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will.deacon@arm.com>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Szabolcs Nagy" <szabolcs.nagy@arm.com>,
	"Okamoto Takayuki" <tokamoto@jp.fujitsu.com>,
	kvmarm@lists.cs.columbia.edu, libc-alpha@sourceware.org,
	linux-arch@vger.kernel.org
Subject: [PATCH v4 18/28] arm64/sve: Preserve SVE registers around EFI runtime service calls
Date: Fri, 27 Oct 2017 11:51:00 +0100	[thread overview]
Message-ID: <1509101470-7881-19-git-send-email-Dave.Martin@arm.com> (raw)
Message-ID: <20171027105100.52oKrlHwEIIuOmfWBSZORQzj8fIgWTiWfV8aU4easZY@z> (raw)
In-Reply-To: <1509101470-7881-1-git-send-email-Dave.Martin@arm.com>

The EFI runtime services ABI allows EFI to make free use of the
FPSIMD registers during EFI runtime service calls, subject to the
callee-save requirements of the AArch64 procedure call standard.

However, the SVE architecture allows upper bits of the SVE vector
registers to be zeroed as a side-effect of FPSIMD V-register
writes.  This means that the SVE vector registers must be saved in
their entirety in order to avoid data loss: non-SVE-aware EFI
implementations cannot restore them correctly.

The non-IRQ case is already handled gracefully by
kernel_neon_begin().  For the IRQ case, this patch allocates a
suitable per-CPU stash buffer for the full SVE register state and
uses it to preserve the affected registers around EFI calls.  It is
currently unclear how the EFI runtime services ABI will be
clarified with respect to SVE, so it safest to assume that the
predicate registers and FFR must be saved and restored too.

No attempt is made to restore the restore the vector length after
a call, for now.  It is deemed rather insane for EFI to change it,
and contemporary EFI implementations certainly won't.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/kernel/fpsimd.c | 67 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 61 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index d5108e8..edc27d2 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -121,11 +121,13 @@ static int sve_default_vl = -1;
 int __ro_after_init sve_max_vl = -1;
 /* Set of available vector lengths, as vq_to_bit(vq): */
 static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
+static void __percpu *efi_sve_state;
 
 #else /* ! CONFIG_ARM64_SVE */
 
 /* Dummy declaration for code that will be optimised out: */
 extern __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
+extern void __percpu *efi_sve_state;
 
 #endif /* ! CONFIG_ARM64_SVE */
 
@@ -550,6 +552,30 @@ int sve_verify_vq_map(void)
 	return ret;
 }
 
+static void __init sve_efi_setup(void)
+{
+	if (!IS_ENABLED(CONFIG_EFI))
+		return;
+
+	/*
+	 * alloc_percpu() warns and prints a backtrace if this goes wrong.
+	 * This is evidence of a crippled system and we are returning void,
+	 * so no attempt is made to handle this situation here.
+	 */
+	if (!sve_vl_valid(sve_max_vl))
+		goto fail;
+
+	efi_sve_state = __alloc_percpu(
+		SVE_SIG_REGS_SIZE(sve_vq_from_vl(sve_max_vl)), SVE_VQ_BYTES);
+	if (!efi_sve_state)
+		goto fail;
+
+	return;
+
+fail:
+	panic("Cannot allocate percpu memory for EFI SVE save/restore");
+}
+
 /*
  * Enable SVE for EL1.
  * Intended for use by the cpufeatures code during CPU boot.
@@ -597,6 +623,8 @@ void __init sve_setup(void)
 		sve_max_vl);
 	pr_info("SVE: default vector length %u bytes per vector\n",
 		sve_default_vl);
+
+	sve_efi_setup();
 }
 
 /*
@@ -925,6 +953,7 @@ EXPORT_SYMBOL(kernel_neon_end);
 
 static DEFINE_PER_CPU(struct fpsimd_state, efi_fpsimd_state);
 static DEFINE_PER_CPU(bool, efi_fpsimd_state_used);
+static DEFINE_PER_CPU(bool, efi_sve_state_used);
 
 /*
  * EFI runtime services support functions
@@ -950,10 +979,24 @@ void __efi_fpsimd_begin(void)
 
 	WARN_ON(preemptible());
 
-	if (may_use_simd())
+	if (may_use_simd()) {
 		kernel_neon_begin();
-	else {
-		fpsimd_save_state(this_cpu_ptr(&efi_fpsimd_state));
+	} else {
+		/*
+		 * If !efi_sve_state, SVE can't be in use yet and doesn't need
+		 * preserving:
+		 */
+		if (system_supports_sve() && likely(efi_sve_state)) {
+			char *sve_state = this_cpu_ptr(efi_sve_state);
+
+			__this_cpu_write(efi_sve_state_used, true);
+
+			sve_save_state(sve_state + sve_ffr_offset(sve_max_vl),
+				       &this_cpu_ptr(&efi_fpsimd_state)->fpsr);
+		} else {
+			fpsimd_save_state(this_cpu_ptr(&efi_fpsimd_state));
+		}
+
 		__this_cpu_write(efi_fpsimd_state_used, true);
 	}
 }
@@ -966,10 +1009,22 @@ void __efi_fpsimd_end(void)
 	if (!system_supports_fpsimd())
 		return;
 
-	if (__this_cpu_xchg(efi_fpsimd_state_used, false))
-		fpsimd_load_state(this_cpu_ptr(&efi_fpsimd_state));
-	else
+	if (!__this_cpu_xchg(efi_fpsimd_state_used, false)) {
 		kernel_neon_end();
+	} else {
+		if (system_supports_sve() &&
+		    likely(__this_cpu_read(efi_sve_state_used))) {
+			char const *sve_state = this_cpu_ptr(efi_sve_state);
+
+			sve_load_state(sve_state + sve_ffr_offset(sve_max_vl),
+				       &this_cpu_ptr(&efi_fpsimd_state)->fpsr,
+				       sve_vq_from_vl(sve_get_vl()) - 1);
+
+			__this_cpu_write(efi_sve_state_used, false);
+		} else {
+			fpsimd_load_state(this_cpu_ptr(&efi_fpsimd_state));
+		}
+	}
 }
 
 #endif /* CONFIG_EFI */
-- 
2.1.4

  parent reply	other threads:[~2017-10-27 10:51 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-27 10:50 [PATCH v4 00/28] ARM Scalable Vector Extension (SVE) Dave Martin
2017-10-27 10:50 ` [PATCH v4 01/28] regset: Add support for dynamically sized regsets Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 10:50 ` [PATCH v4 02/28] arm64: KVM: Hide unsupported AArch64 CPU features from guests Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-31 10:57   ` Alex Bennée
2017-10-31 10:57     ` Alex Bennée
2017-10-27 10:50 ` [PATCH v4 03/28] arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON Dave Martin
2017-10-27 10:50 ` [PATCH v4 04/28] arm64: Port deprecated instruction emulation to new sysctl interface Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 10:50 ` [PATCH v4 05/28] arm64: fpsimd: Simplify uses of {set, clear}_ti_thread_flag() Dave Martin
2017-10-27 10:50   ` [PATCH v4 05/28] arm64: fpsimd: Simplify uses of {set,clear}_ti_thread_flag() Dave Martin
2017-10-27 10:50 ` [PATCH v4 06/28] arm64/sve: System register and exception syndrome definitions Dave Martin
2017-10-27 10:50 ` [PATCH v4 07/28] arm64/sve: Low-level SVE architectural state manipulation functions Dave Martin
2017-10-27 10:50 ` [PATCH v4 08/28] arm64/sve: Kconfig update and conditional compilation support Dave Martin
2017-10-27 10:50 ` [PATCH v4 09/28] arm64/sve: Signal frame and context structure definition Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 10:50 ` [PATCH v4 10/28] arm64/sve: Low-level CPU setup Dave Martin
2017-10-27 10:50 ` [PATCH v4 11/28] arm64/sve: Core task context handling Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 12:45   ` Catalin Marinas
2017-10-27 12:45     ` Catalin Marinas
2017-10-27 10:50 ` [PATCH v4 12/28] arm64/sve: Support vector length resetting for new processes Dave Martin
2017-10-27 10:50 ` [PATCH v4 13/28] arm64/sve: Signal handling support Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 12:54   ` Catalin Marinas
2017-10-27 10:50 ` [PATCH v4 14/28] arm64/sve: Backend logic for setting the vector length Dave Martin
2017-10-27 10:50 ` [PATCH v4 15/28] arm64: cpufeature: Move sys_caps_initialised declarations Dave Martin
2017-10-27 10:50 ` [PATCH v4 16/28] arm64/sve: Probe SVE capabilities and usable vector lengths Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 12:56   ` Catalin Marinas
2017-10-27 12:56     ` Catalin Marinas
2017-10-27 10:50 ` [PATCH v4 17/28] arm64/sve: Preserve SVE registers around kernel-mode NEON use Dave Martin
2017-10-27 10:50   ` Dave Martin
2017-10-27 10:51 ` Dave Martin [this message]
2017-10-27 10:51   ` [PATCH v4 18/28] arm64/sve: Preserve SVE registers around EFI runtime service calls Dave Martin
2017-10-27 10:51 ` [PATCH v4 19/28] arm64/sve: ptrace and ELF coredump support Dave Martin
2017-10-27 13:04   ` Catalin Marinas
2017-10-27 13:04     ` Catalin Marinas
2017-10-27 10:51 ` [PATCH v4 20/28] arm64/sve: Add prctl controls for userspace vector length management Dave Martin
2017-10-27 10:51   ` Dave Martin
2017-10-27 17:52   ` Alex Bennée
2017-10-27 17:52     ` Alex Bennée
2017-10-28 16:05     ` Dave Martin
2017-10-30 16:12       ` Alex Bennée
2017-10-30 16:12         ` Alex Bennée
2017-10-30 16:17         ` Dave Martin
2017-10-30 16:17           ` Dave Martin
2017-10-27 10:51 ` [PATCH v4 21/28] arm64/sve: Add sysctl to set the default vector length for new processes Dave Martin
2017-10-27 10:51 ` [PATCH v4 22/28] arm64/sve: KVM: Prevent guests from using SVE Dave Martin
2017-10-27 10:51 ` [PATCH v4 23/28] arm64/sve: KVM: Treat guest SVE use as undefined instruction execution Dave Martin
2017-10-27 10:51   ` Dave Martin
2017-10-27 10:51 ` [PATCH v4 24/28] arm64/sve: KVM: Hide SVE from CPU features exposed to guests Dave Martin
2017-10-27 10:51 ` [PATCH v4 25/28] arm64/sve: Detect SVE and activate runtime support Dave Martin
2017-10-27 13:05   ` Catalin Marinas
2017-10-27 10:51 ` [PATCH v4 26/28] arm64/sve: Add documentation Dave Martin
2017-10-27 13:06   ` Catalin Marinas
2017-10-27 10:51 ` [RFC PATCH v4 27/28] arm64: signal: Report signal frame size to userspace via auxv Dave Martin
2017-10-27 10:51   ` Dave Martin
2017-10-27 10:51 ` [RFC PATCH v4 28/28] arm64/sve: signal: Include SVE when computing AT_MINSIGSTKSZ Dave Martin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1509101470-7881-19-git-send-email-Dave.Martin@arm.com \
    --to=dave.martin@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=szabolcs.nagy@arm.com \
    --cc=tokamoto@jp.fujitsu.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).