linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Cyril Bur <cyrilbur@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: wei.guo.simon@gmail.com, mikey@neuling.org
Subject: [PATCH v4 02/20] powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use
Date: Tue,  6 Sep 2016 09:44:30 +1000	[thread overview]
Message-ID: <20160905234448.5866-3-cyrilbur@gmail.com> (raw)
In-Reply-To: <20160905234448.5866-1-cyrilbur@gmail.com>

Comment from arch/powerpc/kernel/process.c:967:
 If userspace is inside a transaction (whether active or
 suspended) and FP/VMX/VSX instructions have ever been enabled
 inside that transaction, then we have to keep them enabled
 and keep the FP/VMX/VSX state loaded while ever the transaction
 continues.  The reason is that if we didn't, and subsequently
 got a FP/VMX/VSX unavailable interrupt inside a transaction,
 we don't know whether it's the same transaction, and thus we
 don't know which of the checkpointed state and the ransactional
 state to use.

restore_math() restore_fp() and restore_altivec() currently may not
restore the registers. It doesn't appear that this is more serious
than a performance penalty. If the math registers aren't restored the
userspace thread will still be run with the facility disabled.
Userspace will not be able to read invalid values. On the first access
it will take an facility unavailable exception and the kernel will
detected an active transaction, at which point it will abort the
transaction. There is the possibility for a pathological case
preventing any progress by transactions, however, transactions
are never guaranteed to make progress.

Fixes: 70fe3d9 ("powerpc: Restore FPU/VEC/VSX if previously used")
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 arch/powerpc/kernel/process.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 58ccf86..cdf2d20 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -88,7 +88,13 @@ static void check_if_tm_restore_required(struct task_struct *tsk)
 		set_thread_flag(TIF_RESTORE_TM);
 	}
 }
+
+static inline bool msr_tm_active(unsigned long msr)
+{
+	return MSR_TM_ACTIVE(msr);
+}
 #else
+static inline bool msr_tm_active(unsigned long msr) { return false; }
 static inline void check_if_tm_restore_required(struct task_struct *tsk) { }
 #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
 
@@ -208,7 +214,7 @@ void enable_kernel_fp(void)
 EXPORT_SYMBOL(enable_kernel_fp);
 
 static int restore_fp(struct task_struct *tsk) {
-	if (tsk->thread.load_fp) {
+	if (tsk->thread.load_fp || msr_tm_active(tsk->thread.regs->msr)) {
 		load_fp_state(&current->thread.fp_state);
 		current->thread.load_fp++;
 		return 1;
@@ -278,7 +284,8 @@ EXPORT_SYMBOL_GPL(flush_altivec_to_thread);
 
 static int restore_altivec(struct task_struct *tsk)
 {
-	if (cpu_has_feature(CPU_FTR_ALTIVEC) && tsk->thread.load_vec) {
+	if (cpu_has_feature(CPU_FTR_ALTIVEC) &&
+		(tsk->thread.load_vec || msr_tm_active(tsk->thread.regs->msr))) {
 		load_vr_state(&tsk->thread.vr_state);
 		tsk->thread.used_vr = 1;
 		tsk->thread.load_vec++;
@@ -464,7 +471,8 @@ void restore_math(struct pt_regs *regs)
 {
 	unsigned long msr;
 
-	if (!current->thread.load_fp && !loadvec(current->thread))
+	if (!msr_tm_active(regs->msr) &&
+		!current->thread.load_fp && !loadvec(current->thread))
 		return;
 
 	msr = regs->msr;
@@ -983,6 +991,13 @@ void restore_tm_state(struct pt_regs *regs)
 	msr_diff = current->thread.ckpt_regs.msr & ~regs->msr;
 	msr_diff &= MSR_FP | MSR_VEC | MSR_VSX;
 
+	/* Ensure that restore_math() will restore */
+	if (msr_diff & MSR_FP)
+		current->thread.load_fp = 1;
+#ifdef CONFIG_ALIVEC
+	if (cpu_has_feature(CPU_FTR_ALTIVEC) && msr_diff & MSR_VEC)
+		current->thread.load_vec = 1;
+#endif
 	restore_math(regs);
 
 	regs->msr |= msr_diff;
-- 
2.9.3

  parent reply	other threads:[~2016-09-05 23:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-05 23:44 [PATCH v4 00/20] Consistent TM structures Cyril Bur
2016-09-05 23:44 ` [PATCH v4 01/20] selftests/powerpc: Compile selftests against headers without AT_HWCAP2 Cyril Bur
2016-09-05 23:44 ` Cyril Bur [this message]
2016-09-05 23:44 ` [PATCH v4 03/20] powerpc: Add check_if_tm_restore_required() to giveup_all() Cyril Bur
2016-09-05 23:44 ` [PATCH v4 04/20] powerpc: Return the new MSR from msr_check_and_set() Cyril Bur
2016-09-05 23:44 ` [PATCH v4 05/20] powerpc: Never giveup a reclaimed thread when enabling kernel {fp, altivec, vsx} Cyril Bur
2016-09-05 23:44 ` [PATCH v4 06/20] powerpc: signals: Stop using current in signal code Cyril Bur
2016-09-05 23:44 ` [PATCH v4 07/20] selftests/powerpc: Check for VSX preservation across userspace preemption Cyril Bur
2016-09-05 23:44 ` [PATCH v4 08/20] selftests/powerpc: Rework FPU stack placement macros and move to header file Cyril Bur
2016-09-05 23:44 ` [PATCH v4 09/20] selftests/powerpc: Move VMX stack frame macros " Cyril Bur
2016-09-05 23:44 ` [PATCH v4 10/20] selftests/powerpc: Introduce GPR asm helper " Cyril Bur
2016-09-05 23:44 ` [PATCH v4 11/20] selftests/powerpc: Allow tests to extend their kill timeout Cyril Bur
2016-09-05 23:44 ` [PATCH v4 12/20] selftests/powerpc: Add TM tcheck helpers in C Cyril Bur
2016-09-05 23:44 ` [PATCH v4 13/20] selftests/powerpc: Check that signals always get delivered Cyril Bur
2016-09-05 23:44 ` [PATCH v4 14/20] selftests/powerpc: Add checks for transactional GPRs in signal contexts Cyril Bur
2016-09-05 23:44 ` [PATCH v4 15/20] selftests/powerpc: Add checks for transactional FPUs " Cyril Bur
2016-09-05 23:44 ` [PATCH v4 16/20] selftests/powerpc: Add checks for transactional VMXs " Cyril Bur
2016-09-05 23:44 ` [PATCH v4 17/20] selftests/powerpc: Add checks for transactional VSXs " Cyril Bur
2016-09-05 23:44 ` [PATCH v4 18/20] powerpc: tm: Always use fp_state and vr_state to store live registers Cyril Bur
2016-09-05 23:44 ` [PATCH v4 19/20] powerpc: tm: Rename transct_(*) to ck(\1)_state Cyril Bur
2016-09-05 23:44 ` [PATCH v4 20/20] powerpc: Remove do_load_up_transact_{fpu,altivec} Cyril Bur

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=20160905234448.5866-3-cyrilbur@gmail.com \
    --to=cyrilbur@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=wei.guo.simon@gmail.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).