* Re: linux-next: build failure after merge of the powerpc tree
From: Christophe Leroy @ 2019-02-22 7:37 UTC (permalink / raw)
To: Stephen Rothwell, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190222181403.4ce373bd@canb.auug.org.au>
Le 22/02/2019 à 08:14, Stephen Rothwell a écrit :
> Hi all,
>
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> make[4]: *** No rule to make target 'arch/powerpc/mm/ptdump/core.o', needed by 'arch/powerpc/mm/ptdump/built-in.a'.
>
> Caused by commit
>
> 5df1cfa43394 ("powerpc: Move page table dump files in a dedicated subdirectory")
>
> I have reverted that commit for today.
>
In the Makefile, replace core.o by ptdump.o (or rename the file ptdump.c
to core.c). Michael, what was your intention ?
Christophe
^ permalink raw reply
* linux-next: build failure after merge of the powerpc tree
From: Stephen Rothwell @ 2019-02-22 7:14 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 412 bytes --]
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) failed like this:
make[4]: *** No rule to make target 'arch/powerpc/mm/ptdump/core.o', needed by 'arch/powerpc/mm/ptdump/built-in.a'.
Caused by commit
5df1cfa43394 ("powerpc: Move page table dump files in a dedicated subdirectory")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v2 6/6] powerpc sstep: Add support for modsd, modud instructions
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Modulo Signed Doubleword (modsd)
* Modulo Unsigned Doubleword (modud)
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 9c65fb1da298..3d33fb509ef4 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1704,7 +1704,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
(int) regs->gpr[rb];
goto arith_done;
-
+#ifdef __powerpc64__
+ case 265: /* modud */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = regs->gpr[ra] % regs->gpr[rb];
+ goto compute_done;
+#endif
case 266: /* add */
op->val = regs->gpr[ra] + regs->gpr[rb];
goto arith_done;
@@ -1756,7 +1762,14 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
}
return -1;
-
+#ifdef __powerpc64__
+ case 777: /* modsd */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (long int) regs->gpr[ra] %
+ (long int) regs->gpr[rb];
+ goto compute_done;
+#endif
case 779: /* modsw */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
return -1;
--
2.19.2
^ permalink raw reply related
* [PATCH v2 5/6] powerpc sstep: Add support for modsw, moduw instructions
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, PrasannaKumar Muralidharan, paulus, naveen.n.rao,
linuxppc-dev
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
From: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
This adds emulation support for the following integer instructions:
* Modulo Signed Word (modsw)
* Modulo Unsigned Word (moduw)
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 742298bdf30b..9c65fb1da298 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1708,6 +1708,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
case 266: /* add */
op->val = regs->gpr[ra] + regs->gpr[rb];
goto arith_done;
+
+ case 267: /* moduw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (unsigned int) regs->gpr[ra] %
+ (unsigned int) regs->gpr[rb];
+ goto compute_done;
#ifdef __powerpc64__
case 457: /* divdu */
op->val = regs->gpr[ra] / regs->gpr[rb];
@@ -1750,6 +1757,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
return -1;
+ case 779: /* modsw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (int) regs->gpr[ra] %
+ (int) regs->gpr[rb];
+ goto compute_done;
+
/*
* Logical instructions
--
2.19.2
^ permalink raw reply related
* [PATCH v2 4/6] powerpc sstep: Add support for extswsli instruction
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Extend-Sign Word and Shift Left Immediate (extswsli[.])
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 94189da4c159..742298bdf30b 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1935,6 +1935,20 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
op->xerval &= ~XER_CA;
set_ca32(op, op->xerval & XER_CA);
goto logical_done;
+
+ case 890: /* extswsli with sh_5 = 0 */
+ case 891: /* extswsli with sh_5 = 1 */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->type = COMPUTE + SETREG;
+ sh = rb | ((instr & 2) << 4);
+ val = (signed int) regs->gpr[rd];
+ if (sh)
+ op->val = ROTATE(val, sh) & MASK64(0, 63 - sh);
+ else
+ op->val = val;
+ goto logical_done;
+
#endif /* __powerpc64__ */
/*
--
2.19.2
^ permalink raw reply related
* [PATCH v2 3/6] powerpc sstep: Add support for cnttzw, cnttzd instructions
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Count Trailing Zeros Word (cnttzw[.])
* Count Trailing Zeros Doubleword (cnttzd[.])
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index ab575e02f9b8..94189da4c159 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1819,6 +1819,20 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
case 506: /* popcntd */
do_popcnt(regs, op, regs->gpr[rd], 64);
goto logical_done_nocc;
+#endif
+ case 538: /* cnttzw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ val = (unsigned int) regs->gpr[rd];
+ op->val = (val ? __builtin_ctz(val) : 32);
+ goto logical_done;
+#ifdef __powerpc64__
+ case 570: /* cnttzd */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ val = regs->gpr[rd];
+ op->val = (val ? __builtin_ctzl(val) : 64);
+ goto logical_done;
#endif
case 922: /* extsh */
op->val = (signed short) regs->gpr[rd];
--
2.19.2
^ permalink raw reply related
* [PATCH v2 2/6] powerpc: sstep: Add support for darn instruction
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Deliver A Random Number (darn)
As suggested by Michael, this uses a raw .long for specifying the
instruction word when using inline assembly to retain compatibility
with older binutils.
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 67e69ebd6c00..ab575e02f9b8 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1728,6 +1728,28 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
(int) regs->gpr[rb];
goto arith_done;
+ case 755: /* darn */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ switch (ra & 0x3) {
+ case 0:
+ /* 32-bit conditioned */
+ asm volatile(PPC_DARN(%0, 0) : "=r" (op->val));
+ goto compute_done;
+
+ case 1:
+ /* 64-bit conditioned */
+ asm volatile(PPC_DARN(%0, 1) : "=r" (op->val));
+ goto compute_done;
+
+ case 2:
+ /* 64-bit raw */
+ asm volatile(PPC_DARN(%0, 2) : "=r" (op->val));
+ goto compute_done;
+ }
+
+ return -1;
+
/*
* Logical instructions
--
2.19.2
^ permalink raw reply related
* [PATCH v2 1/6] powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Multiply-Add High Doubleword (maddhd)
* Multiply-Add High Doubleword Unsigned (maddhdu)
* Multiply-Add Low Doubleword (maddld)
As suggested by Michael, this uses a raw .long for specifying the
instruction word when using inline assembly to retain compatibility
with older binutils.
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 15 +++++++++++-
arch/powerpc/lib/sstep.c | 35 ++++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 19a8834e0398..d0b2d8534a62 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -334,6 +334,9 @@
#define PPC_INST_MULLW 0x7c0001d6
#define PPC_INST_MULHWU 0x7c000016
#define PPC_INST_MULLI 0x1c000000
+#define PPC_INST_MADDHD 0x10000030
+#define PPC_INST_MADDHDU 0x10000031
+#define PPC_INST_MADDLD 0x10000033
#define PPC_INST_DIVWU 0x7c000396
#define PPC_INST_DIVD 0x7c0003d2
#define PPC_INST_RLWINM 0x54000000
@@ -376,6 +379,7 @@
/* macros to insert fields into opcodes */
#define ___PPC_RA(a) (((a) & 0x1f) << 16)
#define ___PPC_RB(b) (((b) & 0x1f) << 11)
+#define ___PPC_RC(c) (((c) & 0x1f) << 6)
#define ___PPC_RS(s) (((s) & 0x1f) << 21)
#define ___PPC_RT(t) ___PPC_RS(t)
#define ___PPC_R(r) (((r) & 0x1) << 16)
@@ -395,7 +399,7 @@
#define __PPC_WS(w) (((w) & 0x1f) << 11)
#define __PPC_SH(s) __PPC_WS(s)
#define __PPC_SH64(s) (__PPC_SH(s) | (((s) & 0x20) >> 4))
-#define __PPC_MB(s) (((s) & 0x1f) << 6)
+#define __PPC_MB(s) ___PPC_RC(s)
#define __PPC_ME(s) (((s) & 0x1f) << 1)
#define __PPC_MB64(s) (__PPC_MB(s) | ((s) & 0x20))
#define __PPC_ME64(s) __PPC_MB64(s)
@@ -437,6 +441,15 @@
#define PPC_STQCX(t, a, b) stringify_in_c(.long PPC_INST_STQCX | \
___PPC_RT(t) | ___PPC_RA(a) | \
___PPC_RB(b))
+#define PPC_MADDHD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDHD | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
+#define PPC_MADDHDU(t, a, b, c) stringify_in_c(.long PPC_INST_MADDHDU | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
+#define PPC_MADDLD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDLD | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \
___PPC_RB(b))
#define PPC_MSGSYNC stringify_in_c(.long PPC_INST_MSGSYNC)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index d81568f783e5..67e69ebd6c00 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1169,7 +1169,7 @@ static nokprobe_inline int trap_compare(long v1, long v2)
int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
unsigned int instr)
{
- unsigned int opcode, ra, rb, rd, spr, u;
+ unsigned int opcode, ra, rb, rc, rd, spr, u;
unsigned long int imm;
unsigned long int val, val2;
unsigned int mb, me, sh;
@@ -1292,6 +1292,7 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
rd = (instr >> 21) & 0x1f;
ra = (instr >> 16) & 0x1f;
rb = (instr >> 11) & 0x1f;
+ rc = (instr >> 6) & 0x1f;
switch (opcode) {
#ifdef __powerpc64__
@@ -1305,6 +1306,38 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
goto trap;
return 1;
+#ifdef __powerpc64__
+ case 4:
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+
+ switch (instr & 0x3f) {
+ case 48: /* maddhd */
+ asm volatile(PPC_MADDHD(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+
+ case 49: /* maddhdu */
+ asm volatile(PPC_MADDHDU(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+
+ case 51: /* maddld */
+ asm volatile(PPC_MADDLD(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+ }
+
+ /*
+ * There are other instructions from ISA 3.0 with the same
+ * primary opcode which do not have emulation support yet.
+ */
+ return -1;
+#endif
+
case 7: /* mulli */
op->val = regs->gpr[ra] * (short) instr;
goto compute_done;
--
2.19.2
^ permalink raw reply related
* [PATCH v2 0/6] powerpc: sstep: Extend instruction emulation support
From: Sandipan Das @ 2019-02-22 6:54 UTC (permalink / raw)
To: mpe; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
This series adds emulation support for some additional ISA 3.0
instructions, most of which are now generated by a recent compiler
(e.g. gcc-8.x) when building the kernel with CONFIG_POWER9_CPU=y.
Changelog:
v1 -> v2:
- Use a conservative approach when using the multiply-add and
darn instructions via inline assembly because older binutils
may not be able to recognize them (as pointed out by Michael).
PrasannaKumar Muralidharan (1):
powerpc sstep: Add support for modsw, moduw instructions
Sandipan Das (5):
powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions
powerpc: sstep: Add support for darn instruction
powerpc sstep: Add support for cnttzw, cnttzd instructions
powerpc sstep: Add support for extswsli instruction
powerpc sstep: Add support for modsd, modud instructions
arch/powerpc/include/asm/ppc-opcode.h | 15 +++-
arch/powerpc/lib/sstep.c | 114 +++++++++++++++++++++++++-
2 files changed, 126 insertions(+), 3 deletions(-)
--
2.19.2
^ permalink raw reply
* [PATCH v2 6/6] powerpc sstep: Add support for modsd, modud instructions
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Modulo Signed Doubleword (modsd)
* Modulo Unsigned Doubleword (modud)
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 9c65fb1da298..3d33fb509ef4 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1704,7 +1704,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
(int) regs->gpr[rb];
goto arith_done;
-
+#ifdef __powerpc64__
+ case 265: /* modud */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = regs->gpr[ra] % regs->gpr[rb];
+ goto compute_done;
+#endif
case 266: /* add */
op->val = regs->gpr[ra] + regs->gpr[rb];
goto arith_done;
@@ -1756,7 +1762,14 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
}
return -1;
-
+#ifdef __powerpc64__
+ case 777: /* modsd */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (long int) regs->gpr[ra] %
+ (long int) regs->gpr[rb];
+ goto compute_done;
+#endif
case 779: /* modsw */
if (!cpu_has_feature(CPU_FTR_ARCH_300))
return -1;
--
2.19.2
^ permalink raw reply related
* [PATCH v2 5/6] powerpc sstep: Add support for modsw, moduw instructions
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan
Cc: ravi.bangoria, PrasannaKumar Muralidharan, paulus, naveen.n.rao,
linuxppc-dev
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
From: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
This adds emulation support for the following integer instructions:
* Modulo Signed Word (modsw)
* Modulo Unsigned Word (moduw)
Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 742298bdf30b..9c65fb1da298 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1708,6 +1708,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
case 266: /* add */
op->val = regs->gpr[ra] + regs->gpr[rb];
goto arith_done;
+
+ case 267: /* moduw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (unsigned int) regs->gpr[ra] %
+ (unsigned int) regs->gpr[rb];
+ goto compute_done;
#ifdef __powerpc64__
case 457: /* divdu */
op->val = regs->gpr[ra] / regs->gpr[rb];
@@ -1750,6 +1757,13 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
return -1;
+ case 779: /* modsw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->val = (int) regs->gpr[ra] %
+ (int) regs->gpr[rb];
+ goto compute_done;
+
/*
* Logical instructions
--
2.19.2
^ permalink raw reply related
* [PATCH v2 4/6] powerpc sstep: Add support for extswsli instruction
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Extend-Sign Word and Shift Left Immediate (extswsli[.])
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 94189da4c159..742298bdf30b 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1935,6 +1935,20 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
op->xerval &= ~XER_CA;
set_ca32(op, op->xerval & XER_CA);
goto logical_done;
+
+ case 890: /* extswsli with sh_5 = 0 */
+ case 891: /* extswsli with sh_5 = 1 */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ op->type = COMPUTE + SETREG;
+ sh = rb | ((instr & 2) << 4);
+ val = (signed int) regs->gpr[rd];
+ if (sh)
+ op->val = ROTATE(val, sh) & MASK64(0, 63 - sh);
+ else
+ op->val = val;
+ goto logical_done;
+
#endif /* __powerpc64__ */
/*
--
2.19.2
^ permalink raw reply related
* [PATCH v2 3/6] powerpc sstep: Add support for cnttzw, cnttzd instructions
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Count Trailing Zeros Word (cnttzw[.])
* Count Trailing Zeros Doubleword (cnttzd[.])
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index ab575e02f9b8..94189da4c159 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1819,6 +1819,20 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
case 506: /* popcntd */
do_popcnt(regs, op, regs->gpr[rd], 64);
goto logical_done_nocc;
+#endif
+ case 538: /* cnttzw */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ val = (unsigned int) regs->gpr[rd];
+ op->val = (val ? __builtin_ctz(val) : 32);
+ goto logical_done;
+#ifdef __powerpc64__
+ case 570: /* cnttzd */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ val = regs->gpr[rd];
+ op->val = (val ? __builtin_ctzl(val) : 64);
+ goto logical_done;
#endif
case 922: /* extsh */
op->val = (signed short) regs->gpr[rd];
--
2.19.2
^ permalink raw reply related
* [PATCH v2 2/6] powerpc: sstep: Add support for darn instruction
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Deliver A Random Number (darn)
As suggested by Michael, this uses a raw .long for specifying the
instruction word when using inline assembly to retain compatibility
with older binutils.
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/lib/sstep.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index 67e69ebd6c00..ab575e02f9b8 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1728,6 +1728,28 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
(int) regs->gpr[rb];
goto arith_done;
+ case 755: /* darn */
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+ switch (ra & 0x3) {
+ case 0:
+ /* 32-bit conditioned */
+ asm volatile(PPC_DARN(%0, 0) : "=r" (op->val));
+ goto compute_done;
+
+ case 1:
+ /* 64-bit conditioned */
+ asm volatile(PPC_DARN(%0, 1) : "=r" (op->val));
+ goto compute_done;
+
+ case 2:
+ /* 64-bit raw */
+ asm volatile(PPC_DARN(%0, 2) : "=r" (op->val));
+ goto compute_done;
+ }
+
+ return -1;
+
/*
* Logical instructions
--
2.19.2
^ permalink raw reply related
* [PATCH v2 1/6] powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
In-Reply-To: <cover.1550817742.git.sandipan@linux.ibm.com>
This adds emulation support for the following integer instructions:
* Multiply-Add High Doubleword (maddhd)
* Multiply-Add High Doubleword Unsigned (maddhdu)
* Multiply-Add Low Doubleword (maddld)
As suggested by Michael, this uses a raw .long for specifying the
instruction word when using inline assembly to retain compatibility
with older binutils.
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 15 +++++++++++-
arch/powerpc/lib/sstep.c | 35 ++++++++++++++++++++++++++-
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 19a8834e0398..d0b2d8534a62 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -334,6 +334,9 @@
#define PPC_INST_MULLW 0x7c0001d6
#define PPC_INST_MULHWU 0x7c000016
#define PPC_INST_MULLI 0x1c000000
+#define PPC_INST_MADDHD 0x10000030
+#define PPC_INST_MADDHDU 0x10000031
+#define PPC_INST_MADDLD 0x10000033
#define PPC_INST_DIVWU 0x7c000396
#define PPC_INST_DIVD 0x7c0003d2
#define PPC_INST_RLWINM 0x54000000
@@ -376,6 +379,7 @@
/* macros to insert fields into opcodes */
#define ___PPC_RA(a) (((a) & 0x1f) << 16)
#define ___PPC_RB(b) (((b) & 0x1f) << 11)
+#define ___PPC_RC(c) (((c) & 0x1f) << 6)
#define ___PPC_RS(s) (((s) & 0x1f) << 21)
#define ___PPC_RT(t) ___PPC_RS(t)
#define ___PPC_R(r) (((r) & 0x1) << 16)
@@ -395,7 +399,7 @@
#define __PPC_WS(w) (((w) & 0x1f) << 11)
#define __PPC_SH(s) __PPC_WS(s)
#define __PPC_SH64(s) (__PPC_SH(s) | (((s) & 0x20) >> 4))
-#define __PPC_MB(s) (((s) & 0x1f) << 6)
+#define __PPC_MB(s) ___PPC_RC(s)
#define __PPC_ME(s) (((s) & 0x1f) << 1)
#define __PPC_MB64(s) (__PPC_MB(s) | ((s) & 0x20))
#define __PPC_ME64(s) __PPC_MB64(s)
@@ -437,6 +441,15 @@
#define PPC_STQCX(t, a, b) stringify_in_c(.long PPC_INST_STQCX | \
___PPC_RT(t) | ___PPC_RA(a) | \
___PPC_RB(b))
+#define PPC_MADDHD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDHD | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
+#define PPC_MADDHDU(t, a, b, c) stringify_in_c(.long PPC_INST_MADDHDU | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
+#define PPC_MADDLD(t, a, b, c) stringify_in_c(.long PPC_INST_MADDLD | \
+ ___PPC_RT(t) | ___PPC_RA(a) | \
+ ___PPC_RB(b) | ___PPC_RC(c))
#define PPC_MSGSND(b) stringify_in_c(.long PPC_INST_MSGSND | \
___PPC_RB(b))
#define PPC_MSGSYNC stringify_in_c(.long PPC_INST_MSGSYNC)
diff --git a/arch/powerpc/lib/sstep.c b/arch/powerpc/lib/sstep.c
index d81568f783e5..67e69ebd6c00 100644
--- a/arch/powerpc/lib/sstep.c
+++ b/arch/powerpc/lib/sstep.c
@@ -1169,7 +1169,7 @@ static nokprobe_inline int trap_compare(long v1, long v2)
int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
unsigned int instr)
{
- unsigned int opcode, ra, rb, rd, spr, u;
+ unsigned int opcode, ra, rb, rc, rd, spr, u;
unsigned long int imm;
unsigned long int val, val2;
unsigned int mb, me, sh;
@@ -1292,6 +1292,7 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
rd = (instr >> 21) & 0x1f;
ra = (instr >> 16) & 0x1f;
rb = (instr >> 11) & 0x1f;
+ rc = (instr >> 6) & 0x1f;
switch (opcode) {
#ifdef __powerpc64__
@@ -1305,6 +1306,38 @@ int analyse_instr(struct instruction_op *op, const struct pt_regs *regs,
goto trap;
return 1;
+#ifdef __powerpc64__
+ case 4:
+ if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ return -1;
+
+ switch (instr & 0x3f) {
+ case 48: /* maddhd */
+ asm volatile(PPC_MADDHD(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+
+ case 49: /* maddhdu */
+ asm volatile(PPC_MADDHDU(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+
+ case 51: /* maddld */
+ asm volatile(PPC_MADDLD(%0, %1, %2, %3) :
+ "=r" (op->val) : "r" (regs->gpr[ra]),
+ "r" (regs->gpr[rb]), "r" (regs->gpr[rc]));
+ goto compute_done;
+ }
+
+ /*
+ * There are other instructions from ISA 3.0 with the same
+ * primary opcode which do not have emulation support yet.
+ */
+ return -1;
+#endif
+
case 7: /* mulli */
op->val = regs->gpr[ra] * (short) instr;
goto compute_done;
--
2.19.2
^ permalink raw reply related
* [PATCH v2 0/6] powerpc: sstep: Extend instruction emulation support
From: Sandipan Das @ 2019-02-22 6:53 UTC (permalink / raw)
To: sandipan; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria
This series adds emulation support for some additional ISA 3.0
instructions, most of which are now generated by a recent compiler
(e.g. gcc-8.x) when building the kernel with CONFIG_POWER9_CPU=y.
Changelog:
v1 -> v2:
- Use a conservative approach when using the multiply-add and
darn instructions via inline assembly because older binutils
may not be able to recognize them (as pointed out by Michael).
PrasannaKumar Muralidharan (1):
powerpc sstep: Add support for modsw, moduw instructions
Sandipan Das (5):
powerpc: sstep: Add support for maddhd, maddhdu, maddld instructions
powerpc: sstep: Add support for darn instruction
powerpc sstep: Add support for cnttzw, cnttzd instructions
powerpc sstep: Add support for extswsli instruction
powerpc sstep: Add support for modsd, modud instructions
arch/powerpc/include/asm/ppc-opcode.h | 15 +++-
arch/powerpc/lib/sstep.c | 114 +++++++++++++++++++++++++-
2 files changed, 126 insertions(+), 3 deletions(-)
--
2.19.2
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: sstep: Add tests for compute type instructions
From: Sandipan Das @ 2019-02-22 6:49 UTC (permalink / raw)
To: Michael Ellerman; +Cc: naveen.n.rao, paulus, linuxppc-dev, ravi.bangoria, dja
In-Reply-To: <87r2c15r8w.fsf@concordia.ellerman.id.au>
Hi Michael,
On 21/02/19 4:43 PM, Michael Ellerman wrote:
> Sandipan Das <sandipan@linux.ibm.com> writes:
>> This enhances the current selftest framework for validating
>> the in-kernel instruction emulation infrastructure by adding
>> support for compute type instructions i.e. integer ALU-based
>> instructions. Originally, this framework was limited to only
>> testing load and store instructions.
>>
>> While most of the GPRs can be validated, support for SPRs is
>> limited to LR, CR and XER for now.
>>
>> When writing the test cases, one must ensure that the Stack
>> Pointer (GPR1) or the Thread Pointer (GPR13) are not touched
>> by any means as these are vital non-volatile registers.
>>
>> Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
>> ---
>> arch/powerpc/lib/Makefile | 3 +-
>> arch/powerpc/lib/test_emulate_step.c | 167 +++++++++++++++++-
>> .../lib/test_emulate_step_exec_instr.S | 150 ++++++++++++++++
>> 3 files changed, 315 insertions(+), 5 deletions(-)
>> create mode 100644 arch/powerpc/lib/test_emulate_step_exec_instr.S
>
> Hi Sandipan,
>
> Thanks for the exceptionally well written asm, I wish all our asm code
> was that neat and well commented :)
>
> I'd like to get this merged today so I tweaked it slightly when
> applying to use the new patch_site helpers we added recently, see diff
> below.
>
> cheers
>
>
Thanks for modernizing it :)
- Sandipan
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/64: Adjust order in pcibios_init()
From: Sam Bobroff @ 2019-02-22 5:33 UTC (permalink / raw)
To: Oliver; +Cc: linuxppc-dev
In-Reply-To: <CAOSf1CFezjdgu1idFXmGoXUof0kPyAFcii30MMXXiuoVj0mJ7w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4266 bytes --]
On Fri, Feb 22, 2019 at 03:31:57PM +1100, Oliver wrote:
> On Fri, Feb 22, 2019 at 2:24 PM Sam Bobroff <sbobroff@linux.ibm.com> wrote:
> >
> > Hey all,
> >
> > After some consideration, I've decided to post a v2 of this patch that
> > will make it a bit safer (although I haven't seen any problems with it)
> > and make it a little easier to refactor some of the EEH code that
> > interacts with the hooks.
>
> Can you be a little more specific?
Sure:
When the original patch moves pci_bus_add_devices() to after
pcibios_resource_survey(), this also causes the pcibios_fixup hook
to move, because it's called at the end of pcibios_resource_survey().
So pcibios_fixup would run before pcibios_bus_add_device and while I
don't think that will actually cause problems, there doesn't seem to be
any reason to change the order either. So, I think it would be better
to extract the pcibios_fixup hook out of pcibios_resource_survey() and
call it from pcibios_init after the devices are added, preserving that
ordering.
That's the general reasoning but more specifically, I want to refactor
the EEH code around adding devices, and it seems like I'm going to
need the handlers in that order so that pcibios_bus_add_device() can
probe for EEH support in devices before the EEH post init code needs to
know if any were found.
> > Cheers,
> > Sam.
> >
> > On Thu, Feb 14, 2019 at 04:14:42PM +1100, Sam Bobroff wrote:
> > > The pcibios_init() function for 64 bit PowerPC currently calls
> > > pci_bus_add_devices() before pcibios_resource_survey(), which seems
> > > incorrect because it adds devices and attempts to bind their drivers
> > > before allocating their resources (although no problems seem to be
> > > apparent).
> > >
> > > So move the call to pci_bus_add_devices() to after
> > > pcibios_resource_survey().
> > >
> > > This will also allow the ppc_md.pcibios_bus_add_device() hooks to
> > > perform actions that depend on PCI resources, both during rescanning
> > > (where this is already the case) and at boot time, which should
> > > support improvements and refactoring.
> > >
> > > Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
> > > ---
> > > Hi everyone,
> > >
> > > I've tested this on a P9 for both the host and a KVM guest, and the change
> > > hasn't caused any differences in PCI resource assignments or the general boot
> > > messages.
> > >
> > > I've also had a go at inspecting most of the code used by pci_bus_add_devices()
> > > and pcibios_resource_survey() and it doesn't look like there are going to be
> > > any changes in behaviour caused by reordering. It might be worth mentioning
> > > that the hotplug path (see pcibios_finish_adding_to_bus()) already does
> > > resource allocation before calling pci_bus_add_devices().
> > >
> > > However, it would be great if someone could test this change on some older
> > > hardware or comment on wether we should make the same change on 32 bit machines.
> > >
> > > Cheers,
> > > Sam.
> > >
> > > arch/powerpc/kernel/pci_64.c | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> > > index 9d8c10d55407..1ce28888dbdb 100644
> > > --- a/arch/powerpc/kernel/pci_64.c
> > > +++ b/arch/powerpc/kernel/pci_64.c
> > > @@ -58,14 +58,16 @@ static int __init pcibios_init(void)
> > > pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
> > >
> > > /* Scan all of the recorded PCI controllers. */
> > > - list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> > > + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> > > pcibios_scan_phb(hose);
> > > - pci_bus_add_devices(hose->bus);
> > > - }
> > >
> > > /* Call common code to handle resource allocation */
> > > pcibios_resource_survey();
> > >
> > > + /* Add devices. */
> > > + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> > > + pci_bus_add_devices(hose->bus);
> > > +
> > > printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
> > >
> > > return 0;
> > > --
> > > 2.19.0.2.gcad72f5712
> > >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/64s: Implement KUAP for Radix MMU
From: Nicholas Piggin @ 2019-02-22 5:14 UTC (permalink / raw)
To: linuxppc-dev, Russell Currey; +Cc: kernel-hardening
In-Reply-To: <20190221093601.27920-8-ruscur@russell.cc>
Russell Currey's on February 21, 2019 7:36 pm:
> Kernel Userspace Access Prevention utilises a feature of the Radix MMU
> which disallows read and write access to userspace addresses. By
> utilising this, the kernel is prevented from accessing user data from
> outside of trusted paths that perform proper safety checks, such as
> copy_{to/from}_user() and friends.
>
> Userspace access is disabled from early boot and is only enabled when
> performing an operation like copy_{to/from}_user(). The register that
> controls this (AMR) does not prevent userspace from accessing other
> userspace, so there is no need to save and restore when entering and
> exiting userspace.
>
> This feature has a slight performance impact which I roughly measured
> to be 3% slower in the worst case (performing 1GB of 1 byte
> read()/write() syscalls), and is gated behind the CONFIG_PPC_KUAP
> option for performance-critical builds.
>
> This feature can be tested by using the lkdtm driver (CONFIG_LKDTM=y)
> and performing the following:
>
> # (echo ACCESS_USERSPACE) > [debugfs]/provoke-crash/DIRECT
>
> If enabled, this should send SIGSEGV to the thread.
>
> A big limitation of the current implementation is that user access
> is left unlocked if an exception is taken while user access is unlocked
> (i.e. if an interrupt is taken during copy_to_user()). This should be
> resolved in future, and is why the state is tracked in the PACA even
> though nothing currently uses it.
Did you have an implementation for this in an earlier series?
What's happened to that? If the idea is to add things incrementally
that's fine.
> Signed-off-by: Russell Currey <ruscur@russell.cc>
> ---
> .../powerpc/include/asm/book3s/64/kup-radix.h | 36 +++++++++++++++++++
> arch/powerpc/include/asm/kup.h | 4 +++
> arch/powerpc/include/asm/mmu.h | 9 ++++-
> arch/powerpc/include/asm/reg.h | 1 +
> arch/powerpc/mm/pgtable-radix.c | 16 +++++++++
> arch/powerpc/mm/pkeys.c | 7 ++--
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> 7 files changed, 71 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/include/asm/book3s/64/kup-radix.h
>
> diff --git a/arch/powerpc/include/asm/book3s/64/kup-radix.h b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> new file mode 100644
> index 000000000000..5cfdea954418
> --- /dev/null
> +++ b/arch/powerpc/include/asm/book3s/64/kup-radix.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_POWERPC_KUP_RADIX_H
> +#define _ASM_POWERPC_KUP_RADIX_H
> +
> +#ifndef __ASSEMBLY__
> +#ifdef CONFIG_PPC_KUAP
> +#include <asm/reg.h>
> +/*
> + * We do have the ability to individually lock/unlock reads and writes rather
> + * than both at once, however it's a significant performance hit due to needing
> + * to do a read-modify-write, which adds a mfspr, which is slow. As a result,
> + * locking/unlocking both at once is preferred.
> + */
> +static inline void unlock_user_access(void __user *to, const void __user *from,
> + unsigned long size)
> +{
> + if (!mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + return;
> +
> + mtspr(SPRN_AMR, 0);
> + isync();
> + get_paca()->user_access_allowed = 1;
I think this is going to get corrupted when you context switch isn't
it? I would have thought a per thread flag would be easier, but maybe
that's difficult in your exception code... If you've got more code to
deal with it in a later patch, might be worth just moving all the
user_access_allowed stuff there.
Possibly you could add some debug warnings to catch double lock or
unpaired unlock? That could be removed or put under a CONFIG option
after it gets more testing.
> +}
> +
> +static inline void lock_user_access(void __user *to, const void __user *from,
> + unsigned long size)
> +{
> + if (!mmu_has_feature(MMU_FTR_RADIX_KUAP))
> + return;
> +
> + mtspr(SPRN_AMR, RADIX_AMR_LOCKED);
> + get_paca()->user_access_allowed = 0;
Without the isync here gives you some small window to execute user
accesses without faulting I think. If that's for performance I won't
complain, but a comment would be good.
Looks good though, no real complaints about the series.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/64: Adjust order in pcibios_init()
From: Oliver @ 2019-02-22 4:31 UTC (permalink / raw)
To: Sam Bobroff; +Cc: linuxppc-dev
In-Reply-To: <20190222032320.GA4334@tungsten.ozlabs.ibm.com>
On Fri, Feb 22, 2019 at 2:24 PM Sam Bobroff <sbobroff@linux.ibm.com> wrote:
>
> Hey all,
>
> After some consideration, I've decided to post a v2 of this patch that
> will make it a bit safer (although I haven't seen any problems with it)
> and make it a little easier to refactor some of the EEH code that
> interacts with the hooks.
Can you be a little more specific?
> Cheers,
> Sam.
>
> On Thu, Feb 14, 2019 at 04:14:42PM +1100, Sam Bobroff wrote:
> > The pcibios_init() function for 64 bit PowerPC currently calls
> > pci_bus_add_devices() before pcibios_resource_survey(), which seems
> > incorrect because it adds devices and attempts to bind their drivers
> > before allocating their resources (although no problems seem to be
> > apparent).
> >
> > So move the call to pci_bus_add_devices() to after
> > pcibios_resource_survey().
> >
> > This will also allow the ppc_md.pcibios_bus_add_device() hooks to
> > perform actions that depend on PCI resources, both during rescanning
> > (where this is already the case) and at boot time, which should
> > support improvements and refactoring.
> >
> > Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
> > ---
> > Hi everyone,
> >
> > I've tested this on a P9 for both the host and a KVM guest, and the change
> > hasn't caused any differences in PCI resource assignments or the general boot
> > messages.
> >
> > I've also had a go at inspecting most of the code used by pci_bus_add_devices()
> > and pcibios_resource_survey() and it doesn't look like there are going to be
> > any changes in behaviour caused by reordering. It might be worth mentioning
> > that the hotplug path (see pcibios_finish_adding_to_bus()) already does
> > resource allocation before calling pci_bus_add_devices().
> >
> > However, it would be great if someone could test this change on some older
> > hardware or comment on wether we should make the same change on 32 bit machines.
> >
> > Cheers,
> > Sam.
> >
> > arch/powerpc/kernel/pci_64.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> > index 9d8c10d55407..1ce28888dbdb 100644
> > --- a/arch/powerpc/kernel/pci_64.c
> > +++ b/arch/powerpc/kernel/pci_64.c
> > @@ -58,14 +58,16 @@ static int __init pcibios_init(void)
> > pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
> >
> > /* Scan all of the recorded PCI controllers. */
> > - list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> > + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> > pcibios_scan_phb(hose);
> > - pci_bus_add_devices(hose->bus);
> > - }
> >
> > /* Call common code to handle resource allocation */
> > pcibios_resource_survey();
> >
> > + /* Add devices. */
> > + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> > + pci_bus_add_devices(hose->bus);
> > +
> > printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
> >
> > return 0;
> > --
> > 2.19.0.2.gcad72f5712
> >
^ permalink raw reply
* Re: [PATCH 0/7] Kernel Userspace Protection for radix
From: Michael Ellerman @ 2019-02-22 3:46 UTC (permalink / raw)
To: Kees Cook, Russell Currey; +Cc: PowerPC, Nick Piggin, Kernel Hardening
In-Reply-To: <CAGXu5jL0ZOzTo2sXiWkgemcwHusX4YuM9b_9y-MZ2THuDoRC+g@mail.gmail.com>
Kees Cook <keescook@chromium.org> writes:
> On Thu, Feb 21, 2019 at 4:09 PM Russell Currey <ruscur@russell.cc> wrote:
>> On Thu, 2019-02-21 at 08:07 -0800, Kees Cook wrote:
>> > On Thu, Feb 21, 2019 at 1:36 AM Russell Currey <ruscur@russell.cc>
>> > wrote:
>> > > The first three patches of these series are from Christophe's work
>> > > and are
>> > > the bare minimum framework needed to implement the support for
>> > > radix.
>> > >
>> > > In patch 3, I have removed from Christophe's patch my
>> > > implementation of
>> > > the 64-bit exception handling code, since we don't have an answer
>> > > for
>> > > making nested exceptions work yet. This is mentioned in the final
>> > > KUAP
>> > > patch. Regardless, this is still a significant security
>> > > improvement
>> > > and greatly narrows the attack surface.
>> >
>> > Nice! Am I understanding correctly that with this series powerpc9 and
>> > later, using radix, will pass the lkdtm tests for KUAP and KUEP (i.e.
>> > EXEC_USERSPACE and ACCESS_USERSPACE)?
>>
>> Yes! We've had execution prevention for a while on radix (which is
>> default on POWER9) since 3b10d0095a1e, the only functional thing this
>> series does is allow disabling it with nosmep. This series adds access
>> prevention.
>
> Ah-ha; excellent. And CONFIG_PPC_RADIX_MMU is "default y" already. :)
Though on real hardware it doesn't really work yet, at least if there
are any idle states enabled.
Patch under discussion to fix it:
https://patchwork.ozlabs.org/patch/1038568/
cheers
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the dma-mapping tree
From: Michael Ellerman @ 2019-02-22 3:43 UTC (permalink / raw)
To: Stephen Rothwell, Benjamin Herrenschmidt, PowerPC,
Christoph Hellwig
Cc: Linux Next Mailing List, Linux Kernel Mailing List
In-Reply-To: <20190222091728.6d3d9877@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
> arch/powerpc/kernel/dma-swiotlb.c
>
> between commit:
>
> cfced786969c ("dma-mapping: remove the default map_resource implementation")
>
> from the dma-mapping tree and commit:
>
> 68005b67d15a ("powerpc/dma: use the generic direct mapping bypass")
>
> from the powerpc tree.
>
> I fixed it up (I just used the latter) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Thanks.
Christoph, I've put the powerpc dma changes in a topic branch if you
want to merge it to reduce the conflicts. Up to you.
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/dma
cheers
^ permalink raw reply
* Re: [PATCH v4 3/3] locking/rwsem: Optimize down_read_trylock()
From: Waiman Long @ 2019-02-22 3:28 UTC (permalink / raw)
To: Will Deacon
Cc: linux-ia64, linux-sh, Peter Zijlstra, linux-mips, H. Peter Anvin,
sparclinux, linux-riscv, linux-arch, linux-s390, Davidlohr Bueso,
linux-c6x-dev, linux-hexagon, x86, Ingo Molnar, uclinux-h8-devel,
linux-xtensa, Arnd Bergmann, linux-um, linux-m68k, openrisc,
Borislav Petkov, Thomas Gleixner, linux-arm-kernel, Tim Chen,
linux-parisc, Linus Torvalds, linux-kernel, linux-alpha,
nios2-dev, Andrew Morton, linuxppc-dev
In-Reply-To: <20190221141420.GC12696@fuggles.cambridge.arm.com>
On 02/21/2019 09:14 AM, Will Deacon wrote:
> On Wed, Feb 13, 2019 at 05:00:17PM -0500, Waiman Long wrote:
>> Modify __down_read_trylock() to optimize for an unlocked rwsem and make
>> it generate slightly better code.
>>
>> Before this patch, down_read_trylock:
>>
>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>> 0x0000000000000005 <+5>: jmp 0x18 <down_read_trylock+24>
>> 0x0000000000000007 <+7>: lea 0x1(%rdx),%rcx
>> 0x000000000000000b <+11>: mov %rdx,%rax
>> 0x000000000000000e <+14>: lock cmpxchg %rcx,(%rdi)
>> 0x0000000000000013 <+19>: cmp %rax,%rdx
>> 0x0000000000000016 <+22>: je 0x23 <down_read_trylock+35>
>> 0x0000000000000018 <+24>: mov (%rdi),%rdx
>> 0x000000000000001b <+27>: test %rdx,%rdx
>> 0x000000000000001e <+30>: jns 0x7 <down_read_trylock+7>
>> 0x0000000000000020 <+32>: xor %eax,%eax
>> 0x0000000000000022 <+34>: retq
>> 0x0000000000000023 <+35>: mov %gs:0x0,%rax
>> 0x000000000000002c <+44>: or $0x3,%rax
>> 0x0000000000000030 <+48>: mov %rax,0x20(%rdi)
>> 0x0000000000000034 <+52>: mov $0x1,%eax
>> 0x0000000000000039 <+57>: retq
>>
>> After patch, down_read_trylock:
>>
>> 0x0000000000000000 <+0>: callq 0x5 <down_read_trylock+5>
>> 0x0000000000000005 <+5>: xor %eax,%eax
>> 0x0000000000000007 <+7>: lea 0x1(%rax),%rdx
>> 0x000000000000000b <+11>: lock cmpxchg %rdx,(%rdi)
>> 0x0000000000000010 <+16>: jne 0x29 <down_read_trylock+41>
>> 0x0000000000000012 <+18>: mov %gs:0x0,%rax
>> 0x000000000000001b <+27>: or $0x3,%rax
>> 0x000000000000001f <+31>: mov %rax,0x20(%rdi)
>> 0x0000000000000023 <+35>: mov $0x1,%eax
>> 0x0000000000000028 <+40>: retq
>> 0x0000000000000029 <+41>: test %rax,%rax
>> 0x000000000000002c <+44>: jns 0x7 <down_read_trylock+7>
>> 0x000000000000002e <+46>: xor %eax,%eax
>> 0x0000000000000030 <+48>: retq
>>
>> By using a rwsem microbenchmark, the down_read_trylock() rate (with a
>> load of 10 to lengthen the lock critical section) on a x86-64 system
>> before and after the patch were:
>>
>> Before Patch After Patch
>> # of Threads rlock rlock
>> ------------ ----- -----
>> 1 14,496 14,716
>> 2 8,644 8,453
>> 4 6,799 6,983
>> 8 5,664 7,190
>>
>> On a ARM64 system, the performance results were:
>>
>> Before Patch After Patch
>> # of Threads rlock rlock
>> ------------ ----- -----
>> 1 23,676 24,488
>> 2 7,697 9,502
>> 4 4,945 3,440
>> 8 2,641 1,603
>>
>> For the uncontended case (1 thread), the new down_read_trylock() is a
>> little bit faster. For the contended cases, the new down_read_trylock()
>> perform pretty well in x86-64, but performance degrades at high
>> contention level on ARM64.
>>
>> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> kernel/locking/rwsem.h | 13 ++++++++-----
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/locking/rwsem.h b/kernel/locking/rwsem.h
>> index 45ee002..1f5775a 100644
>> --- a/kernel/locking/rwsem.h
>> +++ b/kernel/locking/rwsem.h
>> @@ -174,14 +174,17 @@ static inline int __down_read_killable(struct rw_semaphore *sem)
>>
>> static inline int __down_read_trylock(struct rw_semaphore *sem)
>> {
>> - long tmp;
>> + /*
>> + * Optimize for the case when the rwsem is not locked at all.
>> + */
>> + long tmp = RWSEM_UNLOCKED_VALUE;
>>
>> - while ((tmp = atomic_long_read(&sem->count)) >= 0) {
>> - if (tmp == atomic_long_cmpxchg_acquire(&sem->count, tmp,
>> - tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> + do {
>> + if (atomic_long_try_cmpxchg_acquire(&sem->count, &tmp,
>> + tmp + RWSEM_ACTIVE_READ_BIAS)) {
>> return 1;
>> }
>> - }
>> + } while (tmp >= 0);
> Nit: but I guess that should be RWSEM_UNLOCKED_VALUE instead of 0.
>
> Will
Using RWSEM_UNLOCKED_VALUE may be better. Anyway, it is not a big deal
as I am going to change this again in a later patch.
Thanks,
Longman
RWSEM_UNLOCKED_VALUE
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/64: Adjust order in pcibios_init()
From: Sam Bobroff @ 2019-02-22 3:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <f232553753fe148118646c9013a3d962c19b58ec.1550121250.git.sbobroff@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]
Hey all,
After some consideration, I've decided to post a v2 of this patch that
will make it a bit safer (although I haven't seen any problems with it)
and make it a little easier to refactor some of the EEH code that
interacts with the hooks.
Cheers,
Sam.
On Thu, Feb 14, 2019 at 04:14:42PM +1100, Sam Bobroff wrote:
> The pcibios_init() function for 64 bit PowerPC currently calls
> pci_bus_add_devices() before pcibios_resource_survey(), which seems
> incorrect because it adds devices and attempts to bind their drivers
> before allocating their resources (although no problems seem to be
> apparent).
>
> So move the call to pci_bus_add_devices() to after
> pcibios_resource_survey().
>
> This will also allow the ppc_md.pcibios_bus_add_device() hooks to
> perform actions that depend on PCI resources, both during rescanning
> (where this is already the case) and at boot time, which should
> support improvements and refactoring.
>
> Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
> ---
> Hi everyone,
>
> I've tested this on a P9 for both the host and a KVM guest, and the change
> hasn't caused any differences in PCI resource assignments or the general boot
> messages.
>
> I've also had a go at inspecting most of the code used by pci_bus_add_devices()
> and pcibios_resource_survey() and it doesn't look like there are going to be
> any changes in behaviour caused by reordering. It might be worth mentioning
> that the hotplug path (see pcibios_finish_adding_to_bus()) already does
> resource allocation before calling pci_bus_add_devices().
>
> However, it would be great if someone could test this change on some older
> hardware or comment on wether we should make the same change on 32 bit machines.
>
> Cheers,
> Sam.
>
> arch/powerpc/kernel/pci_64.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
> index 9d8c10d55407..1ce28888dbdb 100644
> --- a/arch/powerpc/kernel/pci_64.c
> +++ b/arch/powerpc/kernel/pci_64.c
> @@ -58,14 +58,16 @@ static int __init pcibios_init(void)
> pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
>
> /* Scan all of the recorded PCI controllers. */
> - list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> pcibios_scan_phb(hose);
> - pci_bus_add_devices(hose->bus);
> - }
>
> /* Call common code to handle resource allocation */
> pcibios_resource_survey();
>
> + /* Add devices. */
> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node)
> + pci_bus_add_devices(hose->bus);
> +
> printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
>
> return 0;
> --
> 2.19.0.2.gcad72f5712
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the swiotlb tree with the powerpc tree
From: Michael Ellerman @ 2019-02-22 3:17 UTC (permalink / raw)
To: Stephen Rothwell, Konrad Rzeszutek Wilk, Benjamin Herrenschmidt,
PowerPC
Cc: Dongli Zhang, Linux Next Mailing List, Linux Kernel Mailing List,
Christoph Hellwig
In-Reply-To: <20190222113624.2499244a@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi all,
>
> Today's linux-next merge of the swiotlb tree got a conflict in:
>
> kernel/dma/swiotlb.c
>
> between commit:
>
> feee96440c9c ("swiotlb: remove swiotlb_dma_supported")
>
> from the powerpc tree and commit:
>
> 71602fe6d4e9 ("swiotlb: add debugfs to track swiotlb buffer usage")
>
> from the swiotlb tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
OK thanks. That looks pretty harmless as far as conflicts go.
cheers
^ 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