* [PATCH 06/17] powerpc: Add transactional memory paca scratch register to show_regs
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Add transactional memory paca scratch register to show_regs. This is useful
for debugging.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/paca.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/entry_64.S | 4 ++++
arch/powerpc/kernel/process.c | 3 +++
4 files changed, 9 insertions(+)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index c47d687..07e9851 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -137,6 +137,7 @@ struct paca_struct {
u8 irq_work_pending; /* IRQ_WORK interrupt while soft-disable */
u8 nap_state_lost; /* NV GPR values lost in power7_idle */
u64 sprg3; /* Saved user-visible sprg */
+ u64 tm_scratch; /* TM scratch area for reclaim */
#ifdef CONFIG_PPC_POWERNV
/* Pointer to OPAL machine check event structure set by the
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index b67e4c3..f9654b6 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -126,6 +126,7 @@ int main(void)
DEFINE(THREAD_TAR, offsetof(struct thread_struct, tar));
#endif
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ DEFINE(PACATMSCRATCH, offsetof(struct paca_struct, tm_scratch));
DEFINE(THREAD_TM_TFHAR, offsetof(struct thread_struct, tm_tfhar));
DEFINE(THREAD_TM_TEXASR, offsetof(struct thread_struct, tm_texasr));
DEFINE(THREAD_TM_TFIAR, offsetof(struct thread_struct, tm_tfiar));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 9ae8451..612ea13 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -785,6 +785,10 @@ fast_exception_return:
andc r4,r4,r0 /* r0 contains MSR_RI here */
mtmsrd r4,1
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ /* TM debug */
+ std r3, PACATMSCRATCH(r13) /* Stash returned-to MSR */
+#endif
/*
* r13 is our per cpu area, only restore it if we are returning to
* userspace the value stored in the stack frame may belong to
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index b0a0321..1cc4053 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -754,6 +754,9 @@ void show_regs(struct pt_regs * regs)
printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ printk("PACATMSCRATCH [%llx]\n", get_paca()->tm_scratch);
+#endif
show_stack(current, (unsigned long *) regs->gpr[1]);
if (!user_mode(regs))
show_instructions(regs);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 05/17] powerpc: Register defines for various transactional memory registers
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Defines for MSR bits and transactional memory related SPRs TFIAR, TEXASR and
TEXASRU.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/reg.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index e09ac51..7844c28 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -29,6 +29,10 @@
#define MSR_SF_LG 63 /* Enable 64 bit mode */
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
+#define MSR_TS_T_LG 34 /* Trans Mem state: Transactional */
+#define MSR_TS_S_LG 33 /* Trans Mem state: Suspended */
+#define MSR_TS_LG 33 /* Trans Mem state (2 bits) */
+#define MSR_TM_LG 32 /* Trans Mem Available */
#define MSR_VEC_LG 25 /* Enable AltiVec */
#define MSR_VSX_LG 23 /* Enable VSX */
#define MSR_POW_LG 18 /* Enable Power Management */
@@ -98,6 +102,25 @@
#define MSR_RI __MASK(MSR_RI_LG) /* Recoverable Exception */
#define MSR_LE __MASK(MSR_LE_LG) /* Little Endian */
+#define MSR_TM __MASK(MSR_TM_LG) /* Transactional Mem Available */
+#define MSR_TS_N 0 /* Non-transactional */
+#define MSR_TS_S __MASK(MSR_TS_S_LG) /* Transaction Suspended */
+#define MSR_TS_T __MASK(MSR_TS_T_LG) /* Transaction Transactional */
+#define MSR_TS_MASK (MSR_TS_T | MSR_TS_S) /* Transaction State bits */
+#define MSR_TM_ACTIVE(x) (((x) & MSR_TS_MASK) != 0) /* Transaction active? */
+#define MSR_TM_TRANSACTIONAL(x) (((x) & MSR_TS_MASK) == MSR_TS_T)
+#define MSR_TM_SUSPENDED(x) (((x) & MSR_TS_MASK) == MSR_TS_S)
+
+/* Reason codes describing kernel causes for transaction aborts. By
+ convention, bit0 is copied to TEXASR[56] (IBM bit 7) which is set if
+ the failure is persistent.
+*/
+#define TM_CAUSE_RESCHED 0xfe
+#define TM_CAUSE_TLBI 0xfc
+#define TM_CAUSE_FAC_UNAV 0xfa
+#define TM_CAUSE_SYSCALL 0xf9 /* Persistent */
+#define TM_CAUSE_MISC 0xf6
+
#if defined(CONFIG_PPC_BOOK3S_64)
#define MSR_64BIT MSR_SF
@@ -193,6 +216,10 @@
#define SPRN_UAMOR 0x9d /* User Authority Mask Override Register */
#define SPRN_AMOR 0x15d /* Authority Mask Override Register */
#define SPRN_ACOP 0x1F /* Available Coprocessor Register */
+#define SPRN_TFIAR 0x81 /* Transaction Failure Inst Addr */
+#define SPRN_TEXASR 0x82 /* Transaction EXception & Summary */
+#define SPRN_TEXASRU 0x83 /* '' '' '' Upper 32 */
+#define SPRN_TFHAR 0x80 /* Transaction Failure Handler Addr */
#define SPRN_CTRLF 0x088
#define SPRN_CTRLT 0x098
#define CTRL_CT 0xc0000000 /* current thread */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 04/17] powerpc: New macros for transactional memory support
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
This adds new macros for saving and restoring checkpointed architected state
from and to the thread_struct.
It also adds some debugging macros for when your brain explodes trying to debug
your transactional memory enabled kernel.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/ppc_asm.h | 83 ++++++++++++++++++++++++++++++++++
arch/powerpc/include/asm/processor.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 23 ++++++++++
arch/powerpc/kernel/fpu.S | 12 +++++
arch/powerpc/kernel/process.c | 7 +++
arch/powerpc/kernel/traps.c | 8 ++++
6 files changed, 134 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc_asm.h b/arch/powerpc/include/asm/ppc_asm.h
index c2d0e58..54219ce 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -123,6 +123,89 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_SPLPAR)
#define REST_16VRS(n,b,base) REST_8VRS(n,b,base); REST_8VRS(n+8,b,base)
#define REST_32VRS(n,b,base) REST_16VRS(n,b,base); REST_16VRS(n+16,b,base)
+/* Save/restore FPRs, VRs and VSRs from their checkpointed backups in
+ * thread_struct:
+ */
+#define SAVE_FPR_TRANSACT(n, base) stfd n,THREAD_TRANSACT_FPR0+ \
+ 8*TS_FPRWIDTH*(n)(base)
+#define SAVE_2FPRS_TRANSACT(n, base) SAVE_FPR_TRANSACT(n, base); \
+ SAVE_FPR_TRANSACT(n+1, base)
+#define SAVE_4FPRS_TRANSACT(n, base) SAVE_2FPRS_TRANSACT(n, base); \
+ SAVE_2FPRS_TRANSACT(n+2, base)
+#define SAVE_8FPRS_TRANSACT(n, base) SAVE_4FPRS_TRANSACT(n, base); \
+ SAVE_4FPRS_TRANSACT(n+4, base)
+#define SAVE_16FPRS_TRANSACT(n, base) SAVE_8FPRS_TRANSACT(n, base); \
+ SAVE_8FPRS_TRANSACT(n+8, base)
+#define SAVE_32FPRS_TRANSACT(n, base) SAVE_16FPRS_TRANSACT(n, base); \
+ SAVE_16FPRS_TRANSACT(n+16, base)
+
+#define REST_FPR_TRANSACT(n, base) lfd n,THREAD_TRANSACT_FPR0+ \
+ 8*TS_FPRWIDTH*(n)(base)
+#define REST_2FPRS_TRANSACT(n, base) REST_FPR_TRANSACT(n, base); \
+ REST_FPR_TRANSACT(n+1, base)
+#define REST_4FPRS_TRANSACT(n, base) REST_2FPRS_TRANSACT(n, base); \
+ REST_2FPRS_TRANSACT(n+2, base)
+#define REST_8FPRS_TRANSACT(n, base) REST_4FPRS_TRANSACT(n, base); \
+ REST_4FPRS_TRANSACT(n+4, base)
+#define REST_16FPRS_TRANSACT(n, base) REST_8FPRS_TRANSACT(n, base); \
+ REST_8FPRS_TRANSACT(n+8, base)
+#define REST_32FPRS_TRANSACT(n, base) REST_16FPRS_TRANSACT(n, base); \
+ REST_16FPRS_TRANSACT(n+16, base)
+
+
+#define SAVE_VR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VR0+(16*(n)); \
+ stvx n,b,base
+#define SAVE_2VRS_TRANSACT(n,b,base) SAVE_VR_TRANSACT(n,b,base); \
+ SAVE_VR_TRANSACT(n+1,b,base)
+#define SAVE_4VRS_TRANSACT(n,b,base) SAVE_2VRS_TRANSACT(n,b,base); \
+ SAVE_2VRS_TRANSACT(n+2,b,base)
+#define SAVE_8VRS_TRANSACT(n,b,base) SAVE_4VRS_TRANSACT(n,b,base); \
+ SAVE_4VRS_TRANSACT(n+4,b,base)
+#define SAVE_16VRS_TRANSACT(n,b,base) SAVE_8VRS_TRANSACT(n,b,base); \
+ SAVE_8VRS_TRANSACT(n+8,b,base)
+#define SAVE_32VRS_TRANSACT(n,b,base) SAVE_16VRS_TRANSACT(n,b,base); \
+ SAVE_16VRS_TRANSACT(n+16,b,base)
+
+#define REST_VR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VR0+(16*(n)); \
+ lvx n,b,base
+#define REST_2VRS_TRANSACT(n,b,base) REST_VR_TRANSACT(n,b,base); \
+ REST_VR_TRANSACT(n+1,b,base)
+#define REST_4VRS_TRANSACT(n,b,base) REST_2VRS_TRANSACT(n,b,base); \
+ REST_2VRS_TRANSACT(n+2,b,base)
+#define REST_8VRS_TRANSACT(n,b,base) REST_4VRS_TRANSACT(n,b,base); \
+ REST_4VRS_TRANSACT(n+4,b,base)
+#define REST_16VRS_TRANSACT(n,b,base) REST_8VRS_TRANSACT(n,b,base); \
+ REST_8VRS_TRANSACT(n+8,b,base)
+#define REST_32VRS_TRANSACT(n,b,base) REST_16VRS_TRANSACT(n,b,base); \
+ REST_16VRS_TRANSACT(n+16,b,base)
+
+
+#define SAVE_VSR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VSR0+(16*(n)); \
+ STXVD2X(n,R##base,R##b)
+#define SAVE_2VSRS_TRANSACT(n,b,base) SAVE_VSR_TRANSACT(n,b,base); \
+ SAVE_VSR_TRANSACT(n+1,b,base)
+#define SAVE_4VSRS_TRANSACT(n,b,base) SAVE_2VSRS_TRANSACT(n,b,base); \
+ SAVE_2VSRS_TRANSACT(n+2,b,base)
+#define SAVE_8VSRS_TRANSACT(n,b,base) SAVE_4VSRS_TRANSACT(n,b,base); \
+ SAVE_4VSRS_TRANSACT(n+4,b,base)
+#define SAVE_16VSRS_TRANSACT(n,b,base) SAVE_8VSRS_TRANSACT(n,b,base); \
+ SAVE_8VSRS_TRANSACT(n+8,b,base)
+#define SAVE_32VSRS_TRANSACT(n,b,base) SAVE_16VSRS_TRANSACT(n,b,base); \
+ SAVE_16VSRS_TRANSACT(n+16,b,base)
+
+#define REST_VSR_TRANSACT(n,b,base) li b,THREAD_TRANSACT_VSR0+(16*(n)); \
+ LXVD2X(n,R##base,R##b)
+#define REST_2VSRS_TRANSACT(n,b,base) REST_VSR_TRANSACT(n,b,base); \
+ REST_VSR_TRANSACT(n+1,b,base)
+#define REST_4VSRS_TRANSACT(n,b,base) REST_2VSRS_TRANSACT(n,b,base); \
+ REST_2VSRS_TRANSACT(n+2,b,base)
+#define REST_8VSRS_TRANSACT(n,b,base) REST_4VSRS_TRANSACT(n,b,base); \
+ REST_4VSRS_TRANSACT(n+4,b,base)
+#define REST_16VSRS_TRANSACT(n,b,base) REST_8VSRS_TRANSACT(n,b,base); \
+ REST_8VSRS_TRANSACT(n+8,b,base)
+#define REST_32VSRS_TRANSACT(n,b,base) REST_16VSRS_TRANSACT(n,b,base); \
+ REST_16VSRS_TRANSACT(n+16,b,base)
+
/* Save the lower 32 VSRs in the thread VSR region */
#define SAVE_VSR(n,b,base) li b,THREAD_VSR0+(16*(n)); STXVD2X(n,R##base,R##b)
#define SAVE_2VSRS(n,b,base) SAVE_VSR(n,b,base); SAVE_VSR(n+1,b,base)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index fc41ab3..7ff9eaa 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -152,6 +152,7 @@ typedef struct {
#define TS_FPROFFSET 0
#define TS_VSRLOWOFFSET 1
#define TS_FPR(i) fpr[i][TS_FPROFFSET]
+#define TS_TRANS_FPR(i) transact_fpr[i][TS_FPROFFSET]
struct thread_struct {
unsigned long ksp; /* Kernel stack pointer */
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index beddba4..b67e4c3 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -125,6 +125,29 @@ int main(void)
#ifdef CONFIG_PPC_BOOK3S_64
DEFINE(THREAD_TAR, offsetof(struct thread_struct, tar));
#endif
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ DEFINE(THREAD_TM_TFHAR, offsetof(struct thread_struct, tm_tfhar));
+ DEFINE(THREAD_TM_TEXASR, offsetof(struct thread_struct, tm_texasr));
+ DEFINE(THREAD_TM_TFIAR, offsetof(struct thread_struct, tm_tfiar));
+ DEFINE(PT_CKPT_REGS, offsetof(struct thread_struct, ckpt_regs));
+ DEFINE(THREAD_TRANSACT_VR0, offsetof(struct thread_struct,
+ transact_vr[0]));
+ DEFINE(THREAD_TRANSACT_VSCR, offsetof(struct thread_struct,
+ transact_vscr));
+ DEFINE(THREAD_TRANSACT_VRSAVE, offsetof(struct thread_struct,
+ transact_vrsave));
+ DEFINE(THREAD_TRANSACT_FPR0, offsetof(struct thread_struct,
+ transact_fpr[0]));
+ DEFINE(THREAD_TRANSACT_FPSCR, offsetof(struct thread_struct,
+ transact_fpscr));
+#ifdef CONFIG_VSX
+ DEFINE(THREAD_TRANSACT_VSR0, offsetof(struct thread_struct,
+ transact_fpr[0]));
+#endif
+ /* Local pt_regs on stack for Transactional Memory funcs. */
+ DEFINE(TM_FRAME_SIZE, STACK_FRAME_OVERHEAD +
+ sizeof(struct pt_regs) + 16);
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, local_flags));
diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S
index e0ada05..adb1551 100644
--- a/arch/powerpc/kernel/fpu.S
+++ b/arch/powerpc/kernel/fpu.S
@@ -35,6 +35,15 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
2: REST_32VSRS(n,c,base); \
3:
+#define __REST_32FPVSRS_TRANSACT(n,c,base) \
+BEGIN_FTR_SECTION \
+ b 2f; \
+END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
+ REST_32FPRS_TRANSACT(n,base); \
+ b 3f; \
+2: REST_32VSRS_TRANSACT(n,c,base); \
+3:
+
#define __SAVE_32FPVSRS(n,c,base) \
BEGIN_FTR_SECTION \
b 2f; \
@@ -45,9 +54,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX); \
3:
#else
#define __REST_32FPVSRS(n,b,base) REST_32FPRS(n, base)
+#define __REST_32FPVSRS_TRANSACT(n,b,base) REST_32FPRS(n, base)
#define __SAVE_32FPVSRS(n,b,base) SAVE_32FPRS(n, base)
#endif
#define REST_32FPVSRS(n,c,base) __REST_32FPVSRS(n,__REG_##c,__REG_##base)
+#define REST_32FPVSRS_TRANSACT(n,c,base) \
+ __REST_32FPVSRS_TRANSACT(n,__REG_##c,__REG_##base)
#define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base)
/*
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 96e31de..b0a0321 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -57,6 +57,13 @@
#include <linux/kprobes.h>
#include <linux/kdebug.h>
+/* Transactional Memory debug */
+#ifdef TM_DEBUG_SW
+#define TM_DEBUG(x...) printk(KERN_INFO x)
+#else
+#define TM_DEBUG(x...) do { } while(0)
+#endif
+
extern unsigned long _get_SP(void);
#ifndef CONFIG_SMP
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a008cf5..bd5de5d 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -78,6 +78,13 @@ EXPORT_SYMBOL(__debugger_break_match);
EXPORT_SYMBOL(__debugger_fault_handler);
#endif
+/* Transactional Memory trap debug */
+#ifdef TM_DEBUG_SW
+#define TM_DEBUG(x...) printk(KERN_INFO x)
+#else
+#define TM_DEBUG(x...) do { } while(0)
+#endif
+
/*
* Trap & Exception support
*/
@@ -350,6 +357,7 @@ static inline int check_io_access(struct pt_regs *regs)
exception is in the MSR. */
#define get_reason(regs) ((regs)->msr)
#define get_mc_reason(regs) ((regs)->msr)
+#define REASON_TM 0x200000
#define REASON_FP 0x100000
#define REASON_ILLEGAL 0x80000
#define REASON_PRIVILEGED 0x40000
--
1.7.10.4
^ permalink raw reply related
* [PATCH 03/17] powerpc: Add additional state needed for transactional memory to thread struct
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Set of new archtected state for saving away on context switch.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/processor.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 42ac53c..fc41ab3 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -246,6 +246,34 @@ struct thread_struct {
unsigned long spefscr; /* SPE & eFP status */
int used_spe; /* set if process has used spe */
#endif /* CONFIG_SPE */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+ u64 tm_tfhar; /* Transaction fail handler addr */
+ u64 tm_texasr; /* Transaction exception & summary */
+ u64 tm_tfiar; /* Transaction fail instr address reg */
+ unsigned long tm_orig_msr; /* Thread's MSR on ctx switch */
+ struct pt_regs ckpt_regs; /* Checkpointed registers */
+
+ /*
+ * Transactional FP and VSX 0-31 register set.
+ * NOTE: the sense of these is the opposite of the integer ckpt_regs!
+ *
+ * When a transaction is active/signalled/scheduled etc., *regs is the
+ * most recent set of/speculated GPRs with ckpt_regs being the older
+ * checkpointed regs to which we roll back if transaction aborts.
+ *
+ * However, fpr[] is the checkpointed 'base state' of FP regs, and
+ * transact_fpr[] is the new set of transactional values.
+ * VRs work the same way.
+ */
+ double transact_fpr[32][TS_FPRWIDTH];
+ struct {
+ unsigned int pad;
+ unsigned int val; /* Floating point status */
+ } transact_fpscr;
+ vector128 transact_vr[32] __attribute__((aligned(16)));
+ vector128 transact_vscr __attribute__((aligned(16)));
+ unsigned long transact_vrsave;
+#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
#ifdef CONFIG_KVM_BOOK3S_32_HANDLER
void* kvm_shadow_vcpu; /* KVM internal data */
#endif /* CONFIG_KVM_BOOK3S_32_HANDLER */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 02/17] powerpc: Add new instructions for transactional memory
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Here we define the new instructions we need for transactional memory in the
kernel. This is so we can support compiling with binutils that don't support
the new transactional memory instructions.
Transactional memory results in two sets of architected state (GPRs/VSRs
etc).
treclaim allows us to read the checkpointed state (from the tbegin) so that we
can store it away on a context switch. It does this by overwriting the exiting
architected state, so you have to save that away before you treclaim. treclaim
will also abort a transaction, so you can give a register value which contains
an abort reason.
trecheckpoint allows us to inject into the checkpointed state as if it were at
the tbegin. It does this by copying the current architected state into the
checkpointed state.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/ppc-opcode.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 0fd1928..8752bc8 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -129,6 +129,9 @@
#define PPC_INST_TLBSRX_DOT 0x7c0006a5
#define PPC_INST_XXLOR 0xf0000510
#define PPC_INST_XVCPSGNDP 0xf0000780
+#define PPC_INST_TRECHKPT 0x7c0007dd
+#define PPC_INST_TRECLAIM 0x7c00075d
+#define PPC_INST_TABORT 0x7c00071d
#define PPC_INST_NAP 0x4c000364
#define PPC_INST_SLEEP 0x4c0003a4
@@ -294,4 +297,11 @@
#define PPC_NAP stringify_in_c(.long PPC_INST_NAP)
#define PPC_SLEEP stringify_in_c(.long PPC_INST_SLEEP)
+/* Transactional memory instructions */
+#define TRECHKPT stringify_in_c(.long PPC_INST_TRECHKPT)
+#define TRECLAIM(r) stringify_in_c(.long PPC_INST_TRECLAIM \
+ | __PPC_RA(r))
+#define TABORT(r) stringify_in_c(.long PPC_INST_TABORT \
+ | __PPC_RA(r))
+
#endif /* _ASM_POWERPC_PPC_OPCODE_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 01/17] powerpc: Add new CPU feature bit for transactional memory
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1360729895-304-1-git-send-email-mikey@neuling.org>
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/cputable.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index 5f1938f..3636081 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -220,6 +220,13 @@ extern const char *powerpc_base_platform;
#define PPC_FEATURE_HAS_EFP_DOUBLE_COMP 0
#endif
+/* We only set the TM feature if the kernel was compiled with TM supprt */
+#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
+#define CPU_FTR_TM_COMP CPU_FTR_TM
+#else
+#define CPU_FTR_TM_COMP 0
+#endif
+
/* We need to mark all pages as being coherent if we're SMP or we have a
* 74[45]x and an MPC107 host bridge. Also 83xx and PowerQUICC II
* require it for PCI "streaming/prefetch" to work properly.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/17] powerpc: Hardware transactional memory support for POWER8
From: Michael Neuling @ 2013-02-13 4:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Michael Neuling, linuxppc-dev, Matt Evans
In-Reply-To: <1358488117-17363-1-git-send-email-mikey@neuling.org>
POWER8 implements hardware transactional memory support. This patch series
adds kernel support so that user programs can use this hardware transactional
memory and the new state is properly context switched. It is not currently
used by the kernel itself.
This patch series was originally developed by Matt Evans.
v3 changes:
Incorporate review from benh (offline conversation):
- Improve IRQ disabling for tm_reclaim
- Improve IRQ disabling for early fp/vmx/vsx unavail handling
- Change CONFIG option to add PPC (now PPC_TRANSACTIONAL_MEM)
- strip some unneeded #defines
- micro optimisation to asm in early fp/vmx/vsx
- srdi r0, r12, MSR_TS_LG
- andi. r0, r0, 3
+ rldicl. r0, r12, (64-MSR_TS_LG), (64-2)
- do tabort on unmap only when current is using TM
- removed unneeded patch which moved when writing MSR back to the stack
v2 changes:
Adds signal handling
Removes some code for detecting when to restore all register or not
Added tabort for local tlb invalidates
Rebased on benh's next tree
Basic overview of a POWER8 hardware transaction memory
=====================================================
Hardware transactional memory is a feature that enables a different form of
atomic memory access. Several new instructions are presented to delimit
transactions; transactions are guaranteed to either complete atomically or roll
back and undo any partial changes.
A simple transaction looks like this:
begin_move_money:
tbegin
beq abort_handler
ld r4, SAVINGS_ACCT(r3)
ld r5, CURRENT_ACCT(r3)
subi r5, r5, 1
addi r4, r4, 1
std r4, SAVINGS_ACCT(r3)
std r5, CURRENT_ACCT(r3)
tend
b continue
abort_handler:
... test for odd failures ...
/* Retry the transaction if it failed because it conflicted with
* someone else: */
b begin_move_money
The 'tbegin' instruction denotes the start point, and 'tend' the end point.
Between these points the processor is in 'Transactional' state; any memory
references will complete in one go if there are no conflicts with other
transactional or non-transactional accesses within the system. In this
example, the transaction completes as though it were normal straight-line code
IF no other processor has touched SAVINGS_ACCT(r3) or CURRENT_ACCT(r3); an
atomic move of money from the current account to the savings account has been
performed. Even though the normal ld/std instructions are used (note no
lwarx/stwcx), either *both* SAVINGS_ACCT(r3) and CURRENT_ACCT(r3) will be
updated, or neither will be updated.
If, in the meantime, there is a conflict with the locations accessed by the
transaction, the transaction will be aborted by the CPU. Register and memory
state will roll back to that at the 'tbegin', and control will continue from
'tbegin+4'. The branch to abort_handler will be taken this second time; the
abort handler can check the cause of the failure, and retry.
Checkpointed registers include all GPRs, FPRs, VRs/VSRs, LR, CCR/CR, CTR, FPCSR
and a few other status/flag regs;
A preliminary ISA for TM can be found here:
https://www.power.org/documentation/power-isa-transactional-memory/
--
1.7.10.4
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 4:17 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360718594.24612.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, February 13, 2013 12:03 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Michael Neuling; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > > To me this looks wrong. And this seems to works because the
> > > > thread->reg->msr is not actually used to write SRR1 (and
> > eventually
> > > > the thread MSR) when doing rfi to enter guest. Infact
> > > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper
> > MSR
> > > > (including FP set).
> > > >
> > > > But Yes, Scott is right person to comment, So let us wait for him
> > > > comment.
> > >
> > > I don't think it's actually a problem on 32-bit, since r9 is
> > modified but never
> > > actually used for anything.
> >
> > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and
> > then r9 is written back in srr1 ?
>=20
> What epilog? We're talking about the case where it's called from C code.
>=20
> When it's called from an exception handler, then r9 is used, but in that =
case
> it's also initialized before calling load_up_fpu, by the prolog.
>=20
> > > On 64-bit, though, there's a store to the caller's stack frame
> > > (yuck) which the kvm/booke.h caller is not prepared for.
> >
> > So if caller is using r12 then it can lead to come corruption, right ?
>=20
> No, r12 is a volatile register in the ABI, as is r9. The issue is that t=
he
> stack can be corrupted.
What do you mean by stack is corrupted?
My understanding is that when calling the assembly function from C function=
then stack frame will not be pushed and assembly function uses the caller =
stack frame. Example function1() calls function2() which calls assembly_ro=
utine()
functio1()=20
|---------------------|
| Stack Frame 1 |
| <function1 caller |
| registers etc> |
|---------------------|
Calls function 2
|----------------------|
| Stack Frame 2 |
| <function1 registers |
| etc > |
|----------------------|
| Stack Frame 1 |
| <function1 caller |
| registers etc> |
|----------------------|
calls assembly_routine();
Now no stack frame push; And the assembly_routine() changes register values=
saved in stack. So when stack will be unrolled then registers of function1=
() will get corrupted, right?
Thanks
-Bharat
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Benjamin Herrenschmidt @ 2013-02-13 3:46 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, paulus
In-Reply-To: <87sj50kian.fsf@linux.vnet.ibm.com>
On Wed, 2013-02-13 at 08:54 +0530, Aneesh Kumar K.V wrote:
> > A compile option ? Really ? Ugh...
>
> I actually wanted that to be done in Kconfig.cputype, but haven't found
> a nice way to do it. Considering we are switching between only two
> values, I was thinking an #ifdef would work.
No, we want to support all those processor types from a single kernel image.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Aneesh Kumar K.V @ 2013-02-13 3:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360701185.2035.10.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
>> + * Be careful with this value. This determines the VSID_MODULUS_* and that
>> + * need to be co-prime with VSID_MULTIPLIER*
>> + */
>> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
>> +/*
>> + * Even if cpu support 68 bits, we limit this to 66 because
>> + * we support only 2^19 context.
>> + */
>> +#define MAX_VIRTUAL_ADDR_BITS 66
>> +#else
>> +/* power4,power 5 and cell is 65 */
>> +#define MAX_VIRTUAL_ADDR_BITS 65
>> +#endif
>> +
>
> A compile option ? Really ? Ugh...
I actually wanted that to be done in Kconfig.cputype, but haven't found
a nice way to do it. Considering we are switching between only two
values, I was thinking an #ifdef would work.
-aneesh
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:26 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360718594.24612.21@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 6:53 AM
> To: Bhushan Bharat-R65777
> Cc: Wood Scott-B07421; Michael Neuling; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, February 13, 2013 12:03 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Michael Neuling; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > > To me this looks wrong. And this seems to works because the
> > > > thread->reg->msr is not actually used to write SRR1 (and
> > eventually
> > > > the thread MSR) when doing rfi to enter guest. Infact
> > > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper
> > MSR
> > > > (including FP set).
> > > >
> > > > But Yes, Scott is right person to comment, So let us wait for him
> > > > comment.
> > >
> > > I don't think it's actually a problem on 32-bit, since r9 is
> > modified but never
> > > actually used for anything.
> >
> > Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and
> > then r9 is written back in srr1 ?
>=20
> What epilog? We're talking about the case where it's called from C code
>=20
> When it's called from an exception handler, then r9 is used, but in that =
case
> it's also initialized before calling load_up_fpu, by the prolog.
Agree. Was just confirming the exception handler case.
>=20
> > > On 64-bit, though, there's a store to the caller's stack frame
> > > (yuck) which the kvm/booke.h caller is not prepared for.
> >
> > So if caller is using r12 then it can lead to come corruption, right ?
>=20
> No, r12 is a volatile register in the ABI, as is r9. The issue is that t=
he
> stack can be corrupted.
Ok, Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* Re: BOOKE KVM calling load_up_fpu from C?
From: Scott Wood @ 2013-02-13 1:23 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D065A3456@039-SN2MPN1-023.039d.mgd.msft.net>
On 02/12/2013 07:18:14 PM, Bhushan Bharat-R65777 wrote:
>=20
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, February 13, 2013 12:03 AM
> > To: Bhushan Bharat-R65777
> > Cc: Michael Neuling; Wood Scott-B07421; =20
> linuxppc-dev@lists.ozlabs.org
> > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> >
> > On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> > > To me this looks wrong. And this seems to works because the
> > > thread->reg->msr is not actually used to write SRR1 (and =20
> eventually
> > > the thread MSR) when doing rfi to enter guest. Infact
> > > Guest(shadow_msr) MSR is used as SRR1 and which will have proper =20
> MSR
> > > (including FP set).
> > >
> > > But Yes, Scott is right person to comment, So let us wait for him
> > > comment.
> >
> > I don't think it's actually a problem on 32-bit, since r9 is =20
> modified but never
> > actually used for anything.
>=20
> Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and =20
> then r9 is written back in srr1 ?
What epilog? We're talking about the case where it's called from C =20
code.
When it's called from an exception handler, then r9 is used, but in =20
that case it's also initialized before calling load_up_fpu, by the =20
prolog.
> > On 64-bit, though, there's a store to the caller's
> > stack frame (yuck) which the kvm/booke.h caller is not prepared for.
>=20
> So if caller is using r12 then it can lead to come corruption, right ?
No, r12 is a volatile register in the ABI, as is r9. The issue is that =20
the stack can be corrupted.
-Scott=
^ permalink raw reply
* RE: BOOKE KVM calling load_up_fpu from C?
From: Bhushan Bharat-R65777 @ 2013-02-13 1:18 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Michael Neuling, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1360693988.24612.4@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, February 13, 2013 12:03 AM
> To: Bhushan Bharat-R65777
> Cc: Michael Neuling; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: BOOKE KVM calling load_up_fpu from C?
>=20
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 =3D=3D the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>=20
> I don't think it's actually a problem on 32-bit, since r9 is modified but=
never
> actually used for anything.
Is not the epilog loads srr1 in r9 and load_up_fpu() changes r9 and then r9=
is written back in srr1 ?
> On 64-bit, though, there's a store to the caller's
> stack frame (yuck) which the kvm/booke.h caller is not prepared for.
So if caller is using r12 then it can lead to come corruption, right ?
> Indeed,
> book3s's kvmppc_load_up_fpu creates an interrupt-like stack frame, but do=
es not
> load r9 or r12.
>=20
> It would be really nice if assumptions like these were put in a code comm=
ent
> above load_up_fpu... and if we didn't have so many random differences be=
tween
> 32-bit and 64-bit. :-P
:)
Thanks
-Bharat
>=20
> -Scott
^ permalink raw reply
* [PATCH] powerpc: Apply early paca fixups to boot_paca and the boot cpu's paca
From: Michael Ellerman @ 2013-02-13 0:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: phileas-fogg
In commit 466921c we added a hack to set the paca data_offset to zero so
that per-cpu accesses would work on the boot cpu prior to per-cpu areas
being setup. This fixed a problem with lockdep touching per-cpu areas
very early in boot.
However if we combine CONFIG_LOCK_STAT=y with any of the PPC_EARLY_DEBUG
options, we can hit the same problem in udbg_early_init(). To avoid that
we need to set the data_offset of the boot_paca also. So factor out the
fixup logic and call it for both the boot_paca, and "the paca of the
boot cpu".
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6da881b..8d97eb4 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -156,6 +156,15 @@ early_param("smt-enabled", early_smt_enabled);
#define check_smt_enabled()
#endif /* CONFIG_SMP */
+/** Fix up paca fields required for the boot cpu */
+static void fixup_boot_paca(void)
+{
+ /* The boot cpu is started */
+ get_paca()->cpu_start = 1;
+ /* Allow percpu accesses to work until we setup percpu data */
+ get_paca()->data_offset = 0;
+}
+
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the "feature" of
@@ -185,6 +194,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
initialise_paca(&boot_paca, 0);
setup_paca(&boot_paca);
+ fixup_boot_paca();
/* Initialize lockdep early or else spinlocks will blow */
lockdep_init();
@@ -205,11 +215,7 @@ void __init early_setup(unsigned long dt_ptr)
/* Now we know the logical id of our boot cpu, setup the paca. */
setup_paca(&paca[boot_cpuid]);
-
- /* Fix up paca fields required for the boot cpu */
- get_paca()->cpu_start = 1;
- /* Allow percpu accesses to "work" until we setup percpu data */
- get_paca()->data_offset = 0;
+ fixup_boot_paca();
/* Probe the machine type */
probe_machine();
--
1.7.10.4
^ permalink raw reply related
* Re: BOOKE KVM calling load_up_fpu from C?
From: Michael Neuling @ 2013-02-12 22:51 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <1360693988.24612.4@snotra>
Scott Wood <scottwood@freescale.com> wrote:
> On 02/12/2013 03:01:07 AM, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > Sent: Tuesday, February 12, 2013 9:46 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > >
> > > Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Michael Neuling [mailto:mikey@neuling.org]
> > > > > Sent: Tuesday, February 12, 2013 9:16 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: BOOKE KVM calling load_up_fpu from C?
> > > > >
> > > > > Look further down...
> > > > >
> > > > > #ifdef CONFIG_PPC32
> > > > > mfspr r5,SPRN_SPRG_THREAD /* current
> > task's THREAD (phys) */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r9,r9,MSR_FP /* enable FP for
> > current */
> > > > > or r9,r9,r4
> > > > > #else
> > > > > ld r4,PACACURRENT(r13)
> > > > > addi r5,r4,THREAD /* Get THREAD */
> > > > > lwz r4,THREAD_FPEXC_MODE(r5)
> > > > > ori r12,r12,MSR_FP
> > > > > or r12,r12,r4
> > > > > std r12,_MSR(r1)
> > > > > #endif
> > > > >
> > > > > R12 is loaded with SRR1 in the exception prolog before
> > load_up_fpu is
> > > called.
> > > >
> > > > Yes it is SRR1 not MSR.
> > >
> > > Yes, SRR1 == the MSR of the user process, not the current MSR.
> > >
> > > > Also on 32bit it looks like that R9 is assumed to have SRR1.
> > >
> > > Yep that too.
> > >
> > > So any idea how it's suppose to work or is it broken?
> >
> > To me this looks wrong. And this seems to works because the
> > thread->reg->msr is not actually used to write SRR1 (and eventually
> > the thread MSR) when doing rfi to enter guest. Infact
> > Guest(shadow_msr) MSR is used as SRR1 and which will have proper MSR
> > (including FP set).
> >
> > But Yes, Scott is right person to comment, So let us wait for him
> > comment.
>
> I don't think it's actually a problem on 32-bit, since r9 is modified
> but never actually used for anything. On 64-bit, though, there's a
> store to the caller's stack frame (yuck) which the kvm/booke.h caller
> is not prepared for. Indeed, book3s's kvmppc_load_up_fpu creates an
> interrupt-like stack frame, but does not load r9 or r12.
Yep.
> It would be really nice if assumptions like these were put in a code
> comment above load_up_fpu... and if we didn't have so many random
> differences between 32-bit and 64-bit. :-P
Yep.. I won't NACK that patch when you send it :-)
It was pretty much assumed that load_up_fpu was going to be called right
after the exception prolog. Calling it any other way was going to be
tricky.
Mikey
^ permalink raw reply
* Re: [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:16 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360674338-12776-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 14:05:38 +0100
> v3:
> - Use of_get_mac_address() instead of of_get_property()
Just to clarify, I applied this version (v3), not v2 (which I
just replied to with "applied").
^ permalink raw reply
* Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: David Miller @ 2013-02-12 21:15 UTC (permalink / raw)
To: sr; +Cc: netdev, agust, linuxppc-dev
In-Reply-To: <1360660088-27464-1-git-send-email-sr@denx.de>
From: Stefan Roese <sr@denx.de>
Date: Tue, 12 Feb 2013 10:08:08 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the DT as it should be done here.
>
> The following priority is now used to read the MAC address:
>
> 1) First, try OF node MAC address, if not present or invalid, then:
>
> 2) Read from MAC address registers, if invalid, then:
>
> 3) Log a warning message, and choose a random MAC address.
>
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot
> version without FEC initialization before Linux booting for
> boot speedup.
>
> Additionally a status line is now be printed upon successful
> driver probing, also displaying this MAC address.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Make context bits depend on virtual addr size.
From: Benjamin Herrenschmidt @ 2013-02-12 20:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, paulus
In-Reply-To: <1360693905-23503-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Wed, 2013-02-13 at 00:01 +0530, Aneesh Kumar K.V wrote:
> + * Be careful with this value. This determines the VSID_MODULUS_* and that
> + * need to be co-prime with VSID_MULTIPLIER*
> + */
> +#if defined(CONFIG_POWER6_CPU) || defined(CONFIG_POWER7_CPU)
> +/*
> + * Even if cpu support 68 bits, we limit this to 66 because
> + * we support only 2^19 context.
> + */
> +#define MAX_VIRTUAL_ADDR_BITS 66
> +#else
> +/* power4,power 5 and cell is 65 */
> +#define MAX_VIRTUAL_ADDR_BITS 65
> +#endif
> +
A compile option ? Really ? Ugh...
Ben.
^ permalink raw reply
* Re: [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
From: Kumar Gala @ 2013-02-12 20:09 UTC (permalink / raw)
To: Timur Tabi
Cc: Scott Wood, Stef van Os, linuxppc-dev@lists.ozlabs.org,
Paul Mackerras
In-Reply-To: <510FD412.4000505@calxeda.com>
On Feb 4, 2013, at 9:30 AM, Timur Tabi wrote:
> On 02/03/2013 01:39 PM, Stef van Os wrote:
>=20
>> + pci0: pci@fe0008000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci1: pci@fe0009000 {
>> + status =3D "disabled";
>> + };
>> +
>> + pci2: pcie@fe000a000 {
>> + status =3D "disabled";
>> + };
>=20
> I was hoping you'd follow my example and include a comment indicating =
why the PCI devices are all disabled.
>=20
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint svid, phid1;
>=20
> Please don't used unsized integers for hardware registers.
>=20
> uint32_t svid, phid1;
Stef,
If you'd like this included for 3.9, please make the minor updates.
thanks
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:07 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCHv1] crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
From: Kumar Gala @ 2013-02-12 20:04 UTC (permalink / raw)
To: Vakul Garg; +Cc: devicetree-discuss, linuxppc-dev, linux-crypto
In-Reply-To: <1358925668-10330-1-git-send-email-vakul@freescale.com>
On Jan 23, 2013, at 1:21 AM, Vakul Garg wrote:
> This new property defines the era of the particular SEC version.
> The compatible property in device tree "crypto" node has been updated
> not to contain SEC era numbers.
>
> Signed-off-by: Vakul Garg <vakul@freescale.com>
> ---
> Changelog:
> 1. Marked fsl,sec-era as 'optional'.
>
> .../devicetree/bindings/crypto/fsl-sec4.txt | 12 +++++++++---
> 1 files changed, 9 insertions(+), 3 deletions(-)
applied to next.
I assume this supersedes http://patchwork.ozlabs.org/patch/204431/
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <1354318502-367-1-git-send-email-kim.phillips@freescale.com>
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote:
> arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not =
declared. Should it be static?
> arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in =
argument 1 (different base types)
> arch/powerpc/sysdev/fsl_msi.c:138:40: expected restricted __be64 =
const [usertype] *p
> arch/powerpc/sysdev/fsl_msi.c:138:40: got unsigned long long const =
[usertype] *[assigned] reg
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH -next] powerpc/85xx: use for_each_compatible_node() macro
From: Kumar Gala @ 2013-02-12 20:02 UTC (permalink / raw)
To: Wei Yongjun
Cc: devicetree-discuss, linux-kernel, rob.herring, yongjun_wei,
paulus, linuxppc-dev
In-Reply-To: <CAPgLHd_esknTwVv4EeehwSJz6ee5eFJ+zf6xntH-vaNwdxkrvg@mail.gmail.com>
On Dec 3, 2012, at 7:36 AM, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Use for_each_compatible_node() macro instead of open coding it.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: split sbc8548 dts file into pre and post chunks
From: Kumar Gala @ 2013-02-12 20:01 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1358972013-5271-2-git-send-email-paul.gortmaker@windriver.com>
On Jan 23, 2013, at 2:13 PM, Paul Gortmaker wrote:
> Updates to u-boot allow this board to boot off of either
> the 8MB soldered on flash, or the 64MB SODIMM flash.
>=20
> This is achieved by changing JP12 and SW2.8 which in turn
> swaps which flash device appears on /CS0 and /CS6 respectively.
>=20
> Since the flash devices are not the same size, this also
> changes the MTD memory map layout on the local bus.
>=20
> Here we split the common chunks out into a pre and post
> include, so they can be reused by an upcoming "alternative
> boot" dts file; leaving only the local bus chunk behind.
>=20
> No content changes are made at this point - it is just purely
> the move to using include files.
>=20
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 =
+++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 ++++++
> arch/powerpc/boot/dts/sbc8548.dts | 322 =
+-------------------------------
> 3 files changed, 351 insertions(+), 318 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi
> create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi
applied 1-4 to next
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree
From: Gala Kumar-B11780 @ 2013-02-12 20:01 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev@ozlabs.org, Wood Scott-B07421, Yoder Stuart-B08248
In-Reply-To: <1358462073-2558-2-git-send-email-timur@tabi.org>
On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote:
> From: Timur Tabi <timur@freescale.com>
>=20
> The PAMU caches use the LIODNs to determine which cache lines hold the
> entries for the corresponding LIODs. The LIODNs must therefore be
> carefully assigned to avoid cache thrashing -- two active LIODs with
> LIODNs that put them in the same cache line.
>=20
> Currently, LIODNs are statically assigned by U-Boot, but this has
> limitations. LIODNs are assigned even for devices that may be disabled
> or unused by the kernel. Static assignments also do not allow for device
> drivers which may know which LIODs can be used simultaneously. In
> other words, we really should assign LIODNs dynamically in Linux.
>=20
> To do that, we need to describe the PAMU device and cache topologies in
> the device trees.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/guts.txt | 14 ++-
> .../devicetree/bindings/powerpc/fsl/pamu.txt | 142 +++++++++++++++=
+++++
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 87 +++++++++++--
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 68 +++++++++-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 92 +++++++++++--
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 92 +++++++++++--
> 7 files changed, 533 insertions(+), 49 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
applied to next
- k=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox