RE: [PATCH v6 5/6] arm64: dts: add QorIQ LX2160A SoC support
> -Original Message-
> From: Li Yang
> Sent: Friday, October 26, 2018 1:19 AM
> To: Vabhav Sharma
> Cc: Sudeep Holla ; Scott Wood
> ; lkml ; open list:OPEN
> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; Rob Herring ; Mark
> Rutland ; linuxppc-dev d...@lists.ozlabs.org>; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE ; Michael Turquette
> ; sb...@kernel.org; Rafael J. Wysocki
> ; Viresh Kumar ; linux-clk
> ; linux...@vger.kernel.org; linux-kernel-
> ow...@vger.kernel.org; Catalin Marinas ; Will
> Deacon ; Greg Kroah-Hartman
> ; Arnd Bergmann ; Kate
> Stewart ; yamada.masah...@socionext.com;
> Shawn Guo ; Russell King ;
> Adrian Hunter ; Ulf Hansson
> ; Varun Sethi ; Udit Kumar
> ; Pankaj Bansal ; Ramneek
> Mehresh ; Ying Zhang
> ; Nipun Gupta ;
> Priyanka Jain ; Yogesh Narayan Gaur
> ; Sriram Dash ;
> Horia Geanta ; Ran Wang ;
> Yinbo Zhu
> Subject: Re: [PATCH v6 5/6] arm64: dts: add QorIQ LX2160A SoC support
>
> On Thu, Oct 25, 2018 at 2:03 AM Vabhav Sharma
> wrote:
> >
> > LX2160A SoC is based on Layerscape Chassis Generation 3.2 Architecture.
> >
> > LX2160A features an advanced 16 64-bit ARM v8 CortexA72 processor
> > cores in 8 cluster, CCN508, GICv3,two 64-bit DDR4 memory controller, 8
> > I2C controllers, 3 dspi, 2 esdhc,2 USB 3.0, mmu 500, 3 SATA, 4 PL011
> > SBSA UARTs etc.
> >
> > Signed-off-by: Ramneek Mehresh
> > Signed-off-by: Zhang Ying-22455
> > Signed-off-by: Nipun Gupta
> > Signed-off-by: Priyanka Jain
> > Signed-off-by: Yogesh Gaur
> > Signed-off-by: Sriram Dash
> > Signed-off-by: Vabhav Sharma
> > Signed-off-by: Horia Geanta
> > Signed-off-by: Ran Wang
> > Signed-off-by: Yinbo Zhu
> > ---
> > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 766
> > +
> > 1 file changed, 766 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > new file mode 100644
> > index 000..9fcfd48
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -0,0 +1,766 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) // // Device Tree
> > +Include file for Layerscape-LX2160A family SoC.
> > +//
> > +// Copyright 2018 NXP
> > +
> > +#include
> > +#include
> > +
> > +/memreserve/ 0x8000 0x0001;
> > +
> > +/ {
> > + compatible = "fsl,lx2160a";
> > + interrupt-parent = <&gic>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + // 8 clusters having 2 Cortex-A72 cores each
> > + cpu@0 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + enable-method = "psci";
> > + reg = <0x0>;
> > + clocks = <&clockgen 1 0>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster0_l2>;
> > + };
> > +
> > + cpu@1 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + enable-method = "psci";
> > + reg = <0x1>;
> > + clocks = <&clockgen 1 0>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster0_l2>;
> > + };
> > +
> > + cpu@100 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + enable-method = "psci";
> > + reg = <0x100>;
> > + clocks = <&clockgen 1 1>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
> > + i-cache-size = <0xC000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <192>;
> > + next-level-cache = <&cluster1_l2>;
> > + };
> > +
> > + cpu@101 {
> > + device_type = "cpu";
> > + compatible = "arm,cortex-a72";
> > + enable-method = "psci";
> > +
[PATCH v7 0/6] arm64: dts: NXP: add basic dts file for LX2160A SoC
Changes for v7: - Comment for clock-frequency property fixed by bootloader Changes for v6: - Added comment for clock unit-sysclk node name in SoC device tree Changes for v5: - Updated temperature sensor regulator name in board device tree - Sorted nodes alphabatically and unit-address in SoC/board device tree - Identation, new line update in SoC/board device tree - Updated nodes name as per DT spec generic name recommendation in SoC DT - Updated macro define for interrupt/gpio property - Updated i2c node property name scl-gpio - Removed device_type property except cpu/memory node - Added esdhc controller nodes in SoC/RDB board device tree - Added aliases for uart/crypto nodes - Add SoC die attribute definition for LX2160A Changes for v4: - Updated bindings for lx2160a clockgen and dcfg - Modified commit message for lx2160a clockgen changes - Updated interrupt property with macro definition - Added required enable-method property to each core node with psci value - Removed unused node syscon in device tree - Removed blank lines in device tree fsl-lx2160a.dtsi - Updated uart node compatible sbsa-uart first - Added and defined vcc-supply property to temperature sensor node in device tree fsl-lx2160a-rdb.dts Changes for v3: -Split clockgen support patch into below two patches: - a)Updated array size of cmux_to_group[] with NUM_CMUX+1 to include -1 terminator and p4080 cmux_to_group[] array with -1 terminator - b)Add clockgen support for lx2160a Changes for v2: - Modified cmux_to_group array to include -1 terminator - Revert NUM_CMUX to original value 8 from 16 - Remove â LX2160A is 16 core, so modified value for NUM_CMUXX in patch "[PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a" description - Populated cache properties for L1 and L2 cache in lx2160a device-tree. - Removed reboot node from lx2160a device-tree as PSCI is implemented. - Removed incorrect comment for timer node interrupt property in lx2160a device-tree. - Modified pmu node compatible property from "arm,armv8-pmuv3" to "arm,cortex-a72-pmu" in lx2160a device-tree - Non-standard aliases removed in lx2160a rdb board device-tree - Updated i2c child nodes to generic name in lx2160a rdb device-tree. Changes for v1: - Add compatible string for LX2160A clockgen support - Add compatible string to initialize LX2160A guts driver - Add compatible string for LX2160A support in dt-bindings - Add dts file to enable support for LX2160A SoC and LX2160A RDB (Reference design board) Vabhav Sharma (4): dt-bindings: arm64: add compatible for LX2160A soc/fsl/guts: Add definition for LX2160A arm64: dts: add QorIQ LX2160A SoC support arm64: dts: add LX2160ARDB board support Yogesh Gaur (2): clk: qoriq: increase array size of cmux_to_group clk: qoriq: Add clockgen support for lx2160a Documentation/devicetree/bindings/arm/fsl.txt | 14 +- .../devicetree/bindings/clock/qoriq-clock.txt | 1 + arch/arm64/boot/dts/freescale/Makefile | 1 + arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 119 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 766 + drivers/clk/clk-qoriq.c| 16 +- drivers/cpufreq/qoriq-cpufreq.c| 1 + drivers/soc/fsl/guts.c | 6 + 8 files changed, 921 insertions(+), 3 deletions(-) create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi -- 2.7.4
[PATCH v7 1/6] dt-bindings: arm64: add compatible for LX2160A
Add compatible for LX2160A SoC,QDS and RDB board Add lx2160a compatible for clockgen and dcfg Signed-off-by: Vabhav Sharma Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/fsl.txt | 14 +- Documentation/devicetree/bindings/clock/qoriq-clock.txt | 1 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 8a1baa2..71adce2 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -130,7 +130,7 @@ core start address and release the secondary core from holdoff and startup. - compatible: Should contain a chip-specific compatible string, Chip-specific strings are of the form "fsl,-dcfg", The following s are known to be supported: - ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a, lx2160a. - reg : should contain base address and length of DCFG memory-mapped registers @@ -222,3 +222,15 @@ Required root node properties: LS2088A ARMv8 based RDB Board Required root node properties: - compatible = "fsl,ls2088a-rdb", "fsl,ls2088a"; + +LX2160A SoC +Required root node properties: +- compatible = "fsl,lx2160a"; + +LX2160A ARMv8 based QDS Board +Required root node properties: +- compatible = "fsl,lx2160a-qds", "fsl,lx2160a"; + +LX2160A ARMv8 based RDB Board +Required root node properties: +- compatible = "fsl,lx2160a-rdb", "fsl,lx2160a"; diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt index 97f46ad..3fb9995 100644 --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -37,6 +37,7 @@ Required properties: * "fsl,ls1046a-clockgen" * "fsl,ls1088a-clockgen" * "fsl,ls2080a-clockgen" + * "fsl,lx2160a-clockgen" Chassis-version clock strings include: * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks -- 2.7.4
[PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
Adding compatible string "lx2160a-dcfg" to
initialize guts driver for lx2160 and SoC die
attribute definition for LX2160A
Signed-off-by: Vabhav Sharma
Signed-off-by: Yinbo Zhu
Acked-by: Li Yang
---
drivers/soc/fsl/guts.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 302e0c8..bcab1ee 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -100,6 +100,11 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
.svr = 0x8700,
.mask = 0xfff7,
},
+ /* Die: LX2160A, SoC: LX2160A/LX2120A/LX2080A */
+ { .die = "LX2160A",
+ .svr = 0x8736,
+ .mask = 0xff3f,
+ },
{ },
};
@@ -222,6 +227,7 @@ static const struct of_device_id fsl_guts_of_match[] = {
{ .compatible = "fsl,ls1088a-dcfg", },
{ .compatible = "fsl,ls1012a-dcfg", },
{ .compatible = "fsl,ls1046a-dcfg", },
+ { .compatible = "fsl,lx2160a-dcfg", },
{}
};
MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
--
2.7.4
[PATCH v7 3/6] clk: qoriq: increase array size of cmux_to_group
From: Yogesh Gaur
Increase size of cmux_to_group array, to accomdate entry of
-1 termination.
Added -1, terminated, entry for 4080_cmux_grpX.
Signed-off-by: Yogesh Gaur
Signed-off-by: Vabhav Sharma
Acked-by: Stephen Boyd
---
drivers/clk/clk-qoriq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 3a1812f..e152bfb 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -79,7 +79,7 @@ struct clockgen_chipinfo {
const struct clockgen_muxinfo *cmux_groups[2];
const struct clockgen_muxinfo *hwaccel[NUM_HWACCEL];
void (*init_periph)(struct clockgen *cg);
- int cmux_to_group[NUM_CMUX]; /* -1 terminates if fewer than NUM_CMUX */
+ int cmux_to_group[NUM_CMUX+1]; /* array should be -1 terminated */
u32 pll_mask; /* 1 << n bit set if PLL n is valid */
u32 flags; /* CG_xxx */
};
@@ -601,7 +601,7 @@ static const struct clockgen_chipinfo chipinfo[] = {
&p4080_cmux_grp1, &p4080_cmux_grp2
},
.cmux_to_group = {
- 0, 0, 0, 0, 1, 1, 1, 1
+ 0, 0, 0, 0, 1, 1, 1, 1, -1
},
.pll_mask = 0x1f,
},
--
2.7.4
[PATCH v7 4/6] clk: qoriq: Add clockgen support for lx2160a
From: Yogesh Gaur
Add clockgen support for lx2160a.
Added entry for compat 'fsl,lx2160a-clockgen'.
Signed-off-by: Tang Yuantian
Signed-off-by: Yogesh Gaur
Signed-off-by: Vabhav Sharma
Acked-by: Stephen Boyd
Acked-by: Viresh Kumar
---
drivers/clk/clk-qoriq.c | 12
drivers/cpufreq/qoriq-cpufreq.c | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index e152bfb..99675de 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -570,6 +570,17 @@ static const struct clockgen_chipinfo chipinfo[] = {
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
{
+ .compat = "fsl,lx2160a-clockgen",
+ .cmux_groups = {
+ &clockgen2_cmux_cga12, &clockgen2_cmux_cgb
+ },
+ .cmux_to_group = {
+ 0, 0, 0, 0, 1, 1, 1, 1, -1
+ },
+ .pll_mask = 0x37,
+ .flags = CG_VER3 | CG_LITTLE_ENDIAN,
+ },
+ {
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
.init_periph = p2041_init_periph,
@@ -1424,6 +1435,7 @@ CLK_OF_DECLARE(qoriq_clockgen_ls1043a,
"fsl,ls1043a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1046a, "fsl,ls1046a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1088a, "fsl,ls1088a-clockgen", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
+CLK_OF_DECLARE(qoriq_clockgen_lx2160a, "fsl,lx2160a-clockgen", clockgen_init);
/* Legacy nodes */
CLK_OF_DECLARE(qoriq_sysclk_1, "fsl,qoriq-sysclk-1.0", sysclk_init);
diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 3d773f6..83921b7 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -295,6 +295,7 @@ static const struct of_device_id node_matches[] __initconst
= {
{ .compatible = "fsl,ls1046a-clockgen", },
{ .compatible = "fsl,ls1088a-clockgen", },
{ .compatible = "fsl,ls2080a-clockgen", },
+ { .compatible = "fsl,lx2160a-clockgen", },
{ .compatible = "fsl,p4080-clockgen", },
{ .compatible = "fsl,qoriq-clockgen-1.0", },
{ .compatible = "fsl,qoriq-clockgen-2.0", },
--
2.7.4
[PATCH v7 5/6] arm64: dts: add QorIQ LX2160A SoC support
LX2160A SoC is based on Layerscape Chassis Generation 3.2 Architecture.
LX2160A features an advanced 16 64-bit ARM v8 CortexA72 processor cores
in 8 cluster, CCN508, GICv3,two 64-bit DDR4 memory controller, 8 I2C
controllers, 3 dspi, 2 esdhc,2 USB 3.0, mmu 500, 3 SATA, 4 PL011 SBSA
UARTs etc.
Signed-off-by: Ramneek Mehresh
Signed-off-by: Zhang Ying-22455
Signed-off-by: Nipun Gupta
Signed-off-by: Priyanka Jain
Signed-off-by: Yogesh Gaur
Signed-off-by: Sriram Dash
Signed-off-by: Vabhav Sharma
Signed-off-by: Horia Geanta
Signed-off-by: Ran Wang
Signed-off-by: Yinbo Zhu
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 766 +
1 file changed, 766 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
new file mode 100644
index 000..a79f5c1
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -0,0 +1,766 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree Include file for Layerscape-LX2160A family SoC.
+//
+// Copyright 2018 NXP
+
+#include
+#include
+
+/memreserve/ 0x8000 0x0001;
+
+/ {
+ compatible = "fsl,lx2160a";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ // 8 clusters having 2 Cortex-A72 cores each
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x0>;
+ clocks = <&clockgen 1 0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0xC000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <192>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x1>;
+ clocks = <&clockgen 1 0>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0xC000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <192>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x100>;
+ clocks = <&clockgen 1 1>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0xC000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <192>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x101>;
+ clocks = <&clockgen 1 1>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0xC000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <192>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x200>;
+ clocks = <&clockgen 1 2>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ i-cache-size = <0xC000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <192>;
+ next-level-cache = <&cluster2_l2>;
+ };
+
+ cpu@201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ enable-method = "psci";
+ reg = <0x201>;
+ clocks = <&clockgen 1 2>;
+ d-cache-size = <0x8000>;
+ d-c
[PATCH v7 6/6] arm64: dts: add LX2160ARDB board support
LX2160A reference design board (RDB) is a high-performance
computing, evaluation, and development platform with LX2160A
SoC.
Signed-off-by: Priyanka Jain
Signed-off-by: Sriram Dash
Signed-off-by: Vabhav Sharma
Signed-off-by: Horia Geanta
Signed-off-by: Ran Wang
Signed-off-by: Zhang Ying-22455
Signed-off-by: Yinbo Zhu
Acked-by: Li Yang
---
arch/arm64/boot/dts/freescale/Makefile| 1 +
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 119 ++
2 files changed, 120 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile
b/arch/arm64/boot/dts/freescale/Makefile
index 86e18ad..445b72b 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -13,3 +13,4 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
new file mode 100644
index 000..6481e5f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file for LX2160ARDB
+//
+// Copyright 2018 NXP
+
+/dts-v1/;
+
+#include "fsl-lx2160a.dtsi"
+
+/ {
+ model = "NXP Layerscape LX2160ARDB";
+ compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
+
+ aliases {
+ crypto = &crypto;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "MC34717-3.3VSB";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&crypto {
+ status = "okay";
+};
+
+&esdhc0 {
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
+ status = "okay";
+};
+
+&esdhc1 {
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ bus-width = <8>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+
+ power-monitor@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ temperature-sensor@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ vcc-supply = <&sb_3v3>;
+ };
+
+ temperature-sensor@4d {
+ compatible = "nxp,sa56004";
+ reg = <0x4d>;
+ vcc-supply = <&sb_3v3>;
+ };
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+
+ rtc@51 {
+ compatible = "nxp,pcf2129";
+ reg = <0x51>;
+ // IRQ10_B
+ interrupts = <0 150 0x4>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
--
2.7.4
RE: [PATCH 3/7] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
>-Original Message- >From: Li Yang >Sent: 2018年10月27日 4:48 >To: Peng Ma >Cc: Vinod ; Rob Herring ; Mark >Rutland ; Shawn Guo ; Dan >Williams ; dmaeng...@vger.kernel.org; open >list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS >; lkml ; >moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE >; linuxppc-dev >; Wen He ; Jiaheng Fan > >Subject: Re: [PATCH 3/7] dmaengine: fsl-qdma: Add qDMA controller driver for >Layerscape SoCs > >On Fri, Oct 26, 2018 at 4:57 AM Peng Ma wrote: >> >> NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel >> virtuallization by allowing DMA jobs to be enqueued into different >> command queues. >> >> Note that this module depends on NXP DPAA. > >It is not clear if you are saying that the driver can only work on >SoCs with a DPAA hardware block, or the driver is actually depending >on the DPAA drivers also. If it is the later case, you also should >express that in the Kconfig you added below. > [Peng Ma] Ok, I will express it in the Kconfig. >> >> Signed-off-by: Wen He >> Signed-off-by: Jiaheng Fan >> Signed-off-by: Peng Ma >> --- >> change in v10: >> - no >> >> drivers/dma/Kconfig| 13 + >> drivers/dma/Makefile |1 + >> drivers/dma/fsl-qdma.c | 1257 > >> 3 files changed, 1271 insertions(+), 0 deletions(-) >> create mode 100644 drivers/dma/fsl-qdma.c >> >> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig >> index dacf3f4..50e19d7 100644 >> --- a/drivers/dma/Kconfig >> +++ b/drivers/dma/Kconfig >> @@ -218,6 +218,19 @@ config FSL_EDMA >> multiplexing capability for DMA request sources(slot). >> This module can be found on Freescale Vybrid and LS-1 SoCs. >> >> +config FSL_QDMA >> + tristate "NXP Layerscape qDMA engine support" >> + depends on ARM || ARM64 >> + select DMA_ENGINE >> + select DMA_VIRTUAL_CHANNELS >> + select DMA_ENGINE_RAID >> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH >> + help >> + Support the NXP Layerscape qDMA engine with command queue >and legacy mode. >> + Channel virtualization is supported through enqueuing of DMA >jobs to, >> + or dequeuing DMA jobs from, different work queues. >> + This module can be found on NXP Layerscape SoCs. >> + >> config FSL_RAID >> tristate "Freescale RAID engine Support" >> depends on FSL_SOC >&& !ASYNC_TX_ENABLE_CHANNEL_SWITCH >> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile >> index c91702d..2d1b586 100644 >> --- a/drivers/dma/Makefile >> +++ b/drivers/dma/Makefile >> @@ -32,6 +32,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/ >> obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o >> obj-$(CONFIG_FSL_DMA) += fsldma.o >> obj-$(CONFIG_FSL_EDMA) += fsl-edma.o >> +obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o >> obj-$(CONFIG_FSL_RAID) += fsl_raid.o >> obj-$(CONFIG_HSU_DMA) += hsu/ >> obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o >> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c >> new file mode 100644 >> index 000..404869e >> --- /dev/null >> +++ b/drivers/dma/fsl-qdma.c >> @@ -0,0 +1,1257 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// Copyright 2018 NXP > >I'm not sure if this is really the case. The driver at least has been >sent out in 2015. We should keep these copyright claims, even the >legacy Freescale copyright claims. > [Peng Ma] I am not sure this patch sent out in 2015, but the git log earliest shows the patch cteated at Dec 20 2017. so if i changed the "Copyright 2018 NXP" to " Copyright 2017-2018 NXP " Best regards Peng Ma >> + >> +/* >> + * Driver for NXP Layerscape Queue Direct Memory Access Controller >> + * >> + * Author: >> + * Wen He >> + * Jiaheng Fan >> + * >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include "virt-dma.h" >> +#include "fsldma.h" >> + >> +/* Register related definition */ >> +#define FSL_QDMA_DMR 0x0 >> +#define FSL_QDMA_DSR 0x4 >> +#define FSL_QDMA_DEIER 0xe00 >> +#define FSL_QDMA_DEDR 0xe04 >> +#define FSL_QDMA_DECFDW0R 0xe10 >> +#define FSL_QDMA_DECFDW1R 0xe14 >> +#define FSL_QDMA_DECFDW2R 0xe18 >> +#define FSL_QDMA_DECFDW3R 0xe1c >> +#define FSL_QDMA_DECFQIDR 0xe30 >> +#define FSL_QDMA_DECBR 0xe34 >> + >> +#define FSL_QDMA_BCQMR(x) (0xc0 + 0x100 * (x)) >> +#define FSL_QDMA_BCQSR(x) (0xc4 + 0x100 * (x)) >> +#define FSL_QDMA_BCQEDPA_SADDR(x) (0xc8 + 0x100 * (x)) >> +#define FSL_QDMA_BCQDPA_SADDR(x) (0xcc + 0x100 * (x)) >> +#define FSL_QDMA_BCQEEPA_SADDR(x) (0xd0 + 0x100 * (x)) >> +#define FSL_QDMA_BCQEPA_SADDR(x) (0xd4 + 0x100 * (x)) >> +#define FSL_QDMA_BCQIER(x) (0xe0 + 0x100 * (x)) >> +#define FSL_QDMA_BCQIDR(x) (0xe4 + 0x100 * (x)) >> + >> +#define FSL_QDMA_SQDPAR
NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
Hello,
I have figured out that the commit 'devicetree-for-4.20' [1] is
responsible for the SMP problem. I was able to revert this commit with
'git revert b27186abb37b7bd19e0ca434f4f425c807dbd708 -m 1' today.
[master ec81438] Revert "Merge tag 'devicetree-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux"
138 files changed, 931 insertions(+), 1538 deletions(-)
rename Documentation/devicetree/bindings/arm/{atmel-sysregs.txt =>
atmel-at91.txt} (67%)
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
rename Documentation/devicetree/bindings/arm/{zte,sysctrl.txt =>
zte.txt} (62%)
delete mode 100644 Documentation/devicetree/bindings/misc/lwn-bk4.txt
create mode 100644 arch/c6x/boot/dts/linked_dtb.S
delete mode 100644 arch/nios2/boot/dts/Makefile
create mode 100644 arch/nios2/boot/linked_dtb.S
delete mode 100644 arch/powerpc/boot/dts/Makefile
delete mode 100644 arch/powerpc/boot/dts/fsl/Makefile
delete mode 100644 scripts/dtc/yamltree.c
It solves the SMP problem! SMP works again on my P5020 board and on
virtual e5500 QEMU machines.
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel
/home/christian/Downloads/uImage-4.20-alpha5 -drive
format=raw,file=/home/christian/Dokumente/ubuntu_MATE_16.04.3_LTS_PowerPC_QEMU/ubuntu_MATE_16.04_PowerPC.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda3" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -soundhw es1370 -smp 4
Screenshot:
https://plus.google.com/u/0/photos/photo/115515624056477014971/6617705776207990082
Do we need a new dtb file or is it a bug?
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 28 October 2018 at 5:35PM, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18 11:12AM
GMT) on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[ 0.00] -
[ 0.00] phys_mem_size = 0x2
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x0003008003b4
[ 0.00] possible = 0x0003009003b4
[ 0.00] always = 0x0003008003b4
[ 0.00] cpu_user_features = 0xcc008000 0x0800
[ 0.00] mmu_features = 0x000a0010
[ 0.00] firmware_features = 0x
[ 0.00] -
[ 0.00] CoreNet Generic board
...
[ 0.002161] smp: Bringing up secondary CPUs ...
[ 0.002339] No cpu-release-addr for cpu 1
[ 0.002347] smp: failed starting cpu 1 (rc -2)
[ 0.002401] smp: Brought up 1 node, 1 CPU
Virtual e5500 quad core QEMU machine:
[ 0.026394] smp: Bringing up secondary CPUs ...
[ 0.027831] No cpu-release-addr for cpu 1
[ 0.027989] smp: failed starting cpu 1 (rc -2)
[ 0.030143] No cpu-release-addr for cpu 2
[ 0.030304] smp: failed starting cpu 2 (rc -2)
[ 0.032400] No cpu-release-addr for cpu 3
[ 0.032533] smp: failed starting cpu 3 (rc -2)
[ 0.033117] smp: Brought up 1 node, 1 CPU
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel
/home/christian/Downloads/vmlinux-4.20-alpha4-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20
-drive
format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw
es1370 -smp 4
.config:
...
CONFIG_SMP=y
CONFIG_NR_CPUS=4
...
Please test the latest Git kernel on your NXP P50XX boards.
Thanks,
Christian
arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined
Hello, The latest Git kernel doesn't compile currently because of the following error: CC arch/powerpc/kvm/powerpc.o In file included from arch/powerpc/kvm/powerpc.c:51:0: arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined [-Werror] #define TRACE_INCLUDE_PATH . ^ In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0, from arch/powerpc/kvm/powerpc.c:48: ./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of the previous definition #define TRACE_INCLUDE_PATH asm ^ cc1: all warnings being treated as errors scripts/Makefile.build:305: die Regel für Ziel „arch/powerpc/kvm/powerpc.o“ scheiterte make[2]: *** [arch/powerpc/kvm/powerpc.o] Fehler 1 scripts/Makefile.build:546: die Regel für Ziel „arch/powerpc/kvm“ scheiterte make[1]: *** [arch/powerpc/kvm] Fehler 2 Makefile:1052: die Regel für Ziel „arch/powerpc“ scheiterte make: *** [arch/powerpc] Fehler 2 christian@christian-virtual-machine:~/Downloads/a$ env LANG=C make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage CALL scripts/checksyscalls.sh CHK include/generated/compile.h CALL arch/powerpc/kernel/systbl_chk.sh CC arch/powerpc/kvm/powerpc.o In file included from arch/powerpc/kvm/powerpc.c:51:0: arch/powerpc/kvm/trace.h:9:0: error: "TRACE_INCLUDE_PATH" redefined [-Werror] #define TRACE_INCLUDE_PATH . ^ In file included from arch/powerpc/kvm/../mm/mmu_decl.h:25:0, from arch/powerpc/kvm/powerpc.c:48: ./arch/powerpc/include/asm/trace.h:224:0: note: this is the location of the previous definition #define TRACE_INCLUDE_PATH asm ^ cc1: all warnings being treated as errors scripts/Makefile.build:305: recipe for target 'arch/powerpc/kvm/powerpc.o' failed make[2]: *** [arch/powerpc/kvm/powerpc.o] Error 1 scripts/Makefile.build:546: recipe for target 'arch/powerpc/kvm' failed make[1]: *** [arch/powerpc/kvm] Error 2 Makefile:1052: recipe for target 'arch/powerpc' failed make: *** [arch/powerpc] Error 2 --- I deleted the definition of 'TRACE_INCLUDE_PATH' in 'arch/powerpc/kvm/trace.h'. After that the kernel compiled without any problems. -- Christian
Re: [PATCH 0/8] add generic builtin command line
On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote: > On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote: > > Do you mean, that you haven't seen patch for ARM, which I sent on > > September 27 along with cover and patch 1? It is strange, because > > you was the one from recipients. If so, you can see this patch here: > > https://lore.kernel.org/patchwork/patch/992779/ > > It seems that I have received patch 5, _but_ it's not threaded with > the cover message and patch 1. With 50k messages in my inbox, and 3k > messages since you sent the series, it's virtually impossible to find > it (I only found it by looking at my mail server logs from September > to find the subject, and then searching my mailbox for that subject.) > > This is unnecessarily difficult. This comes up surprisingly often, and I think part of the issue is that different maintainers have different preferences. I also prefer to receive the entire series and cover-letter, but I've seen people object to being CC'd on the whole series as well (how they manage to review things in isolation is another question...!) I wonder if we could have an entry in MAINTAINERS for this sort of preference? Maksym: in the short term, please just stick me and Russell on CC for the entire thing. Will
Re: [PATCH 0/8] add generic builtin command line
On Mon, Oct 29, 2018 at 10:29:15AM +, Will Deacon wrote: > On Wed, Oct 24, 2018 at 10:07:32AM +0100, Russell King - ARM Linux wrote: > > On Wed, Oct 24, 2018 at 11:57:44AM +0300, Maksym Kokhan wrote: > > > Do you mean, that you haven't seen patch for ARM, which I sent on > > > September 27 along with cover and patch 1? It is strange, because > > > you was the one from recipients. If so, you can see this patch here: > > > https://lore.kernel.org/patchwork/patch/992779/ > > > > It seems that I have received patch 5, _but_ it's not threaded with > > the cover message and patch 1. With 50k messages in my inbox, and 3k > > messages since you sent the series, it's virtually impossible to find > > it (I only found it by looking at my mail server logs from September > > to find the subject, and then searching my mailbox for that subject.) > > > > This is unnecessarily difficult. > > This comes up surprisingly often, and I think part of the issue is that > different maintainers have different preferences. I also prefer to receive > the entire series and cover-letter, but I've seen people object to being > CC'd on the whole series as well (how they manage to review things in > isolation is another question...!) This series has the odd situation where patch 1 is threaded to the cover letter, but nothing else is - that makes it inconsistent. Where I've seen people disagree with threading is when sending follow-up series - whether that should be threaded to the previous series or not - some people want it others hate it. However, I haven't seen any disagreement is about having the patches threaded to the cover. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH 1/5] selftests/powerpc/ptrace: Fix out-of-tree build
From: Joel Stanley We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the ptrace-pkey and core-pkey rules to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/ptrace/Makefile | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile b/tools/testing/selftests/powerpc/ptrace/Makefile index 9b35ca8e8f13..8d3f006c98cc 100644 --- a/tools/testing/selftests/powerpc/ptrace/Makefile +++ b/tools/testing/selftests/powerpc/ptrace/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_PROGS := ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr \ +TEST_GEN_PROGS := ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr \ ptrace-tar ptrace-tm-tar ptrace-tm-spd-tar ptrace-vsx ptrace-tm-vsx \ ptrace-tm-spd-vsx ptrace-tm-spr ptrace-hwbreak ptrace-pkey core-pkey \ perf-hwbreak ptrace-syscall @@ -7,14 +7,9 @@ TEST_PROGS := ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr \ top_srcdir = ../../../../.. include ../../lib.mk -all: $(TEST_PROGS) - CFLAGS += -m64 -I../../../../../usr/include -I../tm -mhtm -fno-pie -ptrace-pkey core-pkey: child.h -ptrace-pkey core-pkey: LDLIBS += -pthread - -$(TEST_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h +$(OUTPUT)/ptrace-pkey $(OUTPUT)/core-pkey: child.h +$(OUTPUT)/ptrace-pkey $(OUTPUT)/core-pkey: LDLIBS += -pthread -clean: - rm -f $(TEST_PROGS) *.o +$(TEST_GEN_PROGS): ../harness.c ../utils.c ../lib/reg.S ptrace.h -- 2.17.2
[PATCH 2/5] selftests/powerpc/signal: Fix out-of-tree build
From: Joel Stanley We should use TEST_GEN_PROGS, not TEST_PROGS. That tells the selftests makefile (lib.mk) that those tests are generated (built), and so it adds the $(OUTPUT) prefix for us, making the out-of-tree build work correctly. It also means we don't need our own clean rule, lib.mk does it. We also have to update the signal_tm rule to use $(OUTPUT). Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/signal/Makefile | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/tools/testing/selftests/powerpc/signal/Makefile b/tools/testing/selftests/powerpc/signal/Makefile index 1fca25c6ace0..209a958dca12 100644 --- a/tools/testing/selftests/powerpc/signal/Makefile +++ b/tools/testing/selftests/powerpc/signal/Makefile @@ -1,15 +1,10 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_PROGS := signal signal_tm - -all: $(TEST_PROGS) - -$(TEST_PROGS): ../harness.c ../utils.c signal.S +TEST_GEN_PROGS := signal signal_tm CFLAGS += -maltivec -signal_tm: CFLAGS += -mhtm +$(OUTPUT)/signal_tm: CFLAGS += -mhtm top_srcdir = ../../../../.. include ../../lib.mk -clean: - rm -f $(TEST_PROGS) *.o +$(TEST_GEN_PROGS): ../harness.c ../utils.c signal.S -- 2.17.2
[PATCH 3/5] selftests/powerpc/pmu: Link ebb tests with -no-pie
From: Joel Stanley When running the ebb tests after building on a ppc64le Ubuntu machine: $ pmu/ebb/reg_access_test: error while loading shared libraries: R_PPC64_ADDR16_HI reloc at 0x00013a965130 for symbol `' out of range This is because the Ubuntu toolchain builds has PIE enabled by default. Change it to be always off instead. Signed-off-by: Joel Stanley Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/pmu/ebb/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/testing/selftests/powerpc/pmu/ebb/Makefile b/tools/testing/selftests/powerpc/pmu/ebb/Makefile index bd5dfa509272..23f4caf48ffc 100644 --- a/tools/testing/selftests/powerpc/pmu/ebb/Makefile +++ b/tools/testing/selftests/powerpc/pmu/ebb/Makefile @@ -5,6 +5,9 @@ noarg: # The EBB handler is 64-bit code and everything links against it CFLAGS += -m64 +# Toolchains may build PIE by default which breaks the assembly +LDFLAGS += -no-pie + TEST_GEN_PROGS := reg_access_test event_attributes_test cycles_test\ cycles_with_freeze_test pmc56_overflow_test\ ebb_vs_cpu_event_test cpu_event_vs_ebb_test\ -- 2.17.2
[PATCH 4/5] selftests/powerpc/switch_endian: Fix out-of-tree build
For the out-of-tree build to work we need to tell switch_endian_test to look for check-reversed.S in $(OUTPUT). Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/switch_endian/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/powerpc/switch_endian/Makefile b/tools/testing/selftests/powerpc/switch_endian/Makefile index fcd2dcb8972b..bdc081afedb0 100644 --- a/tools/testing/selftests/powerpc/switch_endian/Makefile +++ b/tools/testing/selftests/powerpc/switch_endian/Makefile @@ -8,6 +8,7 @@ EXTRA_CLEAN = $(OUTPUT)/*.o $(OUTPUT)/check-reversed.S top_srcdir = ../../../../.. include ../../lib.mk +$(OUTPUT)/switch_endian_test: ASFLAGS += -I $(OUTPUT) $(OUTPUT)/switch_endian_test: $(OUTPUT)/check-reversed.S $(OUTPUT)/check-reversed.o: $(OUTPUT)/check.o -- 2.17.2
[PATCH 5/5] selftests/powerpc/cache_shape: Fix out-of-tree build
Use TEST_GEN_PROGS and don't redefine all, this makes the out-of-tree build work. We need to move the extra dependencies below the include of lib.mk, because it adds the $(OUTPUT) prefix if it's defined. We can also drop the clean rule, lib.mk does it for us. Signed-off-by: Michael Ellerman --- tools/testing/selftests/powerpc/cache_shape/Makefile | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/powerpc/cache_shape/Makefile b/tools/testing/selftests/powerpc/cache_shape/Makefile index ede4d3dae750..689f6c8ebcd8 100644 --- a/tools/testing/selftests/powerpc/cache_shape/Makefile +++ b/tools/testing/selftests/powerpc/cache_shape/Makefile @@ -1,12 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 -TEST_PROGS := cache_shape - -all: $(TEST_PROGS) - -$(TEST_PROGS): ../harness.c ../utils.c +TEST_GEN_PROGS := cache_shape top_srcdir = ../../../../.. include ../../lib.mk -clean: - rm -f $(TEST_PROGS) *.o +$(TEST_GEN_PROGS): ../harness.c ../utils.c -- 2.17.2
Re: [PATCH 2/4] mm: speed up mremap by 500x on large regions (v2)
On Fri, Oct 26, 2018 at 02:11:48PM -0700, Joel Fernandes wrote: > My thinking is to take it slow and get the patch in in its current state, > since it improves x86. Then as a next step, look into why the arm64 tlb > flushes are that expensive and look into optimizing that. On arm64 I am > testing on a 4.9 kernel so I'm wondering there are any optimizations since > 4.9 that can help speed it up there. After that, if all else fails about > speeding up arm64, then I look into developing the cleanest possible solution > where we can keep the lock held for longer and flush lesser. We rewrote a good chunk of the arm64 TLB invalidation and core mmu_gather code this merge window, so please do have another look at -rc1! Will
RE: [PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Vabhav Sharma
> Sent: Monday, October 29, 2018 2:28 PM
> To: sudeep.ho...@arm.com; o...@buserror.net; linux-ker...@vger.kernel.org;
> devicet...@vger.kernel.org; robh...@kernel.org; mark.rutl...@arm.com;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> mturque...@baylibre.com; sb...@kernel.org; r...@rjwysocki.net;
> viresh.ku...@linaro.org; linux-...@vger.kernel.org; linux...@vger.kernel.org;
> linux-kernel-ow...@vger.kernel.org; catalin.mari...@arm.com;
> will.dea...@arm.com; gre...@linuxfoundation.org; a...@arndb.de;
> kstew...@linuxfoundation.org; yamada.masah...@socionext.com; Leo Li
> ; shawn...@kernel.org
> Cc: ulf.hans...@linaro.org; Udit Kumar ; Pankaj Bansal
> ; li...@armlinux.org.uk; adrian.hun...@intel.com;
> Varun Sethi ; Vabhav Sharma ;
> Yinbo Zhu
> Subject: [PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
>
> Adding compatible string "lx2160a-dcfg" to initialize guts driver for lx2160
> and
> SoC die attribute definition for LX2160A
>
> Signed-off-by: Vabhav Sharma
> Signed-off-by: Yinbo Zhu
> Acked-by: Li Yang
> ---
> drivers/soc/fsl/guts.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c index
> 302e0c8..bcab1ee 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -100,6 +100,11 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
> .svr = 0x8700,
> .mask = 0xfff7,
> },
> + /* Die: LX2160A, SoC: LX2160A/LX2120A/LX2080A */
> + { .die = "LX2160A",
> + .svr = 0x8736,
Do all the threevariants " LX2160A/LX2120A/LX2080A" have same SVR?
> + .mask = 0xff3f,
> + },
> { },
> };
>
> @@ -222,6 +227,7 @@ static const struct of_device_id fsl_guts_of_match[] = {
> { .compatible = "fsl,ls1088a-dcfg", },
> { .compatible = "fsl,ls1012a-dcfg", },
> { .compatible = "fsl,ls1046a-dcfg", },
> + { .compatible = "fsl,lx2160a-dcfg", },
> {}
> };
> MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=02%7C01%7Cpoonam.aggrwal%40nxp.com%7Cd9b7c36c786
> 54cd6dc4008d63d7fee63%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636764017001504288&sdata=pqFMlw6yVrHrvn4YRhqj%2FmoOnSscrZu
> tcoYn3In8OJc%3D&reserved=0
[RFC PATCH] seccomp: Add protection keys into seccomp_data
Add the current value of an architecture specific protection keys
register (currently PKRU on x86) to data available for seccomp-bpf
programs to work on. This allows filters based on the currently
enabled protection keys.
Support for protection keys on the POWER architecture is not part of
this patch since I do not have access to a PowerPC, but adding support
for it can be achieved by setting sd->pkeys to the AMR register in
populate_seccomp_data.
One use case for this patch is disabling unnecessary system calls for a
library (e.g. network i/o for a crypto library) while the library runs
without disabling the system calls for the whole program (by changing
the protection keys before and after the library executes). Using this
one could ensure that the library behaves a expected (e.g. the crypto
library not sending private keys to a malicious server).
This patch also enables lightweight sandboxing of untrusted code using
memory protection keys: Protection keys provide memory isolation but
for a sandbox system call isolation is needed as well. This patch
allows writing a seccomp filter to prevent system calls by the
untrusted code while still allowing system calls for the trusted code.
An alternative design would be to extend (c)BPF with a new instruction
to read the state of a protection key. This alternate design would
provide a simpler interface to the user space since the BPF program
would not need to deal with the architecture specific pkeys field in
seccomp_data, but the question is, how much of an advantage this would
be as the nr field in seccomp_data is already architecture specific.
Adding a new instruction for BPF programs is more complicated than
this patch and might be a breaking change.
Results of selftests/seccomp_benchmark.c on a x86 machine with pkeys
support:
With patch:
Benchmarking 33554432 samples...
28.019505558 - 18.676858522 = 9342647036
getpid native: 278 ns
42.279109885 - 28.019657031 = 14259452854
getpid RET_ALLOW: 424 ns
Estimated seccomp overhead per syscall: 146 ns
Without patch:
Benchmarking 33554432 samples...
28.059619466 - 18.706769155 = 9352850311
getpid native: 278 ns
42.299228279 - 28.059761804 = 14239466475
getpid RET_ALLOW: 424 ns
Estimated seccomp overhead per syscall: 146 ns
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Ram Pai
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Michael Sammler
---
Changes to the previous version:
- added motivation, notes about POWER, alternative design and benchmark results
to the commit log
- renamed pkru field in seccomp_data to pkeys
- changed size of pkru field to __u64 and removed reserved field
- added test for x86
arch/mips/kernel/ptrace.c | 1 +
arch/x86/entry/common.c | 1 +
include/uapi/linux/seccomp.h | 3 +
kernel/seccomp.c | 1 +
tools/testing/selftests/seccomp/seccomp_bpf.c | 107 +-
5 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index e5ba56c0..a58dd04d 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -1277,6 +1277,7 @@ asmlinkage long syscall_trace_enter(struct pt_regs *regs,
long syscall)
for (i = 0; i < 6; i++)
sd.args[i] = args[i];
sd.instruction_pointer = KSTK_EIP(current);
+ sd.pkeys = 0;
ret = __secure_computing(&sd);
if (ret == -1)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 3b2490b8..20c51bf2 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -98,6 +98,7 @@ static long syscall_trace_enter(struct pt_regs *regs)
sd.arch = arch;
sd.nr = regs->orig_ax;
sd.instruction_pointer = regs->ip;
+ sd.pkeys = read_pkru();
#ifdef CONFIG_X86_64
if (arch == AUDIT_ARCH_X86_64) {
sd.args[0] = regs->di;
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 9efc0e73..3aa2d934 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -52,12 +52,15 @@
* @instruction_pointer: at the time of the system call.
* @args: up to 6 system call arguments always stored as 64-bit values
*regardless of the architecture.
+ * @pkeys: value of an architecture specific protection keys register
+ * (currently PKRU on x86)
*/
struct seccomp_data {
int nr;
__u32 arch;
__u64 instruction_pointer;
__u64 args[6];
+ __u64 pkeys;
};
#endif /* _UAPI_LINUX_SECCOMP_H */
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index fd023ac2..dfb8b0d6 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -91,6 +91,7 @@ static void populate_seccomp_data(struct seccomp_data *sd)
sd->args[4] = args[4];
sd->args[5] = args[5];
sd
Re: [PATCH 1/5] powerpc/64s: Guarded Userspace Access Prevention
Hi Russell,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20181029]
[cannot apply to v4.19]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Russell-Currey/Guarded-Userspace-Access-Prevention-on-Radix/20181026-145017
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-ppc64e_defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc
All error/warnings (new ones prefixed by >>):
In file included from arch/powerpc/kernel/asm-offsets.c:31:0:
arch/powerpc/kernel/asm-offsets.c: In function 'main':
>> include/linux/compiler_types.h:229:35: error: 'struct paca_struct' has no
>> member named 'user_access_allowed'
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
^
include/linux/kbuild.h:6:62: note: in definition of macro 'DEFINE'
asm volatile("\n.ascii \"->" #sym " %0 " #val "\"" : : "i" (val))
^~~
include/linux/stddef.h:17:32: note: in expansion of macro
'__compiler_offsetof'
#define offsetof(TYPE, MEMBER) __compiler_offsetof(TYPE, MEMBER)
^~~
>> include/linux/kbuild.h:11:14: note: in expansion of macro 'offsetof'
DEFINE(sym, offsetof(struct str, mem))
^~~~
>> arch/powerpc/kernel/asm-offsets.c:263:2: note: in expansion of macro 'OFFSET'
OFFSET(PACA_USER_ACCESS_ALLOWED, paca_struct, user_access_allowed);
^~
make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1
make[2]: Target '__build' not remade because of errors.
make[1]: *** [prepare0] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [sub-make] Error 2
vim +229 include/linux/compiler_types.h
815f0ddb Nick Desaulniers 2018-08-22 228
815f0ddb Nick Desaulniers 2018-08-22 @229 #define __compiler_offsetof(a, b)
__builtin_offsetof(a, b)
815f0ddb Nick Desaulniers 2018-08-22 230
:: The code at line 229 was first introduced by commit
:: 815f0ddb346c196018d4d8f8f55c12b83da1de3f include/linux/compiler*.h: make
compiler-*.h mutually exclusive
:: TO: Nick Desaulniers
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 3/7] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
> On Oct 29, 2018, at 4:51 AM, Peng Ma wrote: > > > >> -Original Message- >> From: Li Yang >> Sent: 2018年10月27日 4:48 >> To: Peng Ma >> Cc: Vinod ; Rob Herring ; Mark >> Rutland ; Shawn Guo ; Dan >> Williams ; dmaeng...@vger.kernel.org; open >> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS >> ; lkml ; >> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE >> ; linuxppc-dev >> ; Wen He ; Jiaheng Fan >> >> Subject: Re: [PATCH 3/7] dmaengine: fsl-qdma: Add qDMA controller driver for >> Layerscape SoCs >> >>> On Fri, Oct 26, 2018 at 4:57 AM Peng Ma wrote: >>> >>> NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel >>> virtuallization by allowing DMA jobs to be enqueued into different >>> command queues. >>> >>> Note that this module depends on NXP DPAA. >> >> It is not clear if you are saying that the driver can only work on >> SoCs with a DPAA hardware block, or the driver is actually depending >> on the DPAA drivers also. If it is the later case, you also should >> express that in the Kconfig you added below. >> > [Peng Ma] Ok, I will express it in the Kconfig. >>> >>> Signed-off-by: Wen He >>> Signed-off-by: Jiaheng Fan >>> Signed-off-by: Peng Ma >>> --- >>> change in v10: >>>- no >>> >>> drivers/dma/Kconfig| 13 + >>> drivers/dma/Makefile |1 + >>> drivers/dma/fsl-qdma.c | 1257 >> >>> 3 files changed, 1271 insertions(+), 0 deletions(-) >>> create mode 100644 drivers/dma/fsl-qdma.c >>> >>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig >>> index dacf3f4..50e19d7 100644 >>> --- a/drivers/dma/Kconfig >>> +++ b/drivers/dma/Kconfig >>> @@ -218,6 +218,19 @@ config FSL_EDMA >>> multiplexing capability for DMA request sources(slot). >>> This module can be found on Freescale Vybrid and LS-1 SoCs. >>> >>> +config FSL_QDMA >>> + tristate "NXP Layerscape qDMA engine support" >>> + depends on ARM || ARM64 >>> + select DMA_ENGINE >>> + select DMA_VIRTUAL_CHANNELS >>> + select DMA_ENGINE_RAID >>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH >>> + help >>> + Support the NXP Layerscape qDMA engine with command queue >> and legacy mode. >>> + Channel virtualization is supported through enqueuing of DMA >> jobs to, >>> + or dequeuing DMA jobs from, different work queues. >>> + This module can be found on NXP Layerscape SoCs. >>> + >>> config FSL_RAID >>> tristate "Freescale RAID engine Support" >>> depends on FSL_SOC >> && !ASYNC_TX_ENABLE_CHANNEL_SWITCH >>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile >>> index c91702d..2d1b586 100644 >>> --- a/drivers/dma/Makefile >>> +++ b/drivers/dma/Makefile >>> @@ -32,6 +32,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/ >>> obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o >>> obj-$(CONFIG_FSL_DMA) += fsldma.o >>> obj-$(CONFIG_FSL_EDMA) += fsl-edma.o >>> +obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o >>> obj-$(CONFIG_FSL_RAID) += fsl_raid.o >>> obj-$(CONFIG_HSU_DMA) += hsu/ >>> obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o >>> diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c >>> new file mode 100644 >>> index 000..404869e >>> --- /dev/null >>> +++ b/drivers/dma/fsl-qdma.c >>> @@ -0,0 +1,1257 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> +// Copyright 2018 NXP >> >> I'm not sure if this is really the case. The driver at least has been >> sent out in 2015. We should keep these copyright claims, even the >> legacy Freescale copyright claims. >> > [Peng Ma] >I am not sure this patch sent out in 2015, but the git log earliest shows > the patch cteated at Dec 20 2017. so if i changed the "Copyright 2018 NXP" to > " Copyright 2017-2018 NXP " You can find early versions of this patch in previous SDK releases or the upstream versions with a google search. These existing copyright claims should not be removed in the first place. > > Best regards >Peng Ma >>> + >>> +/* >>> + * Driver for NXP Layerscape Queue Direct Memory Access Controller >>> + * >>> + * Author: >>> + * Wen He >>> + * Jiaheng Fan >>> + * >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +#include "virt-dma.h" >>> +#include "fsldma.h" >>> + >>> +/* Register related definition */ >>> +#define FSL_QDMA_DMR 0x0 >>> +#define FSL_QDMA_DSR 0x4 >>> +#define FSL_QDMA_DEIER 0xe00 >>> +#define FSL_QDMA_DEDR 0xe04 >>> +#define FSL_QDMA_DECFDW0R 0xe10 >>> +#define FSL_QDMA_DECFDW1R 0xe14 >>> +#define FSL_QDMA_DECFDW2R 0xe18 >>> +#define FSL_QDMA_DECFDW3R 0xe1c >>> +#define FSL_QDMA_DECFQIDR 0xe30 >>> +#define FSL_QDMA_DECBR 0xe34 >>> + >>> +#define FSL_QDMA_BCQMR(x) (0xc0 + 0x100 * (x)) >>> +#define FSL_QDMA_BCQSR(x) (0xc4 + 0x100 * (x)) >>> +#defi
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote:
> Add the current value of an architecture specific protection keys
> register (currently PKRU on x86) to data available for seccomp-bpf
> programs to work on. This allows filters based on the currently
> enabled protection keys.
>
> Support for protection keys on the POWER architecture is not part of
> this patch since I do not have access to a PowerPC, but adding support
> for it can be achieved by setting sd->pkeys to the AMR register in
> populate_seccomp_data.
>
> One use case for this patch is disabling unnecessary system calls for a
> library (e.g. network i/o for a crypto library) while the library runs
> without disabling the system calls for the whole program (by changing
> the protection keys before and after the library executes). Using this
> one could ensure that the library behaves a expected (e.g. the crypto
> library not sending private keys to a malicious server).
>
> This patch also enables lightweight sandboxing of untrusted code using
> memory protection keys: Protection keys provide memory isolation but
> for a sandbox system call isolation is needed as well. This patch
> allows writing a seccomp filter to prevent system calls by the
> untrusted code while still allowing system calls for the trusted code.
Isn't PKU instruction based? Couldn't a malicious library just change
the state of the MPK registers? This seems like an easy way to bypass
any filters that used PKU. I'm not convinced this is a meaningful
barrier that should be enforced by seccomp.
This can also be done with a signal handler with SECCOMP_RET_TRAP and
check instruction pointer vs PKU state.
-Kees
>
> An alternative design would be to extend (c)BPF with a new instruction
> to read the state of a protection key. This alternate design would
> provide a simpler interface to the user space since the BPF program
> would not need to deal with the architecture specific pkeys field in
> seccomp_data, but the question is, how much of an advantage this would
> be as the nr field in seccomp_data is already architecture specific.
> Adding a new instruction for BPF programs is more complicated than
> this patch and might be a breaking change.
>
> Results of selftests/seccomp_benchmark.c on a x86 machine with pkeys
> support:
>
> With patch:
> Benchmarking 33554432 samples...
> 28.019505558 - 18.676858522 = 9342647036
> getpid native: 278 ns
> 42.279109885 - 28.019657031 = 14259452854
> getpid RET_ALLOW: 424 ns
> Estimated seccomp overhead per syscall: 146 ns
>
> Without patch:
> Benchmarking 33554432 samples...
> 28.059619466 - 18.706769155 = 9352850311
> getpid native: 278 ns
> 42.299228279 - 28.059761804 = 14239466475
> getpid RET_ALLOW: 424 ns
> Estimated seccomp overhead per syscall: 146 ns
>
> Cc: Kees Cook
> Cc: Andy Lutomirski
> Cc: Will Drewry
> Cc: Ram Pai
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Michael Sammler
> ---
> Changes to the previous version:
> - added motivation, notes about POWER, alternative design and benchmark
> results to the commit log
> - renamed pkru field in seccomp_data to pkeys
> - changed size of pkru field to __u64 and removed reserved field
> - added test for x86
>
> arch/mips/kernel/ptrace.c | 1 +
> arch/x86/entry/common.c | 1 +
> include/uapi/linux/seccomp.h | 3 +
> kernel/seccomp.c | 1 +
> tools/testing/selftests/seccomp/seccomp_bpf.c | 107
> +-
> 5 files changed, 112 insertions(+), 1 deletion(-)
>
> diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
> index e5ba56c0..a58dd04d 100644
> --- a/arch/mips/kernel/ptrace.c
> +++ b/arch/mips/kernel/ptrace.c
> @@ -1277,6 +1277,7 @@ asmlinkage long syscall_trace_enter(struct pt_regs
> *regs, long syscall)
> for (i = 0; i < 6; i++)
> sd.args[i] = args[i];
> sd.instruction_pointer = KSTK_EIP(current);
> + sd.pkeys = 0;
>
> ret = __secure_computing(&sd);
> if (ret == -1)
> diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
> index 3b2490b8..20c51bf2 100644
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -98,6 +98,7 @@ static long syscall_trace_enter(struct pt_regs *regs)
> sd.arch = arch;
> sd.nr = regs->orig_ax;
> sd.instruction_pointer = regs->ip;
> + sd.pkeys = read_pkru();
> #ifdef CONFIG_X86_64
> if (arch == AUDIT_ARCH_X86_64) {
> sd.args[0] = regs->di;
> diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> index 9efc0e73..3aa2d934 100644
> --- a/include/uapi/linux/seccomp.h
> +++ b/include/uapi/linux/seccomp.h
> @@ -52,12 +52,15 @@
> * @instruction_pointer: at the time of the system call.
> * @args: up to 6 system call arguments always store
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/18 9:25 AM, Kees Cook wrote: > On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote: >> Add the current value of an architecture specific protection keys >> register (currently PKRU on x86) to data available for seccomp-bpf >> programs to work on. This allows filters based on the currently >> enabled protection keys. How does the current "assignment" of protection keys to the various uses get communicated to the filter? I'm not sure this is a great use for PKRU. I *think* the basic problem is that you want to communicate some rights information down into a filter, and you want to communicate it with PKRU. While it's handy to have an extra register that nobody (generally) mucks with, I'm not quite convinced that we want to repurpose it this way. Also, I'm not sure the kernel provides the PKRU guarantees you want at the moment. Our implementation *probably* works, but it's mostly by accident.
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On Mon, Oct 29, 2018 at 09:25:15AM -0700, Kees Cook wrote:
> On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote:
> > Add the current value of an architecture specific protection keys
> > register (currently PKRU on x86) to data available for seccomp-bpf
> > programs to work on. This allows filters based on the currently
> > enabled protection keys.
> >
> > Support for protection keys on the POWER architecture is not part of
> > this patch since I do not have access to a PowerPC, but adding support
> > for it can be achieved by setting sd->pkeys to the AMR register in
> > populate_seccomp_data.
Maybe you can use a generic read_pkey() function, and each arch can
provide their own implementation. In the case of powerpc it is
mfspr(SPRN_AMR);
something like the code below might help?
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 92a9962..d79efe3 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -89,6 +89,11 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)
#define __mm_pkey_is_reserved(pkey) (reserved_allocation_mask & \
pkey_alloc_mask(pkey))
+static inline u64 read_pkey()
+{
+return mfspr(SPRN_AMR);
+}
+
static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
{
if (pkey < 0 || pkey >= arch_max_pkey())
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index 19b137f..feea114 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -9,6 +9,11 @@
extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
unsigned long init_val);
+static inline u64 read_pkey()
+{
+return read_pkru();
+}
+
static inline bool arch_pkeys_enabled(void)
{
return boot_cpu_has(X86_FEATURE_OSPKE);
diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
index 2955ba97..f1538c7 100644
--- a/include/linux/pkeys.h
+++ b/include/linux/pkeys.h
@@ -13,6 +13,11 @@
#define PKEY_DEDICATED_EXECUTE_ONLY 0
#define ARCH_VM_PKEY_FLAGS 0
+static inline u64 read_pkey()
+{
+ return 0;
+}
+
static inline int vma_pkey(struct vm_area_struct *vma)
{
return 0;
RP
> >
> > One use case for this patch is disabling unnecessary system calls for a
> > library (e.g. network i/o for a crypto library) while the library runs
> > without disabling the system calls for the whole program (by changing
> > the protection keys before and after the library executes). Using this
> > one could ensure that the library behaves a expected (e.g. the crypto
> > library not sending private keys to a malicious server).
> >
> > This patch also enables lightweight sandboxing of untrusted code using
> > memory protection keys: Protection keys provide memory isolation but
> > for a sandbox system call isolation is needed as well. This patch
> > allows writing a seccomp filter to prevent system calls by the
> > untrusted code while still allowing system calls for the trusted code.
>
> Isn't PKU instruction based? Couldn't a malicious library just change
> the state of the MPK registers? This seems like an easy way to bypass
> any filters that used PKU. I'm not convinced this is a meaningful
> barrier that should be enforced by seccomp.
>
> This can also be done with a signal handler with SECCOMP_RET_TRAP and
> check instruction pointer vs PKU state.
>
> -Kees
>
> >
> > An alternative design would be to extend (c)BPF with a new instruction
> > to read the state of a protection key. This alternate design would
> > provide a simpler interface to the user space since the BPF program
> > would not need to deal with the architecture specific pkeys field in
> > seccomp_data, but the question is, how much of an advantage this would
> > be as the nr field in seccomp_data is already architecture specific.
> > Adding a new instruction for BPF programs is more complicated than
> > this patch and might be a breaking change.
> >
> > Results of selftests/seccomp_benchmark.c on a x86 machine with pkeys
> > support:
> >
> > With patch:
> > Benchmarking 33554432 samples...
> > 28.019505558 - 18.676858522 = 9342647036
> > getpid native: 278 ns
> > 42.279109885 - 28.019657031 = 14259452854
> > getpid RET_ALLOW: 424 ns
> > Estimated seccomp overhead per syscall: 146 ns
> >
> > Without patch:
> > Benchmarking 33554432 samples...
> > 28.059619466 - 18.706769155 = 9352850311
> > getpid native: 278 ns
> > 42.299228279 - 28.059761804 = 14239466475
> > getpid RET_ALLOW: 424 ns
> > Estimated seccomp overhead per syscall: 146 ns
> >
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Ram Pai
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Michael Sammler
> > ---
> > Changes to the previous version:
> > - added motivation, notes about POWER, alternative design and benchmark
> > results to the commit log
> > - renamed pkru field in seccomp_data to pkeys
> > - changed si
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
Hello,
I figured out that the problem is in the OF source code of the commit:
Merge tag devicetree-for-4.20. [1]
I reverted the following OF files and SMP works!
drivers/of/base.c
drivers/of/device.c
drivers/of/of_mdio.c
drivers/of/of_numa.c
drivers/of/of_private.h
drivers/of/overlay.c
drivers/of/platform.c
drivers/of/unittest-data/overlay_15.dts
drivers/of/unittest-data/tests-overlay.dtsi
drivers/of/unittest.c
include/linux/of.h
Cheers,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 29 October 2018 at 10:56AM, Christian Zigotzky wrote:
Hello,
I have figured out that the commit 'devicetree-for-4.20' [1] is
responsible for the SMP problem. I was able to revert this commit with
'git revert b27186abb37b7bd19e0ca434f4f425c807dbd708 -m 1' today.
[master ec81438] Revert "Merge tag 'devicetree-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux"
138 files changed, 931 insertions(+), 1538 deletions(-)
rename Documentation/devicetree/bindings/arm/{atmel-sysregs.txt =>
atmel-at91.txt} (67%)
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
rename Documentation/devicetree/bindings/arm/{zte,sysctrl.txt =>
zte.txt} (62%)
delete mode 100644 Documentation/devicetree/bindings/misc/lwn-bk4.txt
create mode 100644 arch/c6x/boot/dts/linked_dtb.S
delete mode 100644 arch/nios2/boot/dts/Makefile
create mode 100644 arch/nios2/boot/linked_dtb.S
delete mode 100644 arch/powerpc/boot/dts/Makefile
delete mode 100644 arch/powerpc/boot/dts/fsl/Makefile
delete mode 100644 scripts/dtc/yamltree.c
It solves the SMP problem! SMP works again on my P5020 board and on
virtual e5500 QEMU machines.
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel /home/christian/Downloads/uImage-4.20-alpha5 -drive
format=raw,file=/home/christian/Dokumente/ubuntu_MATE_16.04.3_LTS_PowerPC_QEMU/ubuntu_MATE_16.04_PowerPC.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda3" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -soundhw es1370
-smp 4
Screenshot:
https://plus.google.com/u/0/photos/photo/115515624056477014971/6617705776207990082
Do we need a new dtb file or is it a bug?
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 28 October 2018 at 5:35PM, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18 11:12AM
GMT) on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[ 0.00] -
[ 0.00] phys_mem_size = 0x2
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x0003008003b4
[ 0.00] possible = 0x0003009003b4
[ 0.00] always = 0x0003008003b4
[ 0.00] cpu_user_features = 0xcc008000 0x0800
[ 0.00] mmu_features = 0x000a0010
[ 0.00] firmware_features = 0x
[ 0.00] -
[ 0.00] CoreNet Generic board
...
[ 0.002161] smp: Bringing up secondary CPUs ...
[ 0.002339] No cpu-release-addr for cpu 1
[ 0.002347] smp: failed starting cpu 1 (rc -2)
[ 0.002401] smp: Brought up 1 node, 1 CPU
Virtual e5500 quad core QEMU machine:
[ 0.026394] smp: Bringing up secondary CPUs ...
[ 0.027831] No cpu-release-addr for cpu 1
[ 0.027989] smp: failed starting cpu 1 (rc -2)
[ 0.030143] No cpu-release-addr for cpu 2
[ 0.030304] smp: failed starting cpu 2 (rc -2)
[ 0.032400] No cpu-release-addr for cpu 3
[ 0.032533] smp: failed starting cpu 3 (rc -2)
[ 0.033117] smp: Brought up 1 node, 1 CPU
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel
/home/christian/Downloads/vmlinux-4.20-alpha4-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20
-drive
format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw
es1370 -smp 4
.config:
...
CONFIG_SMP=y
CONFIG_NR_CPUS=4
...
Please test the latest Git kernel on your NXP P50XX boards.
Thanks,
Christian
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/2018 05:48 PM, Jann Horn wrote: On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen wrote: On 10/29/18 9:25 AM, Kees Cook wrote: On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote: Add the current value of an architecture specific protection keys register (currently PKRU on x86) to data available for seccomp-bpf programs to work on. This allows filters based on the currently enabled protection keys. How does the current "assignment" of protection keys to the various uses get communicated to the filter? I assume that you first allocate your protection keys, then install the filter? Yes, but I agree that it should probably be documented, that the filter should only look at the parts of the PKRU, which belong to pkeys the user space program allocated (if the kernel wants to use some parts of the PKRU for its own purposes). I'm not sure this is a great use for PKRU. I *think* the basic problem is that you want to communicate some rights information down into a filter, and you want to communicate it with PKRU. While it's handy to have an extra register that nobody (generally) mucks with, I'm not quite convinced that we want to repurpose it this way. That's not how I understand it; I believe that the context is probably https://arxiv.org/pdf/1801.06822.pdf ? My understanding is that PKRU is used for lightweight in-process sandboxing, and to extend this sandbox protection to the syscall interface, it is necessary to expose PKRU state to seccomp filters. In other words, this isn't using PKRU exclusively for passing rights into a filter, but it has to use PKRU anyway. Yes, https://arxiv.org/pdf/1801.06822.pdf is indeed the context and what you say is correct. Also, I'm not sure the kernel provides the PKRU guarantees you want at the moment. Our implementation *probably* works, but it's mostly by accident. I don't know, which guarantees about the PKRU are provided at the moment, but the only guarantee needed for this patch is, that the kernel does not change the bits of the PKRU register, which belong to pkeys allocated by the user program, between the syscall entry and the call to secure_computing(). Is there are use case where the kernel would like to modify these bits of the PKRU? -- MIchael
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/2018 05:48 PM, Ram Pai wrote:
On Mon, Oct 29, 2018 at 09:25:15AM -0700, Kees Cook wrote:
On Mon, Oct 29, 2018 at 4:23 AM, Michael Sammler wrote:
Add the current value of an architecture specific protection keys
register (currently PKRU on x86) to data available for seccomp-bpf
programs to work on. This allows filters based on the currently
enabled protection keys.
Support for protection keys on the POWER architecture is not part of
this patch since I do not have access to a PowerPC, but adding support
for it can be achieved by setting sd->pkeys to the AMR register in
populate_seccomp_data.
Maybe you can use a generic read_pkey() function, and each arch can
provide their own implementation. In the case of powerpc it is
mfspr(SPRN_AMR);
something like the code below might help?
diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h
index 92a9962..d79efe3 100644
--- a/arch/powerpc/include/asm/pkeys.h
+++ b/arch/powerpc/include/asm/pkeys.h
@@ -89,6 +89,11 @@ static inline u16 pte_to_pkey_bits(u64 pteflags)
#define __mm_pkey_is_reserved(pkey) (reserved_allocation_mask & \
pkey_alloc_mask(pkey))
+static inline u64 read_pkey()
+{
+return mfspr(SPRN_AMR);
+}
+
static inline bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
{
if (pkey < 0 || pkey >= arch_max_pkey())
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index 19b137f..feea114 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -9,6 +9,11 @@
extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
unsigned long init_val);
+static inline u64 read_pkey()
+{
+return read_pkru();
+}
+
static inline bool arch_pkeys_enabled(void)
{
return boot_cpu_has(X86_FEATURE_OSPKE);
diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
index 2955ba97..f1538c7 100644
--- a/include/linux/pkeys.h
+++ b/include/linux/pkeys.h
@@ -13,6 +13,11 @@
#define PKEY_DEDICATED_EXECUTE_ONLY 0
#define ARCH_VM_PKEY_FLAGS 0
+static inline u64 read_pkey()
+{
+ return 0;
+}
+
static inline int vma_pkey(struct vm_area_struct *vma)
{
return 0;
RP
Thank you very much, this helps indeed. I will add this to the next
version of this patch.
One use case for this patch is disabling unnecessary system calls for a
library (e.g. network i/o for a crypto library) while the library runs
without disabling the system calls for the whole program (by changing
the protection keys before and after the library executes). Using this
one could ensure that the library behaves a expected (e.g. the crypto
library not sending private keys to a malicious server).
This patch also enables lightweight sandboxing of untrusted code using
memory protection keys: Protection keys provide memory isolation but
for a sandbox system call isolation is needed as well. This patch
allows writing a seccomp filter to prevent system calls by the
untrusted code while still allowing system calls for the trusted code.
Isn't PKU instruction based? Couldn't a malicious library just change
the state of the MPK registers? This seems like an easy way to bypass
any filters that used PKU. I'm not convinced this is a meaningful
barrier that should be enforced by seccomp.
This can also be done with a signal handler with SECCOMP_RET_TRAP and
check instruction pointer vs PKU state.
-Kees
An alternative design would be to extend (c)BPF with a new instruction
to read the state of a protection key. This alternate design would
provide a simpler interface to the user space since the BPF program
would not need to deal with the architecture specific pkeys field in
seccomp_data, but the question is, how much of an advantage this would
be as the nr field in seccomp_data is already architecture specific.
Adding a new instruction for BPF programs is more complicated than
this patch and might be a breaking change.
Results of selftests/seccomp_benchmark.c on a x86 machine with pkeys
support:
With patch:
Benchmarking 33554432 samples...
28.019505558 - 18.676858522 = 9342647036
getpid native: 278 ns
42.279109885 - 28.019657031 = 14259452854
getpid RET_ALLOW: 424 ns
Estimated seccomp overhead per syscall: 146 ns
Without patch:
Benchmarking 33554432 samples...
28.059619466 - 18.706769155 = 9352850311
getpid native: 278 ns
42.299228279 - 28.059761804 = 14239466475
getpid RET_ALLOW: 424 ns
Estimated seccomp overhead per syscall: 146 ns
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Ram Pai
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Michael Sammler
---
Changes to the previous version:
- added motivation, notes about POWER, alternative design and benchmark results
to the commit log
- renamed pkru field in seccomp_data to pkeys
- changed size of pkru field to __u64 and removed reserved field
- added test for x86
arch/mips/kernel/ptrace.c
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/18 10:02 AM, Michael Sammler wrote: >>> Also, I'm not sure the kernel provides the PKRU guarantees you want at >>> the moment. Our implementation *probably* works, but it's mostly by >>> accident. > I don't know, which guarantees about the PKRU are provided at the > moment, but the only guarantee needed for this patch is, that the kernel > does not change the bits of the PKRU register, which belong to pkeys > allocated by the user program, between the syscall entry and the call to > secure_computing(). Is there are use case where the kernel would like to > modify these bits of the PKRU? We've been talking about doing more lax save/restore of the XSAVE content (PKRU is part of this content). We would, for instance, only restore it when returning to userspace, but PKRU might not be up-to-date with the value in current->fpu. It's not a deal-breaker with your approach, it's just something to be careful of and make sure PKRU is up-to-date before you go use it.
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/18 9:48 AM, Jann Horn wrote: > On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen wrote: >> I'm not sure this is a great use for PKRU. I *think* the basic problem >> is that you want to communicate some rights information down into a >> filter, and you want to communicate it with PKRU. While it's handy to >> have an extra register that nobody (generally) mucks with, I'm not quite >> convinced that we want to repurpose it this way. > > That's not how I understand it; I believe that the context is probably > https://arxiv.org/pdf/1801.06822.pdf ? > My understanding is that PKRU is used for lightweight in-process > sandboxing, and to extend this sandbox protection to the syscall > interface, it is necessary to expose PKRU state to seccomp filters. > In other words, this isn't using PKRU exclusively for passing rights > into a filter, but it has to use PKRU anyway. PKRU gives information about rights to various bits of application data. From that, a seccomp filter can infer the context, and thus the ability for the code to call a given syscall at a certain point in time. This makes PKRU an opt-in part of the syscall ABI, which is pretty interesting. We _could_ do the same kind of thing with any callee-saved general purpose register, but PKRU is particularly attractive because there is only one instruction that writes to it (well, outside of XSAVE*), and random library code is very unlikely at this point to be using it. PKRU getting reset on signals, and the requirement now that it *can't* be changed if you make syscalls probably needs to get thought about very carefully before we do this, though.
[PATCH 6/7] smp: Don't yell about IRQs disabled in kgdb_roundup_cpus()
In kgdb_roundup_cpus() we've got code that looks like: local_irq_enable(); smp_call_function(kgdb_call_nmi_hook, NULL, 0); local_irq_disable(); In certain cases when we drop into kgdb (like with sysrq-g on a serial console) we'll get a big yell that looks like: sysrq: SysRq : DEBUG [ cut here ] DEBUG_LOCKS_WARN_ON(current->hardirq_context) WARNING: CPU: 0 PID: 0 at .../kernel/locking/lockdep.c:2875 lockdep_hardirqs_on+0xf0/0x160 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.0 #27 pstate: 604003c9 (nZCv DAIF +PAN -UAO) pc : lockdep_hardirqs_on+0xf0/0x160 ... Call trace: lockdep_hardirqs_on+0xf0/0x160 trace_hardirqs_on+0x188/0x1ac kgdb_roundup_cpus+0x14/0x3c kgdb_cpu_enter+0x53c/0x5cc kgdb_handle_exception+0x180/0x1d4 kgdb_compiled_brk_fn+0x30/0x3c brk_handler+0x134/0x178 do_debug_exception+0xfc/0x178 el1_dbg+0x18/0x78 kgdb_breakpoint+0x34/0x58 sysrq_handle_dbg+0x54/0x5c __handle_sysrq+0x114/0x21c handle_sysrq+0x30/0x3c qcom_geni_serial_isr+0x2dc/0x30c ... ... irq event stamp: ...45 hardirqs last enabled at (...44): [...] __do_softirq+0xd8/0x4e4 hardirqs last disabled at (...45): [...] el1_irq+0x74/0x130 softirqs last enabled at (...42): [...] _local_bh_enable+0x2c/0x34 softirqs last disabled at (...43): [...] irq_exit+0xa8/0x100 ---[ end trace adf21f830c46e638 ]--- Let's add kgdb to the list of reasons not to warn in smp_call_function_many(). That will allow us (in a future patch) to stop calling local_irq_enable() which will get rid of the original splat. NOTE: with this change comes the obvious question: will we start deadlocking more often now when we drop into the debugger. I can't say that for sure one way or the other, but the fact that we do the same logic for "oops_in_progress" makes me feel like it shouldn't happen too often. Also note that the old logic of turning on interrupts temporarily wasn't exactly safe since (I presume) that could have violated spin_lock_irqsave() semantics and ended up with a deadlock of its own. Signed-off-by: Douglas Anderson --- kernel/smp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index 163c451af42e..bb581e58c8dc 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -19,6 +19,7 @@ #include #include #include +#include #include "smpboot.h" @@ -413,7 +414,8 @@ void smp_call_function_many(const struct cpumask *mask, * can't happen. */ WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled() -&& !oops_in_progress && !early_boot_irqs_disabled); +&& !oops_in_progress && !early_boot_irqs_disabled +&& !in_dbg_master()); /* Try to fastpath. So, what's a CPU they want? Ignoring this one. */ cpu = cpumask_first_and(mask, cpu_online_mask); -- 2.19.1.568.g152ad8e336-goog
[PATCH 7/7] kgdb: Remove irq flags and local_irq_enable/disable from roundup
The function kgdb_roundup_cpus() was passed a parameter that was
documented as:
> the flags that will be used when restoring the interrupts. There is
> local_irq_save() call before kgdb_roundup_cpus().
Nobody used those flags. Anyone who wanted to temporarily turn on
interrupts just did local_irq_enable() and local_irq_disable() without
looking at them. So we can definitely remove the flags.
Speaking of calling local_irq_enable(), it seems like a bad idea and
it caused a nice splat on my system with lockdep turned on.
Specifically it hit:
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
See the previous patch in this series ("smp: Don't yell about IRQs
disabled in kgdb_roundup_cpus()") for more details, but the last few
things on the stack were this on my arm64 board:
lockdep_hardirqs_on+0xf0/0x160
trace_hardirqs_on+0x188/0x1ac
kgdb_roundup_cpus+0x14/0x3c
As agrued in the the commit text of ("smp: Don't yell about IRQs
disabled in kgdb_roundup_cpus()"), it seems better to make
smp_call_function() lenient about kgdb than to locally turn on IRQs
here. Thus let's totally remove all the local_irq_enable() and
local_irq_disable() calls from all of the kgdb_roundup_cpus() calls.
Signed-off-by: Douglas Anderson
---
arch/arc/kernel/kgdb.c | 4 +---
arch/arm/kernel/kgdb.c | 4 +---
arch/arm64/kernel/kgdb.c | 4 +---
arch/hexagon/kernel/kgdb.c | 11 ++-
arch/mips/kernel/kgdb.c| 4 +---
arch/powerpc/kernel/kgdb.c | 2 +-
arch/sh/kernel/kgdb.c | 4 +---
arch/sparc/kernel/smp_64.c | 2 +-
arch/x86/kernel/kgdb.c | 9 ++---
include/linux/kgdb.h | 9 ++---
kernel/debug/debug_core.c | 2 +-
11 files changed, 14 insertions(+), 41 deletions(-)
diff --git a/arch/arc/kernel/kgdb.c b/arch/arc/kernel/kgdb.c
index 9a3c34af2ae8..d94d3cb7f9e8 100644
--- a/arch/arc/kernel/kgdb.c
+++ b/arch/arc/kernel/kgdb.c
@@ -197,11 +197,9 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), NULL);
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
- local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
}
struct kgdb_arch arch_kgdb_ops = {
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
index caa0dbe3dc61..a80e9259f7e9 100644
--- a/arch/arm/kernel/kgdb.c
+++ b/arch/arm/kernel/kgdb.c
@@ -175,11 +175,9 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
- local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
}
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
diff --git a/arch/arm64/kernel/kgdb.c b/arch/arm64/kernel/kgdb.c
index a20de58061a8..5d171c26788f 100644
--- a/arch/arm64/kernel/kgdb.c
+++ b/arch/arm64/kernel/kgdb.c
@@ -289,11 +289,9 @@ static void kgdb_call_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
- local_irq_enable();
smp_call_function(kgdb_call_nmi_hook, NULL, 0);
- local_irq_disable();
}
static int __kgdb_notify(struct die_args *args, unsigned long cmd)
diff --git a/arch/hexagon/kernel/kgdb.c b/arch/hexagon/kernel/kgdb.c
index 16c24b22d0b2..30fbc491cf45 100644
--- a/arch/hexagon/kernel/kgdb.c
+++ b/arch/hexagon/kernel/kgdb.c
@@ -119,17 +119,12 @@ void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long
pc)
/**
* kgdb_roundup_cpus - Get other CPUs into a holding pattern
- * @flags: Current IRQ state
*
* On SMP systems, we need to get the attention of the other CPUs
* and get them be in a known state. This should do what is needed
* to get the other CPUs to call kgdb_wait(). Note that on some arches,
* the NMI approach is not used for rounding up all the CPUs. For example,
- * in case of MIPS, smp_call_function() is used to roundup CPUs. In
- * this case, we have to make sure that interrupts are enabled before
- * calling smp_call_function(). The argument to this function is
- * the flags that will be used when restoring the interrupts. There is
- * local_irq_save() call before kgdb_roundup_cpus().
+ * in case of MIPS, smp_call_function() is used to roundup CPUs.
*
* On non-SMP systems, this is not called.
*/
@@ -139,11 +134,9 @@ static void hexagon_kgdb_nmi_hook(void *ignored)
kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs());
}
-void kgdb_roundup_cpus(unsigned long flags)
+void kgdb_roundup_cpus(void)
{
- local_irq_enable();
smp_call_function(hexagon_kgdb_nmi_hook, NULL, 0);
- local_irq_disable();
}
#endif
diff --git a/arch/mips/kernel/kgdb.c b/arch/mips/kernel/kgdb.c
index eb6c0d582626..6671a279966f 100644
--- a/arch/mips/kernel/kgdb.c
+++ b/arch/mips/kernel/kgdb.c
@@ -219,11 +2
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
Christian Zigotzky a écrit :
Hello,
I figured out that the problem is in the OF source code of the
commit: Merge tag devicetree-for-4.20. [1]
That's a merge commit. Can you bisect the branch and identify the
faulting commit ?
Christophe
I reverted the following OF files and SMP works!
drivers/of/base.c
drivers/of/device.c
drivers/of/of_mdio.c
drivers/of/of_numa.c
drivers/of/of_private.h
drivers/of/overlay.c
drivers/of/platform.c
drivers/of/unittest-data/overlay_15.dts
drivers/of/unittest-data/tests-overlay.dtsi
drivers/of/unittest.c
include/linux/of.h
Cheers,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 29 October 2018 at 10:56AM, Christian Zigotzky wrote:
Hello,
I have figured out that the commit 'devicetree-for-4.20' [1] is
responsible for the SMP problem. I was able to revert this commit
with 'git revert b27186abb37b7bd19e0ca434f4f425c807dbd708 -m 1'
today.
[master ec81438] Revert "Merge tag 'devicetree-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux"
138 files changed, 931 insertions(+), 1538 deletions(-)
rename Documentation/devicetree/bindings/arm/{atmel-sysregs.txt =>
atmel-at91.txt} (67%)
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
rename Documentation/devicetree/bindings/arm/{zte,sysctrl.txt =>
zte.txt} (62%)
delete mode 100644 Documentation/devicetree/bindings/misc/lwn-bk4.txt
create mode 100644 arch/c6x/boot/dts/linked_dtb.S
delete mode 100644 arch/nios2/boot/dts/Makefile
create mode 100644 arch/nios2/boot/linked_dtb.S
delete mode 100644 arch/powerpc/boot/dts/Makefile
delete mode 100644 arch/powerpc/boot/dts/fsl/Makefile
delete mode 100644 scripts/dtc/yamltree.c
It solves the SMP problem! SMP works again on my P5020 board and on
virtual e5500 QEMU machines.
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel /home/christian/Downloads/uImage-4.20-alpha5 -drive
format=raw,file=/home/christian/Dokumente/ubuntu_MATE_16.04.3_LTS_PowerPC_QEMU/ubuntu_MATE_16.04_PowerPC.img,index=0,if=virtio -nic user,model=e1000 -append "rw root=/dev/vda3" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -soundhw es1370 -smp
4
Screenshot:
https://plus.google.com/u/0/photos/photo/115515624056477014971/6617705776207990082
Do we need a new dtb file or is it a bug?
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 28 October 2018 at 5:35PM, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18
11:12AM GMT) on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[ 0.00] -
[ 0.00] phys_mem_size = 0x2
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x0003008003b4
[ 0.00] possible = 0x0003009003b4
[ 0.00] always = 0x0003008003b4
[ 0.00] cpu_user_features = 0xcc008000 0x0800
[ 0.00] mmu_features = 0x000a0010
[ 0.00] firmware_features = 0x
[ 0.00] -
[ 0.00] CoreNet Generic board
...
[ 0.002161] smp: Bringing up secondary CPUs ...
[ 0.002339] No cpu-release-addr for cpu 1
[ 0.002347] smp: failed starting cpu 1 (rc -2)
[ 0.002401] smp: Brought up 1 node, 1 CPU
Virtual e5500 quad core QEMU machine:
[ 0.026394] smp: Bringing up secondary CPUs ...
[ 0.027831] No cpu-release-addr for cpu 1
[ 0.027989] smp: failed starting cpu 1 (rc -2)
[ 0.030143] No cpu-release-addr for cpu 2
[ 0.030304] smp: failed starting cpu 2 (rc -2)
[ 0.032400] No cpu-release-addr for cpu 3
[ 0.032533] smp: failed starting cpu 3 (rc -2)
[ 0.033117] smp: Brought up 1 node, 1 CPU
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel
/home/christian/Downloads/vmlinux-4.20-alpha4-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20 -drive format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio -nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw es1370 -smp
4
.config:
...
CONFIG_SMP=y
CONFIG_NR_CPUS=4
...
Please test the latest Git kernel on your NXP P50XX boards.
Thanks,
Christian
[PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
post-migration on the destination system CPUs are in nodes 2 and 3.
Handling the node change for a CPU can cause corruption in the slab
cache if we hit a timing where a CPUs node is changed while cache_reap()
is invoked. The corruption occurs because the slab cache code appears
to rely on the CPU and slab cache pages being on the same node.
The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
does not prevent us from hitting this scenario.
Changing the device tree property update notification handler that
recognizes an affinity change for a CPU to do a full DLPAR remove and
add of the CPU instead of dynamically changing its node resolves this
issue.
Signed-off-by: Nathan Fontenot
---
arch/powerpc/include/asm/topology.h |2 ++
arch/powerpc/mm/numa.c |9 +
arch/powerpc/platforms/pseries/hotplug-cpu.c | 19 +++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index a4a718dbfec6..f85e2b01c3df 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -132,6 +132,8 @@ static inline void shared_proc_topology_init(void) {}
#define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu))
#define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu))
#define topology_core_id(cpu) (cpu_to_core_id(cpu))
+
+int dlpar_cpu_readd(int cpu);
#endif
#endif
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 693ae1c1acba..bb6a7b56bef7 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1461,13 +1461,6 @@ static void reset_topology_timer(void)
#ifdef CONFIG_SMP
-static void stage_topology_update(int core_id)
-{
- cpumask_or(&cpu_associativity_changes_mask,
- &cpu_associativity_changes_mask, cpu_sibling_mask(core_id));
- reset_topology_timer();
-}
-
static int dt_update_callback(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -1480,7 +1473,7 @@ static int dt_update_callback(struct notifier_block *nb,
!of_prop_cmp(update->prop->name, "ibm,associativity")) {
u32 core_id;
of_property_read_u32(update->dn, "reg", &core_id);
- stage_topology_update(core_id);
+ rc = dlpar_cpu_readd(core_id);
rc = NOTIFY_OK;
}
break;
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 2f8e62163602..97feb6e79f1a 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -802,6 +802,25 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
return rc;
}
+int dlpar_cpu_readd(int cpu)
+{
+ struct device_node *dn;
+ struct device *dev;
+ u32 drc_index;
+ int rc;
+
+ dev = get_cpu_device(cpu);
+ dn = dev->of_node;
+
+ rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
+
+ rc = dlpar_cpu_remove_by_index(drc_index);
+ if (!rc)
+ rc = dlpar_cpu_add(drc_index);
+
+ return rc;
+}
+
int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
{
u32 count, drc_index;
Re: [PATCH v08 0/5] powerpc/hotplug: Update affinity for migrated CPUs
On Sun, 29 Jul 2018 08:18:34 -0500 Michael Bringmann wrote: > The migration of LPARs across Power systems affects many attributes > including that of the associativity of CPUs. The patches in this > set execute when a system is coming up fresh upon a migration target. > They are intended to, > > * Recognize changes to the associativity of CPUs recorded in internal > data structures when compared to the latest copies in the device > tree. > * Generate calls to other code layers to reset the data structures > related to associativity of the CPUs. > * Re-register the 'changed' entities into the target system. > Re-registration of CPUs mostly entails acting as if they have been > newly hot-added into the target system. > > Signed-off-by: Michael Bringmann > Hello, what is the status of this patchset other than it no longer applies? Thanks Michal
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
Hello Christophe,
Bisecting isn’t necessary because the problem is in the following files.
drivers/of/base.c
drivers/of/device.c
drivers/of/of_mdio.c
drivers/of/of_numa.c
drivers/of/of_private.h
drivers/of/overlay.c
drivers/of/platform.c
drivers/of/unittest-data/overlay_15.dts
drivers/of/unittest-data/tests-overlay.dtsi
drivers/of/unittest.c
include/linux/of.h
I removed the OF modifications from the merge commit 'devicetree-for-4.20' and
SMP works again.
Cheers,
Christian
Sent from my iPhone
> On 29. Oct 2018, at 19:13, LEROY Christophe wrote:
>
> Christian Zigotzky a écrit :
>
>> Hello,
>>
>> I figured out that the problem is in the OF source code of the commit: Merge
>> tag devicetree-for-4.20. [1]
>
> That's a merge commit. Can you bisect the branch and identify the faulting
> commit ?
>
> Christophe
>
>>
>> I reverted the following OF files and SMP works!
>>
>> drivers/of/base.c
>> drivers/of/device.c
>> drivers/of/of_mdio.c
>> drivers/of/of_numa.c
>> drivers/of/of_private.h
>> drivers/of/overlay.c
>> drivers/of/platform.c
>> drivers/of/unittest-data/overlay_15.dts
>> drivers/of/unittest-data/tests-overlay.dtsi
>> drivers/of/unittest.c
>> include/linux/of.h
>>
>> Cheers,
>> Christian
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
>>
>>
>>> On 29 October 2018 at 10:56AM, Christian Zigotzky wrote:
>>> Hello,
>>>
>>> I have figured out that the commit 'devicetree-for-4.20' [1] is responsible
>>> for the SMP problem. I was able to revert this commit with 'git revert
>>> b27186abb37b7bd19e0ca434f4f425c807dbd708 -m 1' today.
>>>
>>> [master ec81438] Revert "Merge tag 'devicetree-for-4.20' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux"
>>> 138 files changed, 931 insertions(+), 1538 deletions(-)
>>> rename Documentation/devicetree/bindings/arm/{atmel-sysregs.txt =>
>>> atmel-at91.txt} (67%)
>>> delete mode 100644
>>> Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
>>> delete mode 100644
>>> Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
>>> rename Documentation/devicetree/bindings/arm/{zte,sysctrl.txt => zte.txt}
>>> (62%)
>>> delete mode 100644 Documentation/devicetree/bindings/misc/lwn-bk4.txt
>>> create mode 100644 arch/c6x/boot/dts/linked_dtb.S
>>> delete mode 100644 arch/nios2/boot/dts/Makefile
>>> create mode 100644 arch/nios2/boot/linked_dtb.S
>>> delete mode 100644 arch/powerpc/boot/dts/Makefile
>>> delete mode 100644 arch/powerpc/boot/dts/fsl/Makefile
>>> delete mode 100644 scripts/dtc/yamltree.c
>>>
>>> It solves the SMP problem! SMP works again on my P5020 board and on virtual
>>> e5500 QEMU machines.
>>>
>>> QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048 -kernel
>>> /home/christian/Downloads/uImage-4.20-alpha5 -drive
>>> format=raw,file=/home/christian/Dokumente/ubuntu_MATE_16.04.3_LTS_PowerPC_QEMU/ubuntu_MATE_16.04_PowerPC.img,index=0,if=virtio
>>> -nic user,model=e1000 -append "rw root=/dev/vda3" -device virtio-vga
>>> -device virtio-mouse-pci -device virtio-keyboard-pci -soundhw es1370 -smp 4
>>>
>>> Screenshot:
>>> https://plus.google.com/u/0/photos/photo/115515624056477014971/6617705776207990082
>>>
>>> Do we need a new dtb file or is it a bug?
>>>
>>> Thanks,
>>> Christian
>>>
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
>>>
>>>
On 28 October 2018 at 5:35PM, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18 11:12AM GMT)
on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[0.00] -
[0.00] phys_mem_size = 0x2
[0.00] dcache_bsize = 0x40
[0.00] icache_bsize = 0x40
[0.00] cpu_features = 0x0003008003b4
[0.00] possible= 0x0003009003b4
[0.00] always = 0x0003008003b4
[0.00] cpu_user_features = 0xcc008000 0x0800
[0.00] mmu_features = 0x000a0010
[0.00] firmware_features = 0x
[0.00] -
[0.00] CoreNet Generic board
...
[0.002161] smp: Bringing up secondary CPUs ...
[0.002339] No cpu-release-addr for cpu 1
[0.002347] smp: failed starting cpu 1 (rc -2)
[0.002401] smp: Brought up 1 node, 1 CPU
Virtual e5500 quad core QEMU machine:
[0.026394] smp: Bringing up secondary CPUs ...
[0.027831] No cpu-release-addr for cpu 1
[0.027989] smp: failed starting cpu 1 (rc -2)
[0.030143] No cpu-release-addr for cpu 2
[0.030304] smp: failed starting cpu
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
Am 29.10.2018 um 18:29 schrieb Dave Hansen: On 10/29/18 9:48 AM, Jann Horn wrote: On Mon, Oct 29, 2018 at 5:37 PM Dave Hansen wrote: I'm not sure this is a great use for PKRU. I *think* the basic problem is that you want to communicate some rights information down into a filter, and you want to communicate it with PKRU. While it's handy to have an extra register that nobody (generally) mucks with, I'm not quite convinced that we want to repurpose it this way. That's not how I understand it; I believe that the context is probably https://arxiv.org/pdf/1801.06822.pdf ? My understanding is that PKRU is used for lightweight in-process sandboxing, and to extend this sandbox protection to the syscall interface, it is necessary to expose PKRU state to seccomp filters. In other words, this isn't using PKRU exclusively for passing rights into a filter, but it has to use PKRU anyway. PKRU gives information about rights to various bits of application data. From that, a seccomp filter can infer the context, and thus the ability for the code to call a given syscall at a certain point in time. This makes PKRU an opt-in part of the syscall ABI, which is pretty interesting. We _could_ do the same kind of thing with any callee-saved general purpose register, but PKRU is particularly attractive because there is only one instruction that writes to it (well, outside of XSAVE*), and random library code is very unlikely at this point to be using it. I agree with you on the points, why PKRU is particularly attractive but I think the most important point is that PKRU is _not_ a general purpose register, but is already used to control access to some resource (memory). This patch would allow to also control access to another resource (system calls) using the PKRU. This is why it makes sense to use the PKRU in this patch instead of another callee-saved register. PKRU getting reset on signals, and the requirement now that it *can't* be changed if you make syscalls probably needs to get thought about very carefully before we do this, though. I am not sure, whether I follow you. Are you saying, that PKRU is currently not guaranteed to be preserved across system calls? This would make it very hard to use protection keys if libc does not save and restore the PKRU before/after systemcalls (and I am not aware of this). Or do you mean, that the kernel might want to use the PKRU register for its own purposes while it is executing? Then the solution you proposed in another email in this thread would work: instead of providing the seccomp filter with the current value of the PKRU (which might be different from what the user space expects) use the user space value which must have been saved somewhere (otherwise it would not be possible to restore it). Or are you afraid, that one part of a user space program installs a seccomp filter, which blocks system calls based on the PKRU, and another part of the same program (maybe a library) changes the PKRU in a way, which the first part did not expect and the program dies because it tries to do a forbidden system call? I don't know whether the kernel can (and wants) do anything against this. This problem also exists without this patch if you replace system call with memory access. -- Michael
Re: [PATCH] seccomp: Add pkru into seccomp_data
On Thu, Oct 25, 2018 at 5:49 PM, Andy Lutomirski wrote: >> On Oct 25, 2018, at 5:35 PM, Kees Cook wrote: >> >>> On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski >>> wrote: >>> You could bite the bullet and add seccomp eBPF support :) >> >> I'm not convinced this is a good enough reason for gaining the eBPF >> attack surface yet. > > Is it an interesting attack surface? It’s certainly scarier if you’re > worried about attacks from the sandbox creator, but the security inside the > sandbox should be more or less equivalent, no? Yeah, I'm more worried about the creator: I don't want kernel exploits via seccomp APIs. :P There have been kind of a long list of eBPF-related flaws, so I'd really rather not tie seccomp to it. As for sandbox escapes, I don't think there's too much concern, but I do worry about "unexpected" situations exposed by eBPF (i.e. maps or functions not doing what was expected, or allowing map manipulation from outside). seccomp cBPF is pretty self-contained right now, so I'd like a strong reason to justify the increase in code complexity and related attack surface. -- Kees Cook
Re: [PATCH 2/2] selftests/powerpc: Skip test instead of failing
Breno Leitao writes:
> Hi Tyrel,
>
> On 10/23/2018 05:41 PM, Tyrel Datwyler wrote:
>>> --- a/tools/testing/selftests/powerpc/ptrace/core-pkey.c
>>> +++ b/tools/testing/selftests/powerpc/ptrace/core-pkey.c
>>> @@ -352,17 +352,11 @@ static int write_core_pattern(const char
>>> *core_pattern)
>>> FILE *f;
>>>
>>> f = fopen(core_pattern_file, "w");
>>> - if (!f) {
>>> - perror("Error writing to core_pattern file");
>>> - return TEST_FAIL;
>>> - }
>>> + SKIP_IF(!f);
>>>
>>> ret = fwrite(core_pattern, 1, len, f);
>>> fclose(f);
>>> - if (ret != len) {
>>> - perror("Error writing to core_pattern file");
>>> - return TEST_FAIL;
>>> - }
>>> + SKIP_IF(ret != len);
>
>> If we don't have proper privileges we should fail on the open, right?
>> So wouldn't we still want to fail on the write if something goes
>> wrong?
>
> That is a good point. Should the test fail or skip if it is not possible
> to create the infrastructure to run the core test?
>
> Trying to find the answer in the current test sets, I find tests where
> the self test skips if the test environment is not able to be set up, as
> for example, when a memory allocation fails.
>
> File: tools/testing/selftests/powerpc/alignment/alignment_handler.c
>
> ci1 = mmap(NULL, bufsize, PROT_WRITE, MAP_SHARED,
>fd, bufsize);
> if ((ci0 == MAP_FAILED) || (ci1 == MAP_FAILED)) {
> printf("\n");
> perror("mmap failed");
> SKIP_IF(1);
> }
I think TEST_FAIL means the test was able to exercise the feature
and found a problem with it. In this case, the test wasn't able to
exercise the feature so it's not appropriate.
Ideally, there should be a TEST_ERROR result for a case like this where
an unexpected problem prevented the testcase from exercising the
feature.
If we're to use the an existing result then I vote for SKIP_IF.
For reference, here are the test results that DejaGnu supports (it is
the test harness used by some GNU projects):
https://www.gnu.org/software/dejagnu/manual/Output-States.html
I would say that SKIP_IF corresponds to UNSUPPORTED in DejaGnu.
--
Thiago Jung Bauermann
IBM Linux Technology Center
NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
Little progress ...
I reverted the following two OF files of the commit 'Merge tag
devicetree-for-4.20' and SMP works! The problematic code is somewhere in
these two files.
a/include/linux/of.h
a/drivers/of/base.c
-- Christian
On 29 October 2018 at 6:00PM, Christian Zigotzky wrote:
Hello,
I figured out that the problem is in the OF source code of the commit:
Merge tag devicetree-for-4.20. [1]
I reverted the following OF files and SMP works!
drivers/of/base.c
drivers/of/device.c
drivers/of/of_mdio.c
drivers/of/of_numa.c
drivers/of/of_private.h
drivers/of/overlay.c
drivers/of/platform.c
drivers/of/unittest-data/overlay_15.dts
drivers/of/unittest-data/tests-overlay.dtsi
drivers/of/unittest.c
include/linux/of.h
Cheers,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 29 October 2018 at 10:56AM, Christian Zigotzky wrote:
Hello,
I have figured out that the commit 'devicetree-for-4.20' [1] is
responsible for the SMP problem. I was able to revert this commit
with 'git revert b27186abb37b7bd19e0ca434f4f425c807dbd708 -m 1' today.
[master ec81438] Revert "Merge tag 'devicetree-for-4.20' of
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux"
138 files changed, 931 insertions(+), 1538 deletions(-)
rename Documentation/devicetree/bindings/arm/{atmel-sysregs.txt =>
atmel-at91.txt} (67%)
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt
delete mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-scfg.txt
rename Documentation/devicetree/bindings/arm/{zte,sysctrl.txt =>
zte.txt} (62%)
delete mode 100644 Documentation/devicetree/bindings/misc/lwn-bk4.txt
create mode 100644 arch/c6x/boot/dts/linked_dtb.S
delete mode 100644 arch/nios2/boot/dts/Makefile
create mode 100644 arch/nios2/boot/linked_dtb.S
delete mode 100644 arch/powerpc/boot/dts/Makefile
delete mode 100644 arch/powerpc/boot/dts/fsl/Makefile
delete mode 100644 scripts/dtc/yamltree.c
It solves the SMP problem! SMP works again on my P5020 board and on
virtual e5500 QEMU machines.
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel /home/christian/Downloads/uImage-4.20-alpha5 -drive
format=raw,file=/home/christian/Dokumente/ubuntu_MATE_16.04.3_LTS_PowerPC_QEMU/ubuntu_MATE_16.04_PowerPC.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda3" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -soundhw es1370
-smp 4
Screenshot:
https://plus.google.com/u/0/photos/photo/115515624056477014971/6617705776207990082
Do we need a new dtb file or is it a bug?
Thanks,
Christian
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b27186abb37b7bd19e0ca434f4f425c807dbd708
On 28 October 2018 at 5:35PM, Christian Zigotzky wrote:
Hello,
SMP doesn't work anymore with the latest Git kernel (28/10/18
11:12AM GMT) on my P5020 board and on virtual e5500 QEMU machines.
Board with P5020 dual core CPU:
[ 0.00] -
[ 0.00] phys_mem_size = 0x2
[ 0.00] dcache_bsize = 0x40
[ 0.00] icache_bsize = 0x40
[ 0.00] cpu_features = 0x0003008003b4
[ 0.00] possible = 0x0003009003b4
[ 0.00] always = 0x0003008003b4
[ 0.00] cpu_user_features = 0xcc008000 0x0800
[ 0.00] mmu_features = 0x000a0010
[ 0.00] firmware_features = 0x
[ 0.00] -
[ 0.00] CoreNet Generic board
...
[ 0.002161] smp: Bringing up secondary CPUs ...
[ 0.002339] No cpu-release-addr for cpu 1
[ 0.002347] smp: failed starting cpu 1 (rc -2)
[ 0.002401] smp: Brought up 1 node, 1 CPU
Virtual e5500 quad core QEMU machine:
[ 0.026394] smp: Bringing up secondary CPUs ...
[ 0.027831] No cpu-release-addr for cpu 1
[ 0.027989] smp: failed starting cpu 1 (rc -2)
[ 0.030143] No cpu-release-addr for cpu 2
[ 0.030304] smp: failed starting cpu 2 (rc -2)
[ 0.032400] No cpu-release-addr for cpu 3
[ 0.032533] smp: failed starting cpu 3 (rc -2)
[ 0.033117] smp: Brought up 1 node, 1 CPU
QEMU command: ./qemu-system-ppc64 -M ppce500 -cpu e5500 -m 2048
-kernel
/home/christian/Downloads/vmlinux-4.20-alpha4-AmigaOne_X1000_X5000/X5000_and_QEMU_e5500/uImage-4.20
-drive
format=raw,file=/home/christian/Downloads/MATE_PowerPC_Remix_2017_0.9.img,index=0,if=virtio
-nic user,model=e1000 -append "rw root=/dev/vda" -device virtio-vga
-device virtio-mouse-pci -device virtio-keyboard-pci -usb -soundhw
es1370 -smp 4
.config:
...
CONFIG_SMP=y
CONFIG_NR_CPUS=4
...
Please test the latest Git kernel on your NXP P50XX boards.
Thanks,
Christian
Re: [RFC PATCH] seccomp: Add protection keys into seccomp_data
On 10/29/18 2:55 PM, Michael Sammler wrote: >> PKRU getting reset on signals, and the requirement now that it *can't* >> be changed if you make syscalls probably needs to get thought about very >> carefully before we do this, though. > I am not sure, whether I follow you. Are you saying, that PKRU is > currently not guaranteed to be preserved across system calls? > This would make it very hard to use protection keys if libc does not > save and restore the PKRU before/after systemcalls (and I am not aware > of this). It's preserved *across* system calls, but you have to be a bit careful using it _inside_ the kernel. We could context switch off to something else, and not think that we need to restore PKRU until _just_ before we return to userspace. > Or do you mean, that the kernel might want to use the PKRU register for > its own purposes while it is executing? That, or we might keep another process's PKRU state in the register if we don't think anyone is using it. Now that I think about it, I think Rik (cc'd, who was working on those patches) *had* to explicitly restore PKRU because it's hard to tell where we might do a copy_to/from_user() and need it. > Then the solution you proposed in another email in this thread would > work: instead of providing the seccomp filter with the current value of > the PKRU (which might be different from what the user space expects) use > the user space value which must have been saved somewhere (otherwise it > would not be possible to restore it). Yep, that's the worst-case scenario: either fetch PKRU out of the XSAVE buffer (current->fpu->something), or just restore them using an existing API before doing RDPKRU. But, that's really an implementation detail. The effect on the ABI and how this might constrain future pkeys use is my bigger worry. I'd also want to make sure that your specific use-case is compatible with all the oddities of pkeys, like the 'clone' and signal behavior. Some of that is spelled out here: http://man7.org/linux/man-pages/man7/pkeys.7.html One thing that's a worry is that we have never said that you *can't* write to arbitrary permissions in PKRU. I can totally see some really paranoid code saying, "I'm about to do something risky, so I'll turn off access to *all* pkeys", or " turn off all access except my current stack". If they did that, they might also inadvertently disable access to certain seccomp-restricted syscalls. We can fix that up by documenting restrictions like "code should never change the access rights of any pkey other than those that it allocated", but that doesn't help any old code (of which I hope there is relatively little).
[PATCH 0/7] serial: Finish kgdb on qcom_geni; fix many lockdep splats w/ kgdb
I started out this series trying to make sysrq work over the serial console on qcom_geni_serial, then fell into a rat's nest. To solve the deadlock I faced when enabling sysrq I tried to borrow code from '8250_port.c' which avoided grabbing the port lock in console_write(). ...but since these days I try to run with lockdep on all the time, I found it caused an annoying lockdep splat (which I also reproduced on my rk3399 board). ...so I instead changed my qcom_geni_serial solution to borrow code from 'msm_serial.c' I wasn't super happy with the solution in 'msm_serial.c' though. I don't like releasing the spinlock there. Not only is it ugly but it means we are unlocking / re-locking _all the time_ even though sysrq characters are rare. ...so I came up with what I think is a better solution and then implemented it for qcom_geni_serial. Since I had a good way to test 8250-based UARTs, I also fixed that driver to use my new method. When doing so, I ran into a missing msm_serial.c at all, so I didn't switch that (or all other serial drivers for that matter) to the new method. After fixing all the above issues, I found the next lockdep splat in kgdb and I think I've worked around it in a good-enough way, but I'm much less confident about this. Hopefully folks can take a look at it. In general, patches earlier in this series should be "less controversial" and hopefully can land even if people don't like patches later in the series. ;-) Looking back, this is pretty much two series squashed that could be treated indepdently. The first is a serial series and the second is a kgdb series. For all serial patches I'd expect them to go through the tty tree once they've been reviewed. If folks are OK w/ the 'smp' patch it probably should go in some core kernel tree. The kgdb patch won't work without it, though, so to land that we'd need coordination between the folks landing that and the folks landing the 'smp' patch. Douglas Anderson (7): serial: qcom_geni_serial: Finish supporting sysrq serial: core: Allow processing sysrq at port unlock time serial: qcom_geni_serial: Process sysrq at port unlock time serial: core: Include console.h from serial_core.h serial: 8250: Process sysrq at port unlock time smp: Don't yell about IRQs disabled in kgdb_roundup_cpus() kgdb: Remove irq flags and local_irq_enable/disable from roundup arch/arc/kernel/kgdb.c | 4 +-- arch/arm/kernel/kgdb.c | 4 +-- arch/arm64/kernel/kgdb.c| 4 +-- arch/hexagon/kernel/kgdb.c | 11 ++ arch/mips/kernel/kgdb.c | 4 +-- arch/powerpc/kernel/kgdb.c | 2 +- arch/sh/kernel/kgdb.c | 4 +-- arch/sparc/kernel/smp_64.c | 2 +- arch/x86/kernel/kgdb.c | 9 ++--- drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +++- drivers/tty/serial/8250/8250_fsl.c | 6 +++- drivers/tty/serial/8250/8250_omap.c | 6 +++- drivers/tty/serial/8250/8250_port.c | 8 ++--- drivers/tty/serial/qcom_geni_serial.c | 10 -- include/linux/kgdb.h| 9 ++--- include/linux/serial_core.h | 38 - kernel/debug/debug_core.c | 2 +- kernel/smp.c| 4 ++- 18 files changed, 80 insertions(+), 53 deletions(-) -- 2.19.1.568.g152ad8e336-goog
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
On Mon, 2018-10-29 at 21:12 +0100, Christian Zigotzky wrote: > Hello Christophe, > > Bisecting isn’t necessary because the problem is in the following files. > > drivers/of/base.c > drivers/of/device.c > drivers/of/of_mdio.c > drivers/of/of_numa.c > drivers/of/of_private.h > drivers/of/overlay.c > drivers/of/platform.c > drivers/of/unittest-data/overlay_15.dts > drivers/of/unittest-data/tests-overlay.dtsi > drivers/of/unittest.c > include/linux/of.h > > I removed the OF modifications from the merge commit 'devicetree-for-4.20' > and SMP works again. Bisecting to get the specific non-merge commit that broke things would be much more useful than simply identifying the affected file (especially if it's a smallish change). -Scott
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
On 30 October 2018 at 00:04AM, Scott Wood wrote:
On Mon, 2018-10-29 at 21:12 +0100, Christian Zigotzky wrote:
Hello Christophe,
Bisecting isn’t necessary because the problem is in the following files.
drivers/of/base.c
drivers/of/device.c
drivers/of/of_mdio.c
drivers/of/of_numa.c
drivers/of/of_private.h
drivers/of/overlay.c
drivers/of/platform.c
drivers/of/unittest-data/overlay_15.dts
drivers/of/unittest-data/tests-overlay.dtsi
drivers/of/unittest.c
include/linux/of.h
I removed the OF modifications from the merge commit 'devicetree-for-4.20'
and SMP works again.
Bisecting to get the specific non-merge commit that broke things would be much
more useful than simply identifying the affected file (especially if it's a
smallish change).
-Scott
You're right but I had no luck with bisecting in the past. I think I
have to learn it more.
I found the problematic code and I created a patch today. SMP works with
this patch again.
Link: http://www.xenosoft.de/of.patch
of.patch
---
diff -rupN a/drivers/of/base.c b/drivers/of/base.c
--- a/drivers/of/base.c 2018-10-30 01:00:59.814808778 +0100
+++ b/drivers/of/base.c 2018-10-30 01:00:27.990741603 +0100
@@ -394,7 +394,7 @@ struct device_node *of_get_cpu_node(int
{
struct device_node *cpun;
- for_each_of_cpu_node(cpun) {
+ for_each_node_by_type(cpun, "cpu") {
if (arch_find_n_match_cpu_physical_id(cpun, cpu, thread))
return cpun;
}
@@ -749,45 +749,6 @@ struct device_node *of_get_next_availabl
EXPORT_SYMBOL(of_get_next_available_child);
/**
- * of_get_next_cpu_node - Iterate on cpu nodes
- * @prev: previous child of the /cpus node, or NULL to get first
- *
- * Returns a cpu node pointer with refcount incremented, use
of_node_put()
- * on it when done. Returns NULL when prev is the last child. Decrements
- * the refcount of prev.
- */
-struct device_node *of_get_next_cpu_node(struct device_node *prev)
-{
- struct device_node *next = NULL;
- unsigned long flags;
- struct device_node *node;
-
- if (!prev)
- node = of_find_node_by_path("/cpus");
-
- raw_spin_lock_irqsave(&devtree_lock, flags);
- if (prev)
- next = prev->sibling;
- else if (node) {
- next = node->child;
- of_node_put(node);
- }
- for (; next; next = next->sibling) {
- if (!(of_node_name_eq(next, "cpu") ||
- (next->type && !of_node_cmp(next->type, "cpu"
- continue;
- if (!__of_device_is_available(next))
- continue;
- if (of_node_get(next))
- break;
- }
- of_node_put(prev);
- raw_spin_unlock_irqrestore(&devtree_lock, flags);
- return next;
-}
-EXPORT_SYMBOL(of_get_next_cpu_node);
-
-/**
* of_get_compatible_child - Find compatible child node
* @parent: parent node
* @compatible: compatible string
diff -rupN a/include/linux/of.h b/include/linux/of.h
--- a/include/linux/of.h 2018-10-30 01:01:01.034811355 +0100
+++ b/include/linux/of.h 2018-10-30 00:56:18.054216284 +0100
@@ -347,7 +347,6 @@ extern const void *of_get_property(const
const char *name,
int *lenp);
extern struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
-extern struct device_node *of_get_next_cpu_node(struct device_node *prev);
#define for_each_property_of_node(dn, pp) \
for (pp = dn->properties; pp != NULL; pp = pp->next)
@@ -754,11 +753,6 @@ static inline struct device_node *of_get
return NULL;
}
-static inline struct device_node *of_get_next_cpu_node(struct
device_node *prev)
-{
- return NULL;
-}
-
static inline int of_n_addr_cells(struct device_node *np)
{
return 0;
@@ -1229,10 +1223,6 @@ static inline int of_property_read_s32(c
for (child = of_get_next_available_child(parent, NULL); child !=
NULL; \
child = of_get_next_available_child(parent, child))
-#define for_each_of_cpu_node(cpu) \
- for (cpu = of_get_next_cpu_node(NULL); cpu != NULL; \
- cpu = of_get_next_cpu_node(cpu))
-
#define for_each_node_with_property(dn, prop_name) \
for (dn = of_find_node_with_property(NULL, prop_name); dn; \
dn = of_find_node_with_property(dn, prop_name))
---
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
OF patch for the latest Git kernel: http://www.xenosoft.de/of_v2.patch
- of_v2.patch -
diff -rupN a/drivers/of/base.c b/drivers/of/base.c
--- a/drivers/of/base.c 2018-10-30 02:19:30.827089495 +0100
+++ b/drivers/of/base.c 2018-10-30 02:18:51.666856715 +0100
@@ -395,7 +395,7 @@ struct device_node *of_get_cpu_node(int
{
struct device_node *cpun;
- for_each_of_cpu_node(cpun) {
+ for_each_node_by_type(cpun, "cpu") {
if (arch_find_n_match_cpu_physical_id(cpun, cpu, thread))
return cpun;
}
@@ -750,45 +750,6 @@ struct device_node *of_get_next_availabl
EXPORT_SYMBOL(of_get_next_available_child);
/**
- * of_get_next_cpu_node - Iterate on cpu nodes
- * @prev: previous child of the /cpus node, or NULL to get first
- *
- * Returns a cpu node pointer with refcount incremented, use
of_node_put()
- * on it when done. Returns NULL when prev is the last child. Decrements
- * the refcount of prev.
- */
-struct device_node *of_get_next_cpu_node(struct device_node *prev)
-{
- struct device_node *next = NULL;
- unsigned long flags;
- struct device_node *node;
-
- if (!prev)
- node = of_find_node_by_path("/cpus");
-
- raw_spin_lock_irqsave(&devtree_lock, flags);
- if (prev)
- next = prev->sibling;
- else if (node) {
- next = node->child;
- of_node_put(node);
- }
- for (; next; next = next->sibling) {
- if (!(of_node_name_eq(next, "cpu") ||
- (next->type && !of_node_cmp(next->type, "cpu"
- continue;
- if (!__of_device_is_available(next))
- continue;
- if (of_node_get(next))
- break;
- }
- of_node_put(prev);
- raw_spin_unlock_irqrestore(&devtree_lock, flags);
- return next;
-}
-EXPORT_SYMBOL(of_get_next_cpu_node);
-
-/**
* of_get_compatible_child - Find compatible child node
* @parent: parent node
* @compatible: compatible string
diff -rupN a/include/linux/of.h b/include/linux/of.h
--- a/include/linux/of.h 2018-10-30 02:19:32.047096634 +0100
+++ b/include/linux/of.h 2018-10-30 02:18:51.666856715 +0100
@@ -347,7 +347,6 @@ extern const void *of_get_property(const
const char *name,
int *lenp);
extern struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
-extern struct device_node *of_get_next_cpu_node(struct device_node *prev);
#define for_each_property_of_node(dn, pp) \
for (pp = dn->properties; pp != NULL; pp = pp->next)
@@ -757,11 +756,6 @@ static inline struct device_node *of_get
return NULL;
}
-static inline struct device_node *of_get_next_cpu_node(struct
device_node *prev)
-{
- return NULL;
-}
-
static inline int of_n_addr_cells(struct device_node *np)
{
return 0;
@@ -1239,10 +1233,6 @@ static inline int of_property_read_s32(c
for (child = of_get_next_available_child(parent, NULL); child !=
NULL; \
child = of_get_next_available_child(parent, child))
-#define for_each_of_cpu_node(cpu) \
- for (cpu = of_get_next_cpu_node(NULL); cpu != NULL; \
- cpu = of_get_next_cpu_node(cpu))
-
#define for_each_node_with_property(dn, prop_name) \
for (dn = of_find_node_with_property(NULL, prop_name); dn; \
dn = of_find_node_with_property(dn, prop_name))
Re: NXP P50XX/e5500: SMP doesn't work anymore with the latest Git kernel
On Tue, 2018-10-30 at 02:42 +0100, Christian Zigotzky wrote:
> OF patch for the latest Git kernel: http://www.xenosoft.de/of_v2.patch
This just seems to revert a whole bunch of stuff, not really the right
way to go. Why is of_get_next_cpu_node() not finding your CPUs ? There
must be something wrong with the device-tree...
> - of_v2.patch -
>
> diff -rupN a/drivers/of/base.c b/drivers/of/base.c
> --- a/drivers/of/base.c2018-10-30 02:19:30.827089495 +0100
> +++ b/drivers/of/base.c2018-10-30 02:18:51.666856715 +0100
> @@ -395,7 +395,7 @@ struct device_node *of_get_cpu_node(int
> {
> struct device_node *cpun;
>
> -for_each_of_cpu_node(cpun) {
> +for_each_node_by_type(cpun, "cpu") {
> if (arch_find_n_match_cpu_physical_id(cpun, cpu, thread))
> return cpun;
> }
> @@ -750,45 +750,6 @@ struct device_node *of_get_next_availabl
> EXPORT_SYMBOL(of_get_next_available_child);
>
> /**
> - *of_get_next_cpu_node - Iterate on cpu nodes
> - *@prev:previous child of the /cpus node, or NULL to get first
> - *
> - *Returns a cpu node pointer with refcount incremented, use
> of_node_put()
> - *on it when done. Returns NULL when prev is the last child. Decrements
> - *the refcount of prev.
> - */
> -struct device_node *of_get_next_cpu_node(struct device_node *prev)
> -{
> -struct device_node *next = NULL;
> -unsigned long flags;
> -struct device_node *node;
> -
> -if (!prev)
> -node = of_find_node_by_path("/cpus");
> -
> -raw_spin_lock_irqsave(&devtree_lock, flags);
> -if (prev)
> -next = prev->sibling;
> -else if (node) {
> -next = node->child;
> -of_node_put(node);
> -}
> -for (; next; next = next->sibling) {
> -if (!(of_node_name_eq(next, "cpu") ||
> - (next->type && !of_node_cmp(next->type, "cpu"
> -continue;
> -if (!__of_device_is_available(next))
> -continue;
> -if (of_node_get(next))
> -break;
> -}
> -of_node_put(prev);
> -raw_spin_unlock_irqrestore(&devtree_lock, flags);
> -return next;
> -}
> -EXPORT_SYMBOL(of_get_next_cpu_node);
> -
> -/**
>* of_get_compatible_child - Find compatible child node
>* @parent:parent node
>* @compatible:compatible string
> diff -rupN a/include/linux/of.h b/include/linux/of.h
> --- a/include/linux/of.h2018-10-30 02:19:32.047096634 +0100
> +++ b/include/linux/of.h2018-10-30 02:18:51.666856715 +0100
> @@ -347,7 +347,6 @@ extern const void *of_get_property(const
> const char *name,
> int *lenp);
> extern struct device_node *of_get_cpu_node(int cpu, unsigned int *thread);
> -extern struct device_node *of_get_next_cpu_node(struct device_node *prev);
>
> #define for_each_property_of_node(dn, pp) \
> for (pp = dn->properties; pp != NULL; pp = pp->next)
> @@ -757,11 +756,6 @@ static inline struct device_node *of_get
> return NULL;
> }
>
> -static inline struct device_node *of_get_next_cpu_node(struct
> device_node *prev)
> -{
> -return NULL;
> -}
> -
> static inline int of_n_addr_cells(struct device_node *np)
> {
> return 0;
> @@ -1239,10 +1233,6 @@ static inline int of_property_read_s32(c
> for (child = of_get_next_available_child(parent, NULL); child !=
> NULL; \
>child = of_get_next_available_child(parent, child))
>
> -#define for_each_of_cpu_node(cpu) \
> -for (cpu = of_get_next_cpu_node(NULL); cpu != NULL; \
> - cpu = of_get_next_cpu_node(cpu))
> -
> #define for_each_node_with_property(dn, prop_name) \
> for (dn = of_find_node_with_property(NULL, prop_name); dn; \
>dn = of_find_node_with_property(dn, prop_name))
[v11 1/7] dmaengine: fsldma: Replace DMA_IN/OUT by FSL_DMA_IN/OUT
From: Wen He
This patch implement a standard macro call functions is
used to NXP dma drivers.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
---
change in v11:
- no
drivers/dma/fsldma.c | 16
drivers/dma/fsldma.h |4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 1117b51..39871e0 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -53,42 +53,42 @@
static void set_sr(struct fsldma_chan *chan, u32 val)
{
- DMA_OUT(chan, &chan->regs->sr, val, 32);
+ FSL_DMA_OUT(chan, &chan->regs->sr, val, 32);
}
static u32 get_sr(struct fsldma_chan *chan)
{
- return DMA_IN(chan, &chan->regs->sr, 32);
+ return FSL_DMA_IN(chan, &chan->regs->sr, 32);
}
static void set_mr(struct fsldma_chan *chan, u32 val)
{
- DMA_OUT(chan, &chan->regs->mr, val, 32);
+ FSL_DMA_OUT(chan, &chan->regs->mr, val, 32);
}
static u32 get_mr(struct fsldma_chan *chan)
{
- return DMA_IN(chan, &chan->regs->mr, 32);
+ return FSL_DMA_IN(chan, &chan->regs->mr, 32);
}
static void set_cdar(struct fsldma_chan *chan, dma_addr_t addr)
{
- DMA_OUT(chan, &chan->regs->cdar, addr | FSL_DMA_SNEN, 64);
+ FSL_DMA_OUT(chan, &chan->regs->cdar, addr | FSL_DMA_SNEN, 64);
}
static dma_addr_t get_cdar(struct fsldma_chan *chan)
{
- return DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
+ return FSL_DMA_IN(chan, &chan->regs->cdar, 64) & ~FSL_DMA_SNEN;
}
static void set_bcr(struct fsldma_chan *chan, u32 val)
{
- DMA_OUT(chan, &chan->regs->bcr, val, 32);
+ FSL_DMA_OUT(chan, &chan->regs->bcr, val, 32);
}
static u32 get_bcr(struct fsldma_chan *chan)
{
- return DMA_IN(chan, &chan->regs->bcr, 32);
+ return FSL_DMA_IN(chan, &chan->regs->bcr, 32);
}
/*
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 4787d48..982845b 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -223,10 +223,10 @@ static void out_le64(u64 __iomem *addr, u64 val)
}
#endif
-#define DMA_IN(fsl_chan, addr, width) \
+#define FSL_DMA_IN(fsl_chan, addr, width) \
(((fsl_chan)->feature & FSL_DMA_BIG_ENDIAN) ? \
in_be##width(addr) : in_le##width(addr))
-#define DMA_OUT(fsl_chan, addr, val, width)\
+#define FSL_DMA_OUT(fsl_chan, addr, val, width)\
(((fsl_chan)->feature & FSL_DMA_BIG_ENDIAN) ? \
out_be##width(addr, val) : out_le##width(addr, val))
--
1.7.1
[v11 2/7] dmaengine: fsldma: Adding macro FSL_DMA_IN/OUT implement for ARM platform
This patch add the macro FSL_DMA_IN/OUT implement for ARM platform.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
---
change in v11:
- no
drivers/dma/fsldma.h | 61 ++---
1 files changed, 42 insertions(+), 19 deletions(-)
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 982845b..88db939 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -196,39 +196,62 @@ struct fsldma_chan {
#define to_fsl_desc(lh) container_of(lh, struct fsl_desc_sw, node)
#define tx_to_fsl_desc(tx) container_of(tx, struct fsl_desc_sw, async_tx)
+#ifdef CONFIG_PPC
+#define fsl_ioread32(p)in_le32(p)
+#define fsl_ioread32be(p) in_be32(p)
+#define fsl_iowrite32(v, p)out_le32(p, v)
+#define fsl_iowrite32be(v, p) out_be32(p, v)
+
#ifndef __powerpc64__
-static u64 in_be64(const u64 __iomem *addr)
+static u64 fsl_ioread64(const u64 __iomem *addr)
{
- return ((u64)in_be32((u32 __iomem *)addr) << 32) |
- (in_be32((u32 __iomem *)addr + 1));
+ u32 fsl_addr = lower_32_bits(addr);
+ u64 fsl_addr_hi = (u64)in_le32((u32 *)(fsl_addr + 1)) << 32;
+
+ return fsl_addr_hi | in_le32((u32 *)fsl_addr);
}
-static void out_be64(u64 __iomem *addr, u64 val)
+static void fsl_iowrite64(u64 val, u64 __iomem *addr)
{
- out_be32((u32 __iomem *)addr, val >> 32);
- out_be32((u32 __iomem *)addr + 1, (u32)val);
+ out_le32((u32 __iomem *)addr + 1, val >> 32);
+ out_le32((u32 __iomem *)addr, (u32)val);
}
-/* There is no asm instructions for 64 bits reverse loads and stores */
-static u64 in_le64(const u64 __iomem *addr)
+static u64 fsl_ioread64be(const u64 __iomem *addr)
{
- return ((u64)in_le32((u32 __iomem *)addr + 1) << 32) |
- (in_le32((u32 __iomem *)addr));
+ u32 fsl_addr = lower_32_bits(addr);
+ u64 fsl_addr_hi = (u64)in_be32((u32 *)fsl_addr) << 32;
+
+ return fsl_addr_hi | in_be32((u32 *)(fsl_addr + 1));
}
-static void out_le64(u64 __iomem *addr, u64 val)
+static void fsl_iowrite64be(u64 val, u64 __iomem *addr)
{
- out_le32((u32 __iomem *)addr + 1, val >> 32);
- out_le32((u32 __iomem *)addr, (u32)val);
+ out_be32((u32 __iomem *)addr, val >> 32);
+ out_be32((u32 __iomem *)addr + 1, (u32)val);
}
#endif
+#endif
-#define FSL_DMA_IN(fsl_chan, addr, width) \
- (((fsl_chan)->feature & FSL_DMA_BIG_ENDIAN) ? \
- in_be##width(addr) : in_le##width(addr))
-#define FSL_DMA_OUT(fsl_chan, addr, val, width)\
- (((fsl_chan)->feature & FSL_DMA_BIG_ENDIAN) ? \
- out_be##width(addr, val) : out_le##width(addr, val))
+#if defined(CONFIG_ARM64) || defined(CONFIG_ARM)
+#define fsl_ioread32(p)ioread32(p)
+#define fsl_ioread32be(p) ioread32be(p)
+#define fsl_iowrite32(v, p)iowrite32(v, p)
+#define fsl_iowrite32be(v, p) iowrite32be(v, p)
+#define fsl_ioread64(p)ioread64(p)
+#define fsl_ioread64be(p) ioread64be(p)
+#define fsl_iowrite64(v, p)iowrite64(v, p)
+#define fsl_iowrite64be(v, p) iowrite64be(v, p)
+#endif
+
+#define FSL_DMA_IN(fsl_dma, addr, width) \
+ (((fsl_dma)->feature & FSL_DMA_BIG_ENDIAN) ?\
+ fsl_ioread##width##be(addr) : fsl_ioread##width(addr))
+
+#define FSL_DMA_OUT(fsl_dma, addr, val, width) \
+ (((fsl_dma)->feature & FSL_DMA_BIG_ENDIAN) ?\
+ fsl_iowrite##width##be(val, addr) : fsl_iowrite \
+ ##width(val, addr))
#define DMA_TO_CPU(fsl_chan, d, width) \
(((fsl_chan)->feature & FSL_DMA_BIG_ENDIAN) ? \
--
1.7.1
[v11 4/7] arm: dts: ls1021a: add qdma device tree nodes
add the qDMA device tree nodes for LS1021A devices.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
---
change in v11:
- no
arch/arm/boot/dts/ls1021a.dtsi | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index f184905..c0ed6be 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -806,5 +806,25 @@
#size-cells = <1>;
ranges = <0x0 0x0 0x1001 0x1>;
};
+
+ qdma: dma-controller@839 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
+ <0x0 0x8389000 0x0 0x1000>, /* Status regs */
+ <0x0 0x838a000 0x0 0x2000>; /* Block regs */
+ interrupts = ,
+,
+;
+ interrupt-names = "qdma-error",
+ "qdma-queue0", "qdma-queue1";
+ dma-channels = <8>;
+ block-number = <1>;
+ block-offset = <0x1000>;
+ fsl,dma-queues = <2>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ };
+
};
};
--
1.7.1
[v11 3/7] dmaengine: fsl-qdma: Add qDMA controller driver for Layerscape SoCs
NXP Queue DMA controller(qDMA) on Layerscape SoCs supports channel virtuallization by allowing DMA jobs to be enqueued into different command queues. Signed-off-by: Wen He Signed-off-by: Jiaheng Fan Signed-off-by: Peng Ma --- change in v11: - remove some useless notes - add driver work on in Kconfig - add previous copyright claims drivers/dma/Kconfig| 14 + drivers/dma/Makefile |1 + drivers/dma/fsl-qdma.c | 1258 3 files changed, 1273 insertions(+), 0 deletions(-) create mode 100644 drivers/dma/fsl-qdma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index dacf3f4..3cdaf84 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -218,6 +218,20 @@ config FSL_EDMA multiplexing capability for DMA request sources(slot). This module can be found on Freescale Vybrid and LS-1 SoCs. +config FSL_QDMA + tristate "NXP Layerscape qDMA engine support" + depends on ARM || ARM64 + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + select DMA_ENGINE_RAID + select ASYNC_TX_ENABLE_CHANNEL_SWITCH + help + Support the NXP Layerscape qDMA engine with command queue and legacy mode. + Channel virtualization is supported through enqueuing of DMA jobs to, + or dequeuing DMA jobs from, different work queues. + This module can be found on NXP Layerscape SoCs. + The qdma driver only work on SoCs with a DPAA hardware block. + config FSL_RAID tristate "Freescale RAID engine Support" depends on FSL_SOC && !ASYNC_TX_ENABLE_CHANNEL_SWITCH diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index c91702d..2d1b586 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -32,6 +32,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o obj-$(CONFIG_FSL_DMA) += fsldma.o obj-$(CONFIG_FSL_EDMA) += fsl-edma.o +obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o obj-$(CONFIG_FSL_RAID) += fsl_raid.o obj-$(CONFIG_HSU_DMA) += hsu/ obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c new file mode 100644 index 000..c18e349 --- /dev/null +++ b/drivers/dma/fsl-qdma.c @@ -0,0 +1,1258 @@ +// SPDX-License-Identifier: GPL-2.0 +// Copyright 2014-2015 Freescale +// Copyright 2018 NXP + +/* + * Driver for NXP Layerscape Queue Direct Memory Access Controller + * + * Author: + * Wen He + * Jiaheng Fan + * + */ + +#include +#include +#include +#include +#include +#include + +#include "virt-dma.h" +#include "fsldma.h" + +/* Register related definition */ +#define FSL_QDMA_DMR 0x0 +#define FSL_QDMA_DSR 0x4 +#define FSL_QDMA_DEIER 0xe00 +#define FSL_QDMA_DEDR 0xe04 +#define FSL_QDMA_DECFDW0R 0xe10 +#define FSL_QDMA_DECFDW1R 0xe14 +#define FSL_QDMA_DECFDW2R 0xe18 +#define FSL_QDMA_DECFDW3R 0xe1c +#define FSL_QDMA_DECFQIDR 0xe30 +#define FSL_QDMA_DECBR 0xe34 + +#define FSL_QDMA_BCQMR(x) (0xc0 + 0x100 * (x)) +#define FSL_QDMA_BCQSR(x) (0xc4 + 0x100 * (x)) +#define FSL_QDMA_BCQEDPA_SADDR(x) (0xc8 + 0x100 * (x)) +#define FSL_QDMA_BCQDPA_SADDR(x) (0xcc + 0x100 * (x)) +#define FSL_QDMA_BCQEEPA_SADDR(x) (0xd0 + 0x100 * (x)) +#define FSL_QDMA_BCQEPA_SADDR(x) (0xd4 + 0x100 * (x)) +#define FSL_QDMA_BCQIER(x) (0xe0 + 0x100 * (x)) +#define FSL_QDMA_BCQIDR(x) (0xe4 + 0x100 * (x)) + +#define FSL_QDMA_SQDPAR0x80c +#define FSL_QDMA_SQEPAR0x814 +#define FSL_QDMA_BSQMR 0x800 +#define FSL_QDMA_BSQSR 0x804 +#define FSL_QDMA_BSQICR0x828 +#define FSL_QDMA_CQMR 0xa00 +#define FSL_QDMA_CQDSCR1 0xa08 +#define FSL_QDMA_CQDSCR20xa0c +#define FSL_QDMA_CQIER 0xa10 +#define FSL_QDMA_CQEDR 0xa14 +#define FSL_QDMA_SQCCMR0xa20 + +/* Registers for bit and genmask */ +#define FSL_QDMA_CQIDR_SQT BIT(15) +#define QDMA_CCDF_FOTMAT BIT(29) +#define QDMA_CCDF_SER BIT(30) +#define QDMA_SG_FINBIT(30) +#define QDMA_SG_LEN_MASK GENMASK(29, 0) +#define QDMA_CCDF_MASK GENMASK(28, 20) + +#define FSL_QDMA_DEDR_CLEARGENMASK(31, 0) +#define FSL_QDMA_BCQIDR_CLEAR GENMASK(31, 0) +#define FSL_QDMA_DEIER_CLEAR GENMASK(31, 0) + +#define FSL_QDMA_BCQIER_CQTIE BIT(15) +#define FSL_QDMA_BCQIER_CQPEIE BIT(23) +#define FSL_QDMA_BSQICR_ICEN BIT(31) + +#define FSL_QDMA_BSQICR_ICST(x)((x) << 16) +#define FSL_QDMA_CQIER_MEIEBIT(31) +#define FSL_QDMA_CQIER_TEIEBIT(0) +#define FSL_QDMA_SQCCMR_ENTER_WM
[v11 5/7] arm64: dts: ls1043a: add qdma device tree nodes
add the qDMA device tree nodes for LS1043A devices.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
---
change in v11:
- no
arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 7881e3d..d560141 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -734,6 +734,28 @@
< 0 0 3 &gic 0 156 0x4>,
< 0 0 4 &gic 0 157 0x4>;
};
+
+ qdma: dma-controller@838 {
+ compatible = "fsl,ls1021a-qdma", "fsl,ls1043a-qdma";
+ reg = <0x0 0x838 0x0 0x1000>, /* Controller regs */
+ <0x0 0x839 0x0 0x1>, /* Status regs */
+ <0x0 0x83a 0x0 0x4>; /* Block regs */
+ interrupts = <0 153 0x4>,
+<0 39 0x4>,
+<0 40 0x4>,
+<0 41 0x4>,
+<0 42 0x4>;
+ interrupt-names = "qdma-error", "qdma-queue0",
+ "qdma-queue1", "qdma-queue2", "qdma-queue3";
+ dma-channels = <8>;
+ block-number = <1>;
+ block-offset = <0x1>;
+ fsl,dma-queues = <2>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ };
+
};
firmware {
--
1.7.1
[v11 6/7] arm64: dts: ls1046a: add qdma device tree nodes
add the qDMA device tree nodes for LS1046A devices.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
---
change in v11:
- no
arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index ef83786..dc65318 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -704,6 +704,27 @@
< 0 0 4 &gic GIC_SPI 154
IRQ_TYPE_LEVEL_HIGH>;
};
+ qdma: dma-controller@838 {
+ compatible = "fsl,ls1046a-qdma", "fsl,ls1021a-qdma";
+ reg = <0x0 0x838 0x0 0x1000>, /* Controller regs */
+ <0x0 0x839 0x0 0x1>, /* Status regs */
+ <0x0 0x83a 0x0 0x4>; /* Block regs */
+ interrupts = <0 153 0x4>,
+<0 39 0x4>,
+<0 40 0x4>,
+<0 41 0x4>,
+<0 42 0x4>;
+ interrupt-names = "qdma-error", "qdma-queue0",
+ "qdma-queue1", "qdma-queue2", "qdma-queue3";
+ dma-channels = <8>;
+ block-number = <1>;
+ block-offset = <0x1>;
+ fsl,dma-queues = <2>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ };
+
};
reserved-memory {
--
1.7.1
[v11 7/7] dt-bindings: fsl-qdma: Add NXP Layerscpae qDMA controller bindings
Document the devicetree bindings for NXP Layerscape qDMA controller
which could be found on NXP QorIQ Layerscape SoCs.
Signed-off-by: Wen He
Signed-off-by: Peng Ma
Reviewed-by: Rob Herring
---
change in v11:
- no
Documentation/devicetree/bindings/dma/fsl-qdma.txt | 57
1 files changed, 57 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
new file mode 100644
index 000..6a0ff90
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
@@ -0,0 +1,57 @@
+NXP Layerscape SoC qDMA Controller
+==
+
+This device follows the generic DMA bindings defined in dma/dma.txt.
+
+Required properties:
+
+- compatible: Must be one of
+"fsl,ls1021a-qdma": for LS1021A Board
+"fsl,ls1043a-qdma": for ls1043A Board
+"fsl,ls1046a-qdma": for ls1046A Board
+- reg: Should contain the register's base address and length.
+- interrupts: Should contain a reference to the interrupt used by this
+ device.
+- interrupt-names: Should contain interrupt names:
+"qdma-queue0": the block0 interrupt
+"qdma-queue1": the block1 interrupt
+"qdma-queue2": the block2 interrupt
+"qdma-queue3": the block3 interrupt
+"qdma-error": the error interrupt
+- fsl,dma-queues: Should contain number of queues supported.
+- dma-channels:Number of DMA channels supported
+- block-number:the virtual block number
+- block-offset:the offset of different virtual block
+- status-sizes:status queue size of per virtual block
+- queue-sizes: command queue size of per virtual block, the size number
+ based on queues
+
+Optional properties:
+
+- dma-channels:Number of DMA channels supported by the
controller.
+- big-endian: If present registers and hardware scatter/gather
descriptors
+ of the qDMA are implemented in big endian mode,
otherwise in little
+ mode.
+
+Examples:
+
+ qdma: dma-controller@839 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8388000 0x0 0x1000>, /* Controller regs */
+ <0x0 0x8389000 0x0 0x1000>, /* Status regs */
+ <0x0 0x838a000 0x0 0x2000>; /* Block regs */
+ interrupts = ,
+,
+;
+ interrupt-names = "qdma-error",
+ "qdma-queue0", "qdma-queue1";
+ dma-channels = <8>;
+ block-number = <2>;
+ block-offset = <0x1000>;
+ fsl,dma-queues = <2>;
+ status-sizes = <64>;
+ queue-sizes = <64 64>;
+ big-endian;
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
1.7.1
RE: [PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
-Original Message-
From: Poonam Aggrwal
Sent: 2018年10月29日 19:09
To: Vabhav Sharma ; sudeep.ho...@arm.com;
o...@buserror.net; linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
robh...@kernel.org; mark.rutl...@arm.com; linuxppc-dev@lists.ozlabs.org;
linux-arm-ker...@lists.infradead.org; mturque...@baylibre.com;
sb...@kernel.org; r...@rjwysocki.net; viresh.ku...@linaro.org;
linux-...@vger.kernel.org; linux...@vger.kernel.org;
linux-kernel-ow...@vger.kernel.org; catalin.mari...@arm.com;
will.dea...@arm.com; gre...@linuxfoundation.org; a...@arndb.de;
kstew...@linuxfoundation.org; yamada.masah...@socionext.com; Leo Li
; shawn...@kernel.org
Cc: ulf.hans...@linaro.org; Udit Kumar ; Pankaj Bansal
; li...@armlinux.org.uk; adrian.hun...@intel.com; Varun
Sethi ; Vabhav Sharma ; Yinbo Zhu
Subject: RE: [PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
> -Original Message-
> From: linux-arm-kernel
> [mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Vabhav Sharma
> Sent: Monday, October 29, 2018 2:28 PM
> To: sudeep.ho...@arm.com; o...@buserror.net;
> linux-ker...@vger.kernel.org; devicet...@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com;
> linuxppc-dev@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org;
> mturque...@baylibre.com; sb...@kernel.org; r...@rjwysocki.net;
> viresh.ku...@linaro.org; linux-...@vger.kernel.org;
> linux...@vger.kernel.org; linux-kernel-ow...@vger.kernel.org;
> catalin.mari...@arm.com; will.dea...@arm.com;
> gre...@linuxfoundation.org; a...@arndb.de;
> kstew...@linuxfoundation.org; yamada.masah...@socionext.com; Leo Li
> ; shawn...@kernel.org
> Cc: ulf.hans...@linaro.org; Udit Kumar ; Pankaj
> Bansal ; li...@armlinux.org.uk;
> adrian.hun...@intel.com; Varun Sethi ; Vabhav Sharma
> ; Yinbo Zhu
> Subject: [PATCH v7 2/6] soc/fsl/guts: Add definition for LX2160A
>
> Adding compatible string "lx2160a-dcfg" to initialize guts driver for
> lx2160 and SoC die attribute definition for LX2160A
>
> Signed-off-by: Vabhav Sharma
> Signed-off-by: Yinbo Zhu
> Acked-by: Li Yang
> ---
> drivers/soc/fsl/guts.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c index
> 302e0c8..bcab1ee 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -100,6 +100,11 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
> .svr = 0x8700,
> .mask = 0xfff7,
> },
> + /* Die: LX2160A, SoC: LX2160A/LX2120A/LX2080A */
> + { .die = "LX2160A",
> + .svr = 0x8736,
>Do all the threevariants " LX2160A/LX2120A/LX2080A" have same SVR?
Dear Poonam Aggrwal,
No, but the threevariants " LX2160A/LX2120A/LX2080A" has same svr value in this
struct,
Because they all are variants of lx2160, the svr value in this struct is equal
the soc svr && mask
Best Regards,
Yinbo Zhu.
> + .mask = 0xff3f,
> + },
> { },
> };
>
> @@ -222,6 +227,7 @@ static const struct of_device_id fsl_guts_of_match[] = {
> { .compatible = "fsl,ls1088a-dcfg", },
> { .compatible = "fsl,ls1012a-dcfg", },
> { .compatible = "fsl,ls1046a-dcfg", },
> + { .compatible = "fsl,lx2160a-dcfg", },
> {}
> };
> MODULE_DEVICE_TABLE(of, fsl_guts_of_match);
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> s.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=02%7C01%7Cpoonam.aggrwal%40nxp.com%7Cd9b7c36c786
> 54cd6dc4008d63d7fee63%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636764017001504288&sdata=pqFMlw6yVrHrvn4YRhqj%2FmoOnSscrZu
> tcoYn3In8OJc%3D&reserved=0
[PATCH 1/2] kbuild: replace cc-name test with CONFIG_CC_IS_CLANG
Evaluating cc-name invokes the compiler every time even when you are not compiling anything, like 'make help'. This is not efficient. The compiler type has been already detected in the Kconfig stage. Use CONFIG_CC_IS_CLANG, instead. Signed-off-by: Masahiro Yamada --- Makefile | 2 +- arch/mips/Makefile | 2 +- arch/mips/vdso/Makefile| 2 +- arch/powerpc/Makefile | 4 ++-- scripts/Makefile.extrawarn | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 0a42d06..bd93bc3 100644 --- a/Makefile +++ b/Makefile @@ -707,7 +707,7 @@ stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong KBUILD_CFLAGS += $(stackp-flags-y) -ifeq ($(cc-name),clang) +ifeq ($(CONFIG_CC_IS_CLANG),y) KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) KBUILD_CFLAGS += $(call cc-disable-warning, gnu) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 15a84cf..ad1c418 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -128,7 +128,7 @@ cflags-y += -ffreestanding # clang's output will be based upon the build machine. So for clang we simply # unconditionally specify -EB or -EL as appropriate. # -ifeq ($(cc-name),clang) +ifeq ($(CONFIG_CC_IS_CLANG),y) cflags-$(CONFIG_CPU_BIG_ENDIAN)+= -EB cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -EL else diff --git a/arch/mips/vdso/Makefile b/arch/mips/vdso/Makefile index 34605ca..e2b055e 100644 --- a/arch/mips/vdso/Makefile +++ b/arch/mips/vdso/Makefile @@ -10,7 +10,7 @@ ccflags-vdso := \ $(filter -march=%,$(KBUILD_CFLAGS)) \ -D__VDSO__ -ifeq ($(cc-name),clang) +ifeq ($(CONFIG_CC_IS_CLANG),y) ccflags-vdso += $(filter --target=%,$(KBUILD_CFLAGS)) endif diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 17be664..338e827 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -96,7 +96,7 @@ aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1) aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2 endif -ifneq ($(cc-name),clang) +ifneq ($(CONFIG_CC_IS_CLANG),y) cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align endif @@ -175,7 +175,7 @@ endif # Work around gcc code-gen bugs with -pg / -fno-omit-frame-pointer in gcc <= 4.8 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52828 -ifneq ($(cc-name),clang) +ifneq ($(CONFIG_CC_IS_CLANG),y) CC_FLAGS_FTRACE+= $(call cc-ifversion, -lt, 0409, -mno-sched-epilog) endif endif diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 24b2fb1..88129e5 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -64,7 +64,7 @@ endif KBUILD_CFLAGS += $(warning) else -ifeq ($(cc-name),clang) +ifeq ($(CONFIG_CC_IS_CLANG),y) KBUILD_CFLAGS += $(call cc-disable-warning, initializer-overrides) KBUILD_CFLAGS += $(call cc-disable-warning, unused-value) KBUILD_CFLAGS += $(call cc-disable-warning, format) -- 2.7.4
Re: [RFC PATCH v1 3/4] kvmppc: H_SVM_INIT_START and H_SVM_INIT_DONE hcalls
On Mon, Oct 22, 2018 at 10:48:36AM +0530, Bharata B Rao wrote:
> H_SVM_INIT_START: Initiate securing a VM
> H_SVM_INIT_DONE: Conclude securing a VM
>
> During early guest init, these hcalls will be issued by UV.
> As part of these hcalls, [un]register memslots with UV.
>
> Signed-off-by: Bharata B Rao
Comments below...
> ---
> arch/powerpc/include/asm/hvcall.h| 4 ++-
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/include/asm/ucall-api.h | 6
> arch/powerpc/kvm/book3s_hv.c | 54
> 4 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/hvcall.h
> b/arch/powerpc/include/asm/hvcall.h
> index 89e6b70c1857..6091276fef07 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -300,7 +300,9 @@
> #define H_INT_RESET 0x3D0
> #define H_SVM_PAGE_IN0x3D4
> #define H_SVM_PAGE_OUT 0x3D8
> -#define MAX_HCALL_OPCODE H_SVM_PAGE_OUT
> +#define H_SVM_INIT_START 0x3DC
> +#define H_SVM_INIT_DONE 0x3E0
> +#define MAX_HCALL_OPCODE H_SVM_INIT_DONE
Same comments about hcall number assignments as for patch 1.
> /* H_VIOCTL functions */
> #define H_GET_VIOA_DUMP_SIZE 0x01
> diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> index 194e6e0ff239..267f8c568bc3 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -292,6 +292,7 @@ struct kvm_arch {
> struct dentry *debugfs_dir;
> struct dentry *htab_dentry;
> struct kvm_resize_hpt *resize_hpt; /* protected by kvm->lock */
> + bool svm_init_start; /* Indicates H_SVM_INIT_START has been called */
That doesn't seem like a good name for the field. How about just
'secure'?
> #endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
> struct mutex hpt_mutex;
> diff --git a/arch/powerpc/include/asm/ucall-api.h
> b/arch/powerpc/include/asm/ucall-api.h
> index 2c12f514f8ab..9ddfcf541211 100644
> --- a/arch/powerpc/include/asm/ucall-api.h
> +++ b/arch/powerpc/include/asm/ucall-api.h
> @@ -17,4 +17,10 @@ static inline int uv_page_out(u64 lpid, u64 dw0, u64 dw1,
> u64 dw2, u64 dw3)
> return U_SUCCESS;
> }
>
> +static inline int uv_register_mem_slot(u64 lpid, u64 dw0, u64 dw1, u64 dw2,
> +u64 dw3)
> +{
> + return 0;
> +}
Please give the parameters descriptive names.
> +
> #endif /* _ASM_POWERPC_UCALL_API_H */
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 05084eb8aadd..47f366f634fd 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -819,6 +819,50 @@ static int kvmppc_get_yield_count(struct kvm_vcpu *vcpu)
> return yield_count;
> }
>
> +#ifdef CONFIG_PPC_SVM
> +#include
> +/*
> + * TODO: Check if memslots related calls here need to be called
> + * under any lock.
> + */
> +static unsigned long kvmppc_h_svm_init_start(struct kvm *kvm)
> +{
> + struct kvm_memslots *slots;
> + struct kvm_memory_slot *memslot;
> + int ret;
> +
> + slots = kvm_memslots(kvm);
I think you need the srcu read lock around this stuff.
> + kvm_for_each_memslot(memslot, slots) {
> + ret = uv_register_mem_slot(kvm->arch.lpid,
> +memslot->base_gfn << PAGE_SHIFT,
> +memslot->npages * PAGE_SIZE,
> +0, memslot->id);
> + if (ret < 0)
> + return H_PARAMETER;
That doesn't seem like the right error code to use...
> + }
> + kvm->arch.svm_init_start = true;
> + return H_SUCCESS;
> +}
> +
> +static unsigned long kvmppc_h_svm_init_done(struct kvm *kvm)
> +{
> + if (kvm->arch.svm_init_start)
> + return H_SUCCESS;
> + else
> + return H_UNSUPPORTED;
> +}
> +#else
> +static unsigned long kvmppc_h_svm_init_start(struct kvm *kvm)
> +{
> + return H_UNSUPPORTED;
> +}
> +
> +static unsigned long kvmppc_h_svm_init_done(struct kvm *kvm)
> +{
> + return H_UNSUPPORTED;
> +}
> +#endif
> +
> int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
> {
> unsigned long req = kvmppc_get_gpr(vcpu, 3);
> @@ -950,6 +994,12 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
> kvmppc_get_gpr(vcpu, 6),
> kvmppc_get_gpr(vcpu, 7));
> break;
> + case H_SVM_INIT_START:
> + ret = kvmppc_h_svm_init_start(vcpu->kvm);
> + break;
> + case H_SVM_INIT_DONE:
> + ret = kvmppc_h_svm_init_done(vcpu->kvm);
> + break;
> default:
> return RESUME_HOST;
> }
> @@ -978,6 +1028,8 @@ static int kvmppc_hcall_impl_hv(unsigned long cmd)
> #endif
> case H_SVM_PAGE_IN:
>
Re: [RFC PATCH v1 2/4] kvmppc: Add support for shared pages in HMM driver
On Mon, Oct 22, 2018 at 10:48:35AM +0530, Bharata B Rao wrote:
> A secure guest will share some of its pages with hypervisor (Eg. virtio
> bounce buffers etc). Support shared pages in HMM driver.
>
> Signed-off-by: Bharata B Rao
Comments below...
> ---
> arch/powerpc/kvm/book3s_hv_hmm.c | 69 ++--
> 1 file changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_hmm.c
> b/arch/powerpc/kvm/book3s_hv_hmm.c
> index a2ee3163a312..09b8e19b7605 100644
> --- a/arch/powerpc/kvm/book3s_hv_hmm.c
> +++ b/arch/powerpc/kvm/book3s_hv_hmm.c
> @@ -50,6 +50,7 @@ struct kvmppc_hmm_page_pvt {
> struct hlist_head *hmm_hash;
> unsigned int lpid;
> unsigned long gpa;
> + bool skip_page_out;
> };
>
> struct kvmppc_hmm_migrate_args {
> @@ -278,6 +279,65 @@ static unsigned long kvmppc_gpa_to_hva(struct kvm *kvm,
> unsigned long gpa,
> return hva;
> }
>
> +/*
> + * Shares the page with HV, thus making it a normal page.
> + *
> + * - If the page is already secure, then provision a new page and share
> + * - If the page is a normal page, share the existing page
> + *
> + * In the former case, uses the HMM fault handler to release the HMM page.
> + */
> +static unsigned long
> +kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
> + unsigned long addr, unsigned long page_shift)
> +{
> +
> + int ret;
> + struct hlist_head *list, *hmm_hash;
> + unsigned int lpid = kvm->arch.lpid;
> + unsigned long flags;
> + struct kvmppc_hmm_pfn_entry *p;
> + struct page *hmm_page, *page;
> + struct kvmppc_hmm_page_pvt *pvt;
> + unsigned long pfn;
> +
> + /*
> + * First check if the requested page has already been given to
> + * UV as a secure page. If so, ensure that we don't issue a
> + * UV_PAGE_OUT but instead directly send the page
> + */
> + spin_lock_irqsave(&kvmppc_hmm_lock, flags);
> + hmm_hash = kvm->arch.hmm_hash;
> + list = &hmm_hash[kvmppc_hmm_pfn_hash_fn(gpa)];
> + hlist_for_each_entry(p, list, hlist) {
> + if (p->addr == gpa) {
> + hmm_page = pfn_to_page(p->hmm_pfn);
> + get_page(hmm_page); /* TODO: Necessary ? */
> + pvt = (struct kvmppc_hmm_page_pvt *)
> + hmm_devmem_page_get_drvdata(hmm_page);
> + pvt->skip_page_out = true;
> + put_page(hmm_page);
> + break;
> + }
> + }
> + spin_unlock_irqrestore(&kvmppc_hmm_lock, flags);
> +
> + ret = get_user_pages_fast(addr, 1, 0, &page);
Why are we calling this with write==0? Surely in general the secure
guest will expect to be able to write to the shared page?
Also, in general get_user_pages_fast isn't sufficient to translate a
host virtual address (derived from a guest real address) into a pfn.
See for example hva_to_pfn() in virt/kvm/kvm_main.c and the things it
does to cope with the various cases that one can hit. I can imagine
in future that the secure guest might want to establish a shared
mapping to a PCI device, for instance.
> + if (ret != 1)
> + return H_PARAMETER;
> +
> + pfn = page_to_pfn(page);
> + if (is_zero_pfn(pfn)) {
> + put_page(page);
> + return H_SUCCESS;
> + }
The ultravisor still needs a page to map into the guest in this case,
doesn't it? What's the point of returning without giving the
ultravisor a page to use?
> +
> + ret = uv_page_in(lpid, pfn << page_shift, gpa, 0, page_shift);
> + put_page(page);
> +
> + return (ret == U_SUCCESS) ? H_SUCCESS : H_PARAMETER;
> +}
> +
> /*
> * Move page from normal memory to secure memory.
> */
> @@ -300,8 +360,8 @@ kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
> return H_PARAMETER;
> end = addr + (1UL << page_shift);
>
> - if (flags)
> - return H_P2;
> + if (flags & H_PAGE_IN_SHARED)
> + return kvmppc_share_page(kvm, gpa, addr, page_shift);
Would be best to fail if any unknown flags are set, I would think.
>
> args.hmm_hash = kvm->arch.hmm_hash;
> args.lpid = kvm->arch.lpid;
> @@ -349,8 +409,9 @@ kvmppc_hmm_fault_migrate_alloc_and_copy(struct
> vm_area_struct *vma,
> hmm_devmem_page_get_drvdata(spage);
>
> pfn = page_to_pfn(dpage);
> - ret = uv_page_out(pvt->lpid, pfn << PAGE_SHIFT,
> - pvt->gpa, 0, PAGE_SHIFT);
> + if (!pvt->skip_page_out)
> + ret = uv_page_out(pvt->lpid, pfn << PAGE_SHIFT,
> + pvt->gpa, 0, PAGE_SHIFT);
> if (ret == U_SUCCESS)
> *dst_pfn = migrate_pfn(pfn) | MIGRATE_PFN_LOCKED;
> }
> --
> 2.17.1
Paul.
Re: [RFC PATCH v1 1/4] kvmppc: HMM backend driver to manage pages of secure guest
On Mon, Oct 22, 2018 at 10:48:34AM +0530, Bharata B Rao wrote:
> HMM driver for KVM PPC to manage page transitions of
> secure guest via H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls.
>
> H_SVM_PAGE_IN: Move the content of a normal page to secure page
> H_SVM_PAGE_OUT: Move the content of a secure page to normal page
Comments below...
> Signed-off-by: Bharata B Rao
> ---
> arch/powerpc/include/asm/hvcall.h| 7 +-
> arch/powerpc/include/asm/kvm_host.h | 15 +
> arch/powerpc/include/asm/kvm_ppc.h | 28 ++
> arch/powerpc/include/asm/ucall-api.h | 20 ++
> arch/powerpc/kvm/Makefile| 3 +
> arch/powerpc/kvm/book3s_hv.c | 38 ++
> arch/powerpc/kvm/book3s_hv_hmm.c | 514 +++
> 7 files changed, 624 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/include/asm/ucall-api.h
> create mode 100644 arch/powerpc/kvm/book3s_hv_hmm.c
>
> diff --git a/arch/powerpc/include/asm/hvcall.h
> b/arch/powerpc/include/asm/hvcall.h
> index a0b17f9f1ea4..89e6b70c1857 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -158,6 +158,9 @@
> /* Each control block has to be on a 4K boundary */
> #define H_CB_ALIGNMENT 4096
>
> +/* Flags for H_SVM_PAGE_IN */
> +#define H_PAGE_IN_SHARED 0x1
> +
> /* pSeries hypervisor opcodes */
> #define H_REMOVE 0x04
> #define H_ENTER 0x08
> @@ -295,7 +298,9 @@
> #define H_INT_ESB 0x3C8
> #define H_INT_SYNC 0x3CC
> #define H_INT_RESET 0x3D0
> -#define MAX_HCALL_OPCODE H_INT_RESET
> +#define H_SVM_PAGE_IN0x3D4
> +#define H_SVM_PAGE_OUT 0x3D8
> +#define MAX_HCALL_OPCODE H_SVM_PAGE_OUT
We should define hcall numbers in the implementation-specific range.
We can't use numbers in this range without first getting them
standardized in PAPR. Since these hcalls are not actually used by
the guest but are just a private interface between KVM and the
ultravisor, it's probably not worth putting them in PAPR. We should
pick a range somewhere in the 0xf000 - 0xfffc area and use that.
> /* H_VIOCTL functions */
> #define H_GET_VIOA_DUMP_SIZE 0x01
> diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> index 906bcbdfd2a1..194e6e0ff239 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -310,6 +310,9 @@ struct kvm_arch {
> struct kvmppc_passthru_irqmap *pimap;
> #endif
> struct kvmppc_ops *kvm_ops;
> +#ifdef CONFIG_PPC_SVM
> + struct hlist_head *hmm_hash;
> +#endif
I'd suggest not having the #ifdef here, given it's only 8 bytes and
the type (struct hlist_head) doesn't depend on CONFIG_PPC_SVM.
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> /* This array can grow quite large, keep it at the end */
> struct kvmppc_vcore *vcores[KVM_MAX_VCORES];
> @@ -830,4 +833,16 @@ static inline void kvm_arch_vcpu_blocking(struct
> kvm_vcpu *vcpu) {}
> static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> +#ifdef CONFIG_PPC_SVM
> +struct kvmppc_hmm_device {
> + struct hmm_device *device;
> + struct hmm_devmem *devmem;
> + unsigned long *pfn_bitmap;
> +};
> +
> +extern int kvmppc_hmm_init(void);
> +extern void kvmppc_hmm_free(void);
> +extern int kvmppc_hmm_hash_create(struct kvm *kvm);
> +extern void kvmppc_hmm_hash_destroy(struct kvm *kvm);
> +#endif
> #endif /* __POWERPC_KVM_HOST_H__ */
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index e991821dd7fa..ba81a07e2bdf 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -906,4 +906,32 @@ static inline ulong kvmppc_get_ea_indexed(struct
> kvm_vcpu *vcpu, int ra, int rb)
>
> extern void xics_wake_cpu(int cpu);
>
> +#ifdef CONFIG_PPC_SVM
> +extern unsigned long kvmppc_h_svm_page_in(struct kvm *kvm,
> + unsigned int lpid,
> + unsigned long gra,
> + unsigned long flags,
> + unsigned long page_shift);
> +extern unsigned long kvmppc_h_svm_page_out(struct kvm *kvm,
> + unsigned int lpid,
> + unsigned long gra,
> + unsigned long flags,
> + unsigned long page_shift);
> +#else
> +static inline unsigned long
> +kvmppc_h_svm_page_in(struct kvm *kvm, unsigned int lpid,
> + unsigned long gra, unsigned long flags,
> + unsigned long page_shift)
> +{
> + return H_UNSUPPORTED;
> +}
> +
> +static inline unsigned long
> +kvmppc_h_svm_page_out(struct kvm *kvm, unsigned int lpid,
> + unsigned
Re: [RFC PATCH v1 1/4] kvmppc: HMM backend driver to manage pages of secure guest
On Tue, Oct 30, 2018 at 04:03:00PM +1100, Paul Mackerras wrote: > On Mon, Oct 22, 2018 at 10:48:34AM +0530, Bharata B Rao wrote: > > HMM driver for KVM PPC to manage page transitions of > > secure guest via H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls. > > > > H_SVM_PAGE_IN: Move the content of a normal page to secure page > > H_SVM_PAGE_OUT: Move the content of a secure page to normal page > > Comments below... > > > Signed-off-by: Bharata B Rao > > --- > > /* pSeries hypervisor opcodes */ > > #define H_REMOVE 0x04 > > #define H_ENTER0x08 > > @@ -295,7 +298,9 @@ > > #define H_INT_ESB 0x3C8 > > #define H_INT_SYNC 0x3CC > > #define H_INT_RESET 0x3D0 > > -#define MAX_HCALL_OPCODE H_INT_RESET > > +#define H_SVM_PAGE_IN 0x3D4 > > +#define H_SVM_PAGE_OUT 0x3D8 > > +#define MAX_HCALL_OPCODE H_SVM_PAGE_OUT > > We should define hcall numbers in the implementation-specific range. > We can't use numbers in this range without first getting them > standardized in PAPR. Since these hcalls are not actually used by > the guest but are just a private interface between KVM and the > ultravisor, it's probably not worth putting them in PAPR. We should > pick a range somewhere in the 0xf000 - 0xfffc area and use that. We are using that range for Ucalls. For hcalls we were told to reserve a range between 1024(0x400) to 2047(0x7FF). Have to reserve them in the appropriate database. RP
Re: [RFC PATCH v1 1/4] kvmppc: HMM backend driver to manage pages of secure guest
On Mon, Oct 29, 2018 at 11:31:55PM -0700, Ram Pai wrote: > On Tue, Oct 30, 2018 at 04:03:00PM +1100, Paul Mackerras wrote: > > On Mon, Oct 22, 2018 at 10:48:34AM +0530, Bharata B Rao wrote: > > > HMM driver for KVM PPC to manage page transitions of > > > secure guest via H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls. > > > > > > H_SVM_PAGE_IN: Move the content of a normal page to secure page > > > H_SVM_PAGE_OUT: Move the content of a secure page to normal page > > > > Comments below... > > > > > Signed-off-by: Bharata B Rao > > > --- > > > /* pSeries hypervisor opcodes */ > > > > #define H_REMOVE 0x04 > > > #define H_ENTER 0x08 > > > @@ -295,7 +298,9 @@ > > > #define H_INT_ESB 0x3C8 > > > #define H_INT_SYNC 0x3CC > > > #define H_INT_RESET 0x3D0 > > > -#define MAX_HCALL_OPCODE H_INT_RESET > > > +#define H_SVM_PAGE_IN0x3D4 > > > +#define H_SVM_PAGE_OUT 0x3D8 > > > +#define MAX_HCALL_OPCODE H_SVM_PAGE_OUT > > > > We should define hcall numbers in the implementation-specific range. > > We can't use numbers in this range without first getting them > > standardized in PAPR. Since these hcalls are not actually used by > > the guest but are just a private interface between KVM and the > > ultravisor, it's probably not worth putting them in PAPR. We should > > pick a range somewhere in the 0xf000 - 0xfffc area and use that. > > We are using that range for Ucalls. For hcalls we were told to reserve > a range between 1024(0x400) to 2047(0x7FF). Have to reserve them in the > appropriate database. Who gave you that advice? Paul.
[mainline][bisected 55469b][ppc] build error at drivers/net/ethernet/mellanox/mlx4/en_rx.c
Greeting's mainline build fails on my powerpc with commit 55469b : drivers: net: remove inclusion when not needed Machine type: PowerPC power 8 bare-metal kernel : 4.19.0 gcc : 4.8.5 config attached build errors: drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: ‘struct iphdr’ declared inside parameter list [enabled by default] struct iphdr *iph) ^ drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] drivers/net/ethernet/mellanox/mlx4/en_rx.c: In function ‘get_fixed_ipv4_csum’: drivers/net/ethernet/mellanox/mlx4/en_rx.c:586:20: error: dereferencing pointer to incomplete type __u8 ipproto = iph->protocol; ^ Kernel builds fine when the patch is reverted. -- Regard's Abdul Haleem IBM Linux Technology Centre # # Automatically generated file; DO NOT EDIT. # Linux/powerpc 4.13.0-rc2 Kernel Configuration # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S_64=y # CONFIG_PPC_BOOK3E_64 is not set # CONFIG_POWER7_CPU is not set CONFIG_POWER8_CPU=y CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y # CONFIG_PPC_ICSWX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_RADIX_MMU=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_PPC_MM_SLICES=y CONFIG_PPC_HAVE_PMU_SUPPORT=y CONFIG_PPC_PERF_CTRS=y CONFIG_FORCE_SMP=y CONFIG_SMP=y CONFIG_NR_CPUS=2048 CONFIG_PPC_DOORBELL=y # CONFIG_CPU_BIG_ENDIAN is not set CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_PPC64_BOOT_WRAPPER=y CONFIG_64BIT=y CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_ARCH_DMA_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_ARCH_MMAP_RND_BITS_MAX=29 CONFIG_ARCH_MMAP_RND_BITS_MIN=14 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=13 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=7 CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NR_IRQS=512 CONFIG_NMI_IPI=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_HAS_DMA_SET_COHERENT_MASK=y CONFIG_PPC=y # CONFIG_GENERIC_CSUM is not set CONFIG_EARLY_PRINTK=y CONFIG_PANIC_TIMEOUT=180 CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_EPAPR_BOOT=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_PPC_EMULATE_SSTEP=y CONFIG_ZONE_DMA32=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_XZ is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_SHOW_LEVEL=y CONFIG_GENERIC_IRQ_MIGRATION=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_VIRT_CPU_ACCOUNTING_NATIVE=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TREE_SRCU=y CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_RCU_NOCB_CPU=y CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LOG_CPU_MAX_BUF_SHIFT=13 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_NUMA_BALANCING=y CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y CONFIG_CGROUPS=y CONFIG_PAGE
