* Re: [PATCH 6/9] PCI: hotplug: Constify hotplug_slot_ops
From: Tyrel Datwyler @ 2018-08-21 0:38 UTC (permalink / raw)
To: Lukas Wunner, Bjorn Helgaas, linux-pci, Sinan Kaya,
Mika Westerberg
Cc: Scott Murray, linux-s390, Greg Kroah-Hartman, acpi4asus-user,
Rafael J. Wysocki, Gavin Shan, platform-driver-x86, linux-acpi,
Paul Mackerras, Sebastian Ott, Corentin Chary, Darren Hart,
linuxppc-dev, Andy Shevchenko, Gerald Schaefer, Len Brown
In-Reply-To: <40b17d029c4fbf099535f989b1d6dd013f708a73.1534686485.git.lukas@wunner.de>
On 08/19/2018 07:29 AM, Lukas Wunner wrote:
> Hotplug drivers cannot declare their hotplug_slot_ops const, making them
> attractive targets for attackers, because upon registration of a hotplug
> slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members
> in that struct.
>
> Fix by moving these members to struct hotplug_slot and constify every
> driver's hotplug_slot_ops except for pciehp.
>
> pciehp constructs its hotplug_slot_ops at runtime based on the PCIe
> port's capabilities, hence cannot declare them const. It can be
> converted to __write_rarely once that's mainlined:
> http://www.openwall.com/lists/kernel-hardening/2016/11/16/3
>
> Signed-off-by: Lukas Wunner <lukas@wunner.de>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Scott Murray <scott@spiteful.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
> Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
> Cc: Corentin Chary <corentin.chary@gmail.com>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Andy Shevchenko <andy@infradead.org>
> ---
With regards to drivers/pci/hotplug/rpa*
Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
^ permalink raw reply
* [PATCH 5/5] arm64: dts: add LX2160ARDB board support
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Vabhav Sharma, Priyanka Jain,
Sriram Dash
In-Reply-To: <1534747636-20064-1-git-send-email-vabhav.sharma@nxp.com>
LX2160A reference design board (RDB) is a high-performance
computing, evaluation, and development platform with LX2160A
SoC.
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 95 +++++++++++++++++++++++
2 files changed, 96 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 0000000..70fad20
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -0,0 +1,95 @@
+// 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;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ };
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ pca9547@77 {
+ compatible = "nxp,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+
+ ina220@40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ sa56004@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ };
+
+ sa56004@4d {
+ compatible = "nxp,sa56004";
+ reg = <0x4d>;
+ };
+ };
+ };
+};
+
+&i2c4 {
+ status = "okay";
+
+ rtc@51 {
+ compatible = "nxp,pcf2129";
+ reg = <0x51>;
+ // IRQ10_B
+ interrupts = <0 150 0x4>;
+ };
+
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
+&crypto {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: add QorIQ LX2160A SoC support
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Vabhav Sharma, Ramneek Mehresh,
Zhang Ying-22455, Nipun Gupta, Priyanka Jain, Yogesh Gaur,
Sriram Dash
In-Reply-To: <1534747636-20064-1-git-send-email-vabhav.sharma@nxp.com>
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 <ramneek.mehresh@nxp.com>
Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
Signed-off-by: Sriram Dash <sriram.dash@nxp.com>
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 572 +++++++++++++++++++++++++
1 file changed, 572 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 0000000..e35e494
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -0,0 +1,572 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree Include file for Layerscape-LX2160A family SoC.
+//
+// Copyright 2018 NXP
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/memreserve/ 0x80000000 0x00010000;
+
+/ {
+ 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";
+ reg = <0x0>;
+ clocks = <&clockgen 1 0>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x1>;
+ clocks = <&clockgen 1 0>;
+ next-level-cache = <&cluster0_l2>;
+ };
+
+ cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x100>;
+ clocks = <&clockgen 1 1>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x101>;
+ clocks = <&clockgen 1 1>;
+ next-level-cache = <&cluster1_l2>;
+ };
+
+ cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x200>;
+ clocks = <&clockgen 1 2>;
+ next-level-cache = <&cluster2_l2>;
+ };
+
+ cpu@201 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x201>;
+ clocks = <&clockgen 1 2>;
+ next-level-cache = <&cluster2_l2>;
+ };
+
+ cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x300>;
+ clocks = <&clockgen 1 3>;
+ next-level-cache = <&cluster3_l2>;
+ };
+
+ cpu@301 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x301>;
+ clocks = <&clockgen 1 3>;
+ next-level-cache = <&cluster3_l2>;
+ };
+
+ cpu@400 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x400>;
+ clocks = <&clockgen 1 4>;
+ next-level-cache = <&cluster4_l2>;
+ };
+
+ cpu@401 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x401>;
+ clocks = <&clockgen 1 4>;
+ next-level-cache = <&cluster4_l2>;
+ };
+
+ cpu@500 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x500>;
+ clocks = <&clockgen 1 5>;
+ next-level-cache = <&cluster5_l2>;
+ };
+
+ cpu@501 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x501>;
+ clocks = <&clockgen 1 5>;
+ next-level-cache = <&cluster5_l2>;
+ };
+
+ cpu@600 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x600>;
+ clocks = <&clockgen 1 6>;
+ next-level-cache = <&cluster6_l2>;
+ };
+
+ cpu@601 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x601>;
+ clocks = <&clockgen 1 6>;
+ next-level-cache = <&cluster6_l2>;
+ };
+
+ cpu@700 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x700>;
+ clocks = <&clockgen 1 7>;
+ next-level-cache = <&cluster7_l2>;
+ };
+
+ cpu@701 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x701>;
+ clocks = <&clockgen 1 7>;
+ next-level-cache = <&cluster7_l2>;
+ };
+
+ cluster0_l2: l2-cache0 {
+ compatible = "cache";
+ };
+
+ cluster1_l2: l2-cache1 {
+ compatible = "cache";
+ };
+
+ cluster2_l2: l2-cache2 {
+ compatible = "cache";
+ };
+
+ cluster3_l2: l2-cache3 {
+ compatible = "cache";
+ };
+
+ cluster4_l2: l2-cache4 {
+ compatible = "cache";
+ };
+
+ cluster5_l2: l2-cache5 {
+ compatible = "cache";
+ };
+
+ cluster6_l2: l2-cache6 {
+ compatible = "cache";
+ };
+
+ cluster7_l2: l2-cache7 {
+ compatible = "cache";
+ };
+ };
+
+ gic: interrupt-controller@6000000 {
+ compatible = "arm,gic-v3";
+ reg = <0x0 0x06000000 0 0x10000>, // GIC Dist
+ <0x0 0x06200000 0 0x200000>, // GICR (RD_base +
+ // SGI_base)
+ <0x0 0x0c0c0000 0 0x2000>, // GICC
+ <0x0 0x0c0d0000 0 0x1000>, // GICH
+ <0x0 0x0c0e0000 0 0x20000>; // GICV
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ interrupt-controller;
+ interrupts = <1 9 0x4>;
+
+ its: gic-its@6020000 {
+ compatible = "arm,gic-v3-its";
+ msi-controller;
+ reg = <0x0 0x6020000 0 0x20000>;
+ };
+ };
+
+ rstcr: syscon@1e60000 {
+ compatible = "syscon";
+ reg = <0x0 0x1e60000 0x0 0x4>;
+ };
+
+ reboot {
+ compatible ="syscon-reboot";
+ regmap = <&rstcr>;
+ offset = <0x0>;
+ mask = <0x2>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <1 13 4>, // Physical Secure PPI, active-low
+ <1 14 4>, // Physical Non-Secure PPI, active-low
+ <1 11 4>, // Virtual PPI, active-low
+ <1 10 4>; // Hypervisor PPI, active-low
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = <1 7 0x8>; // PMU PPI, Level low type
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ memory@80000000 {
+ // DRAM space - 1, size : 2 GB DRAM
+ device_type = "memory";
+ reg = <0x00000000 0x80000000 0 0x80000000>;
+ };
+
+ ddr1: memory-controller@1080000 {
+ compatible = "fsl,qoriq-memory-controller";
+ reg = <0x0 0x1080000 0x0 0x1000>;
+ interrupts = <0 17 0x4>;
+ little-endian;
+ };
+
+ ddr2: memory-controller@1090000 {
+ compatible = "fsl,qoriq-memory-controller";
+ reg = <0x0 0x1090000 0x0 0x1000>;
+ interrupts = <0 18 0x4>;
+ little-endian;
+ };
+
+ sysclk: sysclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "sysclk";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ clockgen: clocking@1300000 {
+ compatible = "fsl,lx2160a-clockgen";
+ reg = <0 0x1300000 0 0xa0000>;
+ #clock-cells = <2>;
+ clocks = <&sysclk>;
+ };
+
+ crypto: crypto@8000000 {
+ compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
+ fsl,sec-era = <10>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x8000000 0x100000>;
+ reg = <0x00 0x8000000 0x0 0x100000>;
+ interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+ dma-coherent;
+ status = "disabled";
+
+ sec_jr0: jr@10000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x10000 0x10000>;
+ interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr@20000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x20000 0x10000>;
+ interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr2: jr@30000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x30000 0x10000>;
+ interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr3: jr@40000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+ "fsl,sec-v4.0-job-ring";
+ reg = <0x40000 0x10000>;
+ interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ dcfg: dcfg@1e00000 {
+ compatible = "fsl,lx2160a-dcfg", "syscon";
+ reg = <0x0 0x1e00000 0x0 0x10000>;
+ little-endian;
+ };
+
+ gpio0: gpio@2300000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <0 36 0x4>; // Level high type
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio1: gpio@2310000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x0 0x2310000 0x0 0x10000>;
+ interrupts = <0 36 0x4>; // Level high type
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio2: gpio@2320000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x0 0x2320000 0x0 0x10000>;
+ interrupts = <0 37 0x4>; // Level high type
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpio3: gpio@2330000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x0 0x2330000 0x0 0x10000>;
+ interrupts = <0 37 0x4>; // Level high type
+ gpio-controller;
+ little-endian;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+
+ i2c0: i2c@2000000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2000000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ fsl-scl-gpio = <&gpio2 15 0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c@2010000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2010000 0x0 0x10000>;
+ interrupts = <0 34 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ i2c2: i2c@2020000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2020000 0x0 0x10000>;
+ interrupts = <0 35 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ i2c3: i2c@2030000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2030000 0x0 0x10000>;
+ interrupts = <0 35 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@2040000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2040000 0x0 0x10000>;
+ interrupts = <0 74 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ fsl-scl-gpio = <&gpio2 16 0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@2050000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2050000 0x0 0x10000>;
+ interrupts = <0 74 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ i2c6: i2c@2060000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2060000 0x0 0x10000>;
+ interrupts = <0 75 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ i2c7: i2c@2070000 {
+ compatible = "fsl,vf610-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2070000 0x0 0x10000>;
+ interrupts = <0 75 0x4>; // Level high type
+ clock-names = "i2c";
+ clocks = <&clockgen 4 7>;
+ status = "disabled";
+ };
+
+ uart0: serial@21c0000 {
+ device_type = "serial";
+ compatible = "arm,pl011","arm,sbsa-uart";
+ reg = <0x0 0x21c0000 0x0 0x1000>;
+ interrupts = <0 32 0x4>; // Level high type
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ uart1: serial@21d0000 {
+ device_type = "serial";
+ compatible = "arm,pl011","arm,sbsa-uart";
+ reg = <0x0 0x21d0000 0x0 0x1000>;
+ interrupts = <0 33 0x4>; // Level high type
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ uart2: serial@21e0000 {
+ device_type = "serial";
+ compatible = "arm,pl011","arm,sbsa-uart";
+ reg = <0x0 0x21e0000 0x0 0x1000>;
+ interrupts = <0 72 0x4>; // Level high type
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ uart3: serial@21f0000 {
+ device_type = "serial";
+ compatible = "arm,pl011","arm,sbsa-uart";
+ reg = <0x0 0x21f0000 0x0 0x1000>;
+ interrupts = <0 73 0x4>; // Level high type
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ smmu: iommu@5000000 {
+ compatible = "arm,mmu-500";
+ reg = <0 0x5000000 0 0x800000>;
+ #iommu-cells = <1>;
+ #global-interrupts = <14>;
+ interrupts = <0 13 4>, // global secure fault
+ <0 14 4>, // combined secure interrupt
+ <0 15 4>, // global non-secure fault
+ <0 16 4>, // combined non-secure interrupt
+ // performance counter interrupts 0-9
+ <0 211 4>, <0 212 4>,
+ <0 213 4>, <0 214 4>,
+ <0 215 4>, <0 216 4>,
+ <0 217 4>, <0 218 4>,
+ <0 219 4>, <0 220 4>,
+ // per context interrupt, 64 interrupts
+ <0 146 4>, <0 147 4>,
+ <0 148 4>, <0 149 4>,
+ <0 150 4>, <0 151 4>,
+ <0 152 4>, <0 153 4>,
+ <0 154 4>, <0 155 4>,
+ <0 156 4>, <0 157 4>,
+ <0 158 4>, <0 159 4>,
+ <0 160 4>, <0 161 4>,
+ <0 162 4>, <0 163 4>,
+ <0 164 4>, <0 165 4>,
+ <0 166 4>, <0 167 4>,
+ <0 168 4>, <0 169 4>,
+ <0 170 4>, <0 171 4>,
+ <0 172 4>, <0 173 4>,
+ <0 174 4>, <0 175 4>,
+ <0 176 4>, <0 177 4>,
+ <0 178 4>, <0 179 4>,
+ <0 180 4>, <0 181 4>,
+ <0 182 4>, <0 183 4>,
+ <0 184 4>, <0 185 4>,
+ <0 186 4>, <0 187 4>,
+ <0 188 4>, <0 189 4>,
+ <0 190 4>, <0 191 4>,
+ <0 192 4>, <0 193 4>,
+ <0 194 4>, <0 195 4>,
+ <0 196 4>, <0 197 4>,
+ <0 198 4>, <0 199 4>,
+ <0 200 4>, <0 201 4>,
+ <0 202 4>, <0 203 4>,
+ <0 204 4>, <0 205 4>,
+ <0 206 4>, <0 207 4>,
+ <0 208 4>, <0 209 4>;
+ dma-coherent;
+ };
+
+ usb0: usb3@3100000 {
+ status = "disabled";
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 80 0x4>; // Level high type
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ usb1: usb3@3110000 {
+ status = "disabled";
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3110000 0x0 0x10000>;
+ interrupts = <0 81 0x4>; // Level high type
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ };
+
+ watchdog@23a0000 {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x23a0000 0 0x1000>,
+ <0x0 0x2390000 0 0x1000>;
+ interrupts = <0 59 4>;
+ timeout-sec = <30>;
+ };
+
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] drivers: clk-qoriq: Add clockgen support for lx2160a
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Yogesh Gaur, Tang Yuantian,
Vabhav Sharma
In-Reply-To: <1534747636-20064-1-git-send-email-vabhav.sharma@nxp.com>
From: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
Add clockgen support for lx2160a.
Added entry for compat 'fsl,lx2160a-clockgen'.
As LX2160A is 16 core, so modified value for NUM_CMUX
Signed-off-by: Tang Yuantian <andy.tang@nxp.com>
Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
---
drivers/clk/clk-qoriq.c | 14 +++++++++++++-
drivers/cpufreq/qoriq-cpufreq.c | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 3a1812f..fc6e308 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -60,7 +60,7 @@ struct clockgen_muxinfo {
};
#define NUM_HWACCEL 5
-#define NUM_CMUX 8
+#define NUM_CMUX 16
struct clockgen;
@@ -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
^ permalink raw reply related
* [PATCH 2/5] soc/fsl/guts: Add compatible string for LX2160A
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Vabhav Sharma
In-Reply-To: <1534747636-20064-1-git-send-email-vabhav.sharma@nxp.com>
Adding compatible string "lx2160a-dcfg" to
initialize guts driver for lx2160
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
---
drivers/soc/fsl/guts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
index 302e0c8..5e1e633 100644
--- a/drivers/soc/fsl/guts.c
+++ b/drivers/soc/fsl/guts.c
@@ -222,6 +222,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
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: arm64: add compatible for LX2160A
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Vabhav Sharma
In-Reply-To: <1534747636-20064-1-git-send-email-vabhav.sharma@nxp.com>
Add compatible for LX2160A SoC,QDS and RDB board
Signed-off-by: Vabhav Sharma <vabhav.sharma@nxp.com>
---
Documentation/devicetree/bindings/arm/fsl.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index cdb9dd7..76256bd 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -218,3 +218,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";
--
2.7.4
^ permalink raw reply related
* [PATCH 0/5] arm64: dts: NXP: add basic dts file for LX2160A SoC
From: Vabhav Sharma @ 2018-08-20 6:47 UTC (permalink / raw)
To: linux-kernel, devicetree, robh+dt, mark.rutland, linuxppc-dev,
linux-arm-kernel, mturquette, sboyd, rjw, viresh.kumar, linux-clk,
linux-pm, linux-kernel-owner, catalin.marinas, will.deacon,
gregkh, arnd, kstewart, yamada.masahiro
Cc: linux, V.Sethi, udit.kumar, Vabhav Sharma
- 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 compatible string for LX2160A
arm64: dts: add QorIQ LX2160A SoC support
arm64: dts: add LX2160ARDB board support
Yogesh Gaur (1):
drivers: clk-qoriq: Add clockgen support for lx2160a
Documentation/devicetree/bindings/arm/fsl.txt | 12 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 95 ++++
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 572 ++++++++++++++++++++++
drivers/clk/clk-qoriq.c | 14 +-
drivers/cpufreq/qoriq-cpufreq.c | 1 +
drivers/soc/fsl/guts.c | 1 +
7 files changed, 695 insertions(+), 1 deletion(-)
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
^ permalink raw reply
* Re: [PATCH v7 2/2] powerpc: Use cpu_smallcore_sibling_mask at SMT level on bigcores
From: Srikar Dronamraju @ 2018-08-20 18:05 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Michael Ellerman, Benjamin Herrenschmidt, Michael Neuling,
Vaidyanathan Srinivasan, Akshay Adiga, Shilpasri G Bhat,
Oliver O'Halloran, Nicholas Piggin, Murilo Opsfelder Araujo,
Anton Blanchard, linuxppc-dev, linux-kernel
In-Reply-To: <1534743704-4760-3-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2018-08-20 11:11:44]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> Each of the SMT4 cores forming a big-core are more or less independent
> units. Thus when multiple tasks are scheduled to run on the fused
> core, we get the best performance when the tasks are spread across the
> pair of SMT4 cores.
>
> This patch achieves this by setting the SMT level mask to correspond
> to the smallcore sibling mask on big-core systems. This patch also
> ensures that while checked for shared-caches on big-core system, we
> use the smallcore_sibling_mask to compare with the l2_cache_mask.
> This ensure that the CACHE level sched-domain is created, whose groups
> correspond to the threads of the big-core.
>
> With this patch, the SMT sched-domain with SMT=8,4,2 on big-core
> systems are as follows:
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH v7 1/2] powerpc: Detect the presence of big-cores via "ibm,thread-groups"
From: Srikar Dronamraju @ 2018-08-20 17:59 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Michael Ellerman, Benjamin Herrenschmidt, Michael Neuling,
Vaidyanathan Srinivasan, Akshay Adiga, Shilpasri G Bhat,
Oliver O'Halloran, Nicholas Piggin, Murilo Opsfelder Araujo,
Anton Blanchard, linuxppc-dev, linux-kernel
In-Reply-To: <1534743704-4760-2-git-send-email-ego@linux.vnet.ibm.com>
* Gautham R. Shenoy <ego@linux.vnet.ibm.com> [2018-08-20 11:11:43]:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> On IBM POWER9, the device tree exposes a property array identifed by
one small nit:
s/identifed/identified/g
> "ibm,thread-groups" which will indicate which groups of threads share
> a particular set of resources.
>
> As of today we only have one form of grouping identifying the group of
> threads in the core that share the L1 cache, translation cache and
> instruction data flow.
>
> This patch defines the helper function to parse the contents of
> "ibm,thread-groups" and a new structure to contain the parsed output.
>
> The patch also creates the sysfs file named "small_core_siblings" that
> returns the physical ids of the threads in the core that share the L1
> cache, translation cache and instruction data flow.
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
Otherwise looks good to me.
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
^ permalink raw reply
* Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")
From: Christophe LEROY @ 2018-08-20 16:04 UTC (permalink / raw)
To: Michal Hocko
Cc: Michael Ellerman, Ram Pai, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, linux-mm
In-Reply-To: <20180820160133.GP29735@dhcp22.suse.cz>
Le 20/08/2018 à 18:01, Michal Hocko a écrit :
> On Mon 20-08-18 17:23:58, Christophe LEROY wrote:
>> Hello,
>>
>> I have an odd issue on my powerpc 8xx board.
>>
>> I am running latest 4.14 and get the following SIGSEGV which appears more or
>> less randomly.
>>
>> [ 9.190354] touch[91]: unhandled signal 11 at 67807b58 nip 777cf114 lr
>> 777cf100 code 30001
>> [ 24.634810] ifconfig[160]: unhandled signal 11 at 67ae7b58 nip 77aaf114
>> lr 77aaf100 code 30001
>> [ 30.383737] default.deconfi[231]: unhandled signal 11 at 67c8bb58 nip
>> 77c53114 lr 77c53100 code 30001
>> [ 37.655588] S15syslogd[251]: unhandled signal 11 at 6784fb58 nip 77817114
>> lr 77817100 code 30001
>> [ 40.974649] snmpd[315]: unhandled signal 11 at 67e0bb58 nip 77dd3114 lr
>> 77dd3100 code 30001
>> [ 43.220964] exe[338]: unhandled signal 11 at 67cd3b58 nip 77c9b114 lr
>> 77c9b100 code 30001
>> [ 44.191494] exe[348]: unhandled signal 11 at 67c1fb58 nip 77be7114 lr
>> 77be7100 code 30001
>> [ 59.175022] sleep[655]: unhandled signal 11 at 67ca3b58 nip 77c6b114 lr
>> 77c6b100 code 30001
>> [ 61.853406] smcroute[705]: unhandled signal 11 at 6789bb58 nip 77863114
>> lr 77863100 code 30001
>> [ 64.662431] smcroute[778]: unhandled signal 11 at 67e03b58 nip 77dcb114
>> lr 77dcb100 code 30001
>> [ 65.623103] smcroute[795]: unhandled signal 11 at 67bdbb58 nip 77ba3114
>> lr 77ba3100 code 30001
>> [ 66.579416] exe[825]: unhandled signal 11 at 67edbb58 nip 77ea3114 lr
>> 77ea3100 code 30001
>> [ 68.382941] exe[864]: unhandled signal 11 at 6789bb58 nip 77863114 lr
>> 77863100 code 30001
>> [ 95.187346] exe[1147]: unhandled signal 11 at 67e83b58 nip 77e4b114 lr
>> 77e4b100 code 30001
>> [ 105.238218] exe[1158]: unhandled signal 11 at 67ca3b58 nip 77c6b114 lr
>> 77c6b100 code 30001
>> [ 127.556731] exe[1181]: unhandled signal 11 at 67cc3b58 nip 77c8b114 lr
>> 77c8b100 code 30001
>> [ 135.558982] exe[1195]: unhandled signal 11 at 678d7b58 nip 7789f114 lr
>> 7789f100 code 30001
>> [ 147.579142] exe[1216]: unhandled signal 11 at 67c6bb58 nip 77c33114 lr
>> 77c33100 code 30001
>> [ 175.538747] exe[1262]: unhandled signal 11 at 67e2fb58 nip 77df7114 lr
>> 77df7100 code 30001
>> [ 186.552670] exe[1275]: unhandled signal 11 at 6781fb58 nip 777e7114 lr
>> 777e7100 code 30001
>> [ 230.629786] exe[1344]: unhandled signal 11 at 67cb3b58 nip 77c7b114 lr
>> 77c7b100 code 30001
>> [ 249.640396] repair-service.[1369]: unhandled signal 11 at 67e5fb58 nip
>> 77e27114 lr 77e27100 code 30001
>> [ 378.003410] exe[1593]: unhandled signal 11 at 678d7b58 nip 7789f114 lr
>> 7789f100 code 30001
>> [ 414.060661] exe[1656]: unhandled signal 11 at 67cc7b58 nip 77c8f114 lr
>> 77c8f100 code 30001
>>
>> The problem is present in 3.13, 3.14 and 3.15.
>>
>> I bisected its appearance with commit 6b31d5955cb29 ("mm, oom: fix potential
>> data corruption when oom_reaper races with writer")
>
> Do you see any oom killer invocations preceeding the SEGV? Some of those
> killed tasks simply do not look like a sensible oom victims (e.g.
> touch)...
No I don't see any.
>
>> And I bisected its disappearance with commit 99cd1302327a2 ("powerpc:
>> Deliver SEGV signal on pkey violation")
>
> Those two seem completely unrelated.
>
That's my feeling too, hence my incredulity
^ permalink raw reply
* Re: Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")
From: Michal Hocko @ 2018-08-20 16:01 UTC (permalink / raw)
To: Christophe LEROY
Cc: Michael Ellerman, Ram Pai, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, linux-mm
In-Reply-To: <7767bdf4-a034-ecb9-1ac8-4fa87f335818@c-s.fr>
On Mon 20-08-18 17:23:58, Christophe LEROY wrote:
> Hello,
>
> I have an odd issue on my powerpc 8xx board.
>
> I am running latest 4.14 and get the following SIGSEGV which appears more or
> less randomly.
>
> [ 9.190354] touch[91]: unhandled signal 11 at 67807b58 nip 777cf114 lr
> 777cf100 code 30001
> [ 24.634810] ifconfig[160]: unhandled signal 11 at 67ae7b58 nip 77aaf114
> lr 77aaf100 code 30001
> [ 30.383737] default.deconfi[231]: unhandled signal 11 at 67c8bb58 nip
> 77c53114 lr 77c53100 code 30001
> [ 37.655588] S15syslogd[251]: unhandled signal 11 at 6784fb58 nip 77817114
> lr 77817100 code 30001
> [ 40.974649] snmpd[315]: unhandled signal 11 at 67e0bb58 nip 77dd3114 lr
> 77dd3100 code 30001
> [ 43.220964] exe[338]: unhandled signal 11 at 67cd3b58 nip 77c9b114 lr
> 77c9b100 code 30001
> [ 44.191494] exe[348]: unhandled signal 11 at 67c1fb58 nip 77be7114 lr
> 77be7100 code 30001
> [ 59.175022] sleep[655]: unhandled signal 11 at 67ca3b58 nip 77c6b114 lr
> 77c6b100 code 30001
> [ 61.853406] smcroute[705]: unhandled signal 11 at 6789bb58 nip 77863114
> lr 77863100 code 30001
> [ 64.662431] smcroute[778]: unhandled signal 11 at 67e03b58 nip 77dcb114
> lr 77dcb100 code 30001
> [ 65.623103] smcroute[795]: unhandled signal 11 at 67bdbb58 nip 77ba3114
> lr 77ba3100 code 30001
> [ 66.579416] exe[825]: unhandled signal 11 at 67edbb58 nip 77ea3114 lr
> 77ea3100 code 30001
> [ 68.382941] exe[864]: unhandled signal 11 at 6789bb58 nip 77863114 lr
> 77863100 code 30001
> [ 95.187346] exe[1147]: unhandled signal 11 at 67e83b58 nip 77e4b114 lr
> 77e4b100 code 30001
> [ 105.238218] exe[1158]: unhandled signal 11 at 67ca3b58 nip 77c6b114 lr
> 77c6b100 code 30001
> [ 127.556731] exe[1181]: unhandled signal 11 at 67cc3b58 nip 77c8b114 lr
> 77c8b100 code 30001
> [ 135.558982] exe[1195]: unhandled signal 11 at 678d7b58 nip 7789f114 lr
> 7789f100 code 30001
> [ 147.579142] exe[1216]: unhandled signal 11 at 67c6bb58 nip 77c33114 lr
> 77c33100 code 30001
> [ 175.538747] exe[1262]: unhandled signal 11 at 67e2fb58 nip 77df7114 lr
> 77df7100 code 30001
> [ 186.552670] exe[1275]: unhandled signal 11 at 6781fb58 nip 777e7114 lr
> 777e7100 code 30001
> [ 230.629786] exe[1344]: unhandled signal 11 at 67cb3b58 nip 77c7b114 lr
> 77c7b100 code 30001
> [ 249.640396] repair-service.[1369]: unhandled signal 11 at 67e5fb58 nip
> 77e27114 lr 77e27100 code 30001
> [ 378.003410] exe[1593]: unhandled signal 11 at 678d7b58 nip 7789f114 lr
> 7789f100 code 30001
> [ 414.060661] exe[1656]: unhandled signal 11 at 67cc7b58 nip 77c8f114 lr
> 77c8f100 code 30001
>
> The problem is present in 3.13, 3.14 and 3.15.
>
> I bisected its appearance with commit 6b31d5955cb29 ("mm, oom: fix potential
> data corruption when oom_reaper races with writer")
Do you see any oom killer invocations preceeding the SEGV? Some of those
killed tasks simply do not look like a sensible oom victims (e.g.
touch)...
> And I bisected its disappearance with commit 99cd1302327a2 ("powerpc:
> Deliver SEGV signal on pkey violation")
Those two seem completely unrelated.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Odd SIGSEGV issue introduced by commit 6b31d5955cb29 ("mm, oom: fix potential data corruption when oom_reaper races with writer")
From: Christophe LEROY @ 2018-08-20 15:23 UTC (permalink / raw)
To: Michal Hocko, Michael Ellerman, Ram Pai, Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm
Hello,
I have an odd issue on my powerpc 8xx board.
I am running latest 4.14 and get the following SIGSEGV which appears
more or less randomly.
[ 9.190354] touch[91]: unhandled signal 11 at 67807b58 nip 777cf114
lr 777cf100 code 30001
[ 24.634810] ifconfig[160]: unhandled signal 11 at 67ae7b58 nip
77aaf114 lr 77aaf100 code 30001
[ 30.383737] default.deconfi[231]: unhandled signal 11 at 67c8bb58 nip
77c53114 lr 77c53100 code 30001
[ 37.655588] S15syslogd[251]: unhandled signal 11 at 6784fb58 nip
77817114 lr 77817100 code 30001
[ 40.974649] snmpd[315]: unhandled signal 11 at 67e0bb58 nip 77dd3114
lr 77dd3100 code 30001
[ 43.220964] exe[338]: unhandled signal 11 at 67cd3b58 nip 77c9b114 lr
77c9b100 code 30001
[ 44.191494] exe[348]: unhandled signal 11 at 67c1fb58 nip 77be7114 lr
77be7100 code 30001
[ 59.175022] sleep[655]: unhandled signal 11 at 67ca3b58 nip 77c6b114
lr 77c6b100 code 30001
[ 61.853406] smcroute[705]: unhandled signal 11 at 6789bb58 nip
77863114 lr 77863100 code 30001
[ 64.662431] smcroute[778]: unhandled signal 11 at 67e03b58 nip
77dcb114 lr 77dcb100 code 30001
[ 65.623103] smcroute[795]: unhandled signal 11 at 67bdbb58 nip
77ba3114 lr 77ba3100 code 30001
[ 66.579416] exe[825]: unhandled signal 11 at 67edbb58 nip 77ea3114 lr
77ea3100 code 30001
[ 68.382941] exe[864]: unhandled signal 11 at 6789bb58 nip 77863114 lr
77863100 code 30001
[ 95.187346] exe[1147]: unhandled signal 11 at 67e83b58 nip 77e4b114
lr 77e4b100 code 30001
[ 105.238218] exe[1158]: unhandled signal 11 at 67ca3b58 nip 77c6b114
lr 77c6b100 code 30001
[ 127.556731] exe[1181]: unhandled signal 11 at 67cc3b58 nip 77c8b114
lr 77c8b100 code 30001
[ 135.558982] exe[1195]: unhandled signal 11 at 678d7b58 nip 7789f114
lr 7789f100 code 30001
[ 147.579142] exe[1216]: unhandled signal 11 at 67c6bb58 nip 77c33114
lr 77c33100 code 30001
[ 175.538747] exe[1262]: unhandled signal 11 at 67e2fb58 nip 77df7114
lr 77df7100 code 30001
[ 186.552670] exe[1275]: unhandled signal 11 at 6781fb58 nip 777e7114
lr 777e7100 code 30001
[ 230.629786] exe[1344]: unhandled signal 11 at 67cb3b58 nip 77c7b114
lr 77c7b100 code 30001
[ 249.640396] repair-service.[1369]: unhandled signal 11 at 67e5fb58
nip 77e27114 lr 77e27100 code 30001
[ 378.003410] exe[1593]: unhandled signal 11 at 678d7b58 nip 7789f114
lr 7789f100 code 30001
[ 414.060661] exe[1656]: unhandled signal 11 at 67cc7b58 nip 77c8f114
lr 77c8f100 code 30001
The problem is present in 3.13, 3.14 and 3.15.
I bisected its appearance with commit 6b31d5955cb29 ("mm, oom: fix
potential data corruption when oom_reaper races with writer")
And I bisected its disappearance with commit 99cd1302327a2 ("powerpc:
Deliver SEGV signal on pkey violation")
Looking at those two commits, especially the one which makes it
dissapear, I'm quite sceptic. Any idea on what could be the cause and/or
how to investigate further ?
Thanks
Christophe
^ permalink raw reply
* [PATCH v2 0/3] powerpc/pseries: use H_BLOCK_REMOVE
From: Laurent Dufour @ 2018-08-20 14:29 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: aneesh.kumar, mpe, benh, paulus, npiggin
On very large system we could see soft lockup fired when a process is
exiting
watchdog: BUG: soft lockup - CPU#851 stuck for 21s! [forkoff:215523]
Modules linked in: pseries_rng rng_core xfs raid10 vmx_crypto btrfs libcrc32c xor zstd_decompress zstd_compress xxhash lzo_compress raid6_pq crc32c_vpmsum lpfc crc_t10dif crct10dif_generic crct10dif_common dm_multipath scsi_dh_rdac scsi_dh_alua autofs4
CPU: 851 PID: 215523 Comm: forkoff Not tainted 4.17.0 #1
NIP: c0000000000b995c LR: c0000000000b8f64 CTR: 000000000000aa18
REGS: c00006b0645b7610 TRAP: 0901 Not tainted (4.17.0)
MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 22042082 XER: 00000000
CFAR: 00000000006cf8f0 SOFTE: 0
GPR00: 0010000000000000 c00006b0645b7890 c000000000f99200 0000000000000000
GPR04: 8e000001a5a4de58 400249cf1bfd5480 8e000001a5a4de50 400249cf1bfd5480
GPR08: 8e000001a5a4de48 400249cf1bfd5480 8e000001a5a4de40 400249cf1bfd5480
GPR12: ffffffffffffffff c00000001e690800
NIP [c0000000000b995c] plpar_hcall9+0x44/0x7c
LR [c0000000000b8f64] pSeries_lpar_flush_hash_range+0x324/0x3d0
Call Trace:
[c00006b0645b7890] [8e000001a5a4dd20] 0x8e000001a5a4dd20 (unreliable)
[c00006b0645b7a00] [c00000000006d5b0] flush_hash_range+0x60/0x110
[c00006b0645b7a50] [c000000000072a2c] __flush_tlb_pending+0x4c/0xd0
[c00006b0645b7a80] [c0000000002eaf44] unmap_page_range+0x984/0xbd0
[c00006b0645b7bc0] [c0000000002eb594] unmap_vmas+0x84/0x100
[c00006b0645b7c10] [c0000000002f8afc] exit_mmap+0xac/0x1f0
[c00006b0645b7cd0] [c0000000000f2638] mmput+0x98/0x1b0
[c00006b0645b7d00] [c0000000000fc9d0] do_exit+0x330/0xc00
[c00006b0645b7dc0] [c0000000000fd384] do_group_exit+0x64/0x100
[c00006b0645b7e00] [c0000000000fd44c] sys_exit_group+0x2c/0x30
[c00006b0645b7e30] [c00000000000b960] system_call+0x58/0x6c
Instruction dump:
60000000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378
e9410060 e9610068 e9810070 44000022 <7d806378> e9810028 f88c0000 f8ac0008
This happens when removing the PTE by calling the hypervisor using the
H_BULK_REMOVE call. This call is processing up to 4 PTEs but is doing a
tlbie for each PTE it is processing. This could lead to long time spent in
the hypervisor (sometimes up to 4s) and soft lockup being raised because
the scheduler is not called in zap_pte_range().
Since the Power7's time, the hypervisor is providing a new hcall
H_BLOCK_REMOVE allowing processing up to 8 PTEs with one call to
tlbie. By limiting the amount of tlbie generated, this reduces the time
spent invalidating the PTEs.
This hcall requires that the pages are "all within the same naturally
aligned 8 page virtual address block".
With this patch series applied, I couldn't see any soft lockup raised on
the victim LPAR I was running the test one.
Changes since V1:
- Remove a call to BUG_ON() in call_block_remove() since this one can be
handled gently.
- Remove uneeded of current_vpgb to 0 when retrying entries in
hugepage_block_invalidate() and do_block_remove().
Laurent Dufour (3):
powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
powerpc/pseries/mm: factorize PTE slot computation
powerpc/pseries/mm: call H_BLOCK_REMOVE
arch/powerpc/include/asm/firmware.h | 3 +-
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/platforms/pseries/firmware.c | 1 +
arch/powerpc/platforms/pseries/lpar.c | 241 ++++++++++++++++++++++++++++--
4 files changed, 230 insertions(+), 16 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 3/3] powerpc/pseries/mm: call H_BLOCK_REMOVE
From: Laurent Dufour @ 2018-08-20 14:29 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: aneesh.kumar, mpe, benh, paulus, npiggin
In-Reply-To: <1534775376-22480-1-git-send-email-ldufour@linux.vnet.ibm.com>
This hypervisor's call allows to remove up to 8 ptes with only call to
tlbie.
The virtual pages must be all within the same naturally aligned 8 pages
virtual address block and have the same page and segment size encodings.
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/platforms/pseries/lpar.c | 214 ++++++++++++++++++++++++++++++++--
2 files changed, 207 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
index a0b17f9f1ea4..c349d3960d63 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -278,6 +278,7 @@
#define H_COP 0x304
#define H_GET_MPP_X 0x314
#define H_SET_MODE 0x31C
+#define H_BLOCK_REMOVE 0x328
#define H_CLEAR_HPT 0x358
#define H_REQUEST_VMC 0x360
#define H_RESIZE_HPT_PREPARE 0x36C
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index ebc852e3607d..0b5081085a44 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -417,6 +417,79 @@ static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long vpn,
BUG_ON(lpar_rc != H_SUCCESS);
}
+
+/*
+ * As defined in the PAPR's section 14.5.4.1.8
+ * The control mask doesn't include the returned reference and change bit from
+ * the processed PTE.
+ */
+#define HBLKR_AVPN 0x0100000000000000UL
+#define HBLKR_CTRL_MASK 0xf800000000000000UL
+#define HBLKR_CTRL_SUCCESS 0x8000000000000000UL
+#define HBLKR_CTRL_ERRNOTFOUND 0x8800000000000000UL
+#define HBLKR_CTRL_ERRBUSY 0xa000000000000000UL
+
+/**
+ * H_BLOCK_REMOVE caller.
+ * @idx should point to the latest @param entry set with a PTEX.
+ * If PTE cannot be processed because another CPUs has already locked that
+ * group, those entries are put back in @param starting at index 1.
+ * If entries has to be retried and @retry_busy is set to true, these entries
+ * are retried until success. If @retry_busy is set to false, the returned
+ * is the number of entries yet to process.
+ */
+static unsigned long call_block_remove(unsigned long idx, unsigned long *param,
+ bool retry_busy)
+{
+ unsigned long i, rc, new_idx;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+
+ if (idx < 2) {
+ pr_warn("Unexpected empty call to H_BLOCK_REMOVE");
+ return 0;
+ }
+again:
+ new_idx = 0;
+ if (idx > PLPAR_HCALL9_BUFSIZE) {
+ pr_err("Too many PTEs (%lu) for H_BLOCK_REMOVE", idx);
+ idx = PLPAR_HCALL9_BUFSIZE;
+ } else if (idx < PLPAR_HCALL9_BUFSIZE)
+ param[idx] = HBR_END;
+
+ rc = plpar_hcall9(H_BLOCK_REMOVE, retbuf,
+ param[0], /* AVA */
+ param[1], param[2], param[3], param[4], /* TS0-7 */
+ param[5], param[6], param[7], param[8]);
+ if (rc == H_SUCCESS)
+ return 0;
+
+ BUG_ON(rc != H_PARTIAL);
+
+ /* Check that the unprocessed entries were 'not found' or 'busy' */
+ for (i = 0; i < idx-1; i++) {
+ unsigned long ctrl = retbuf[i] & HBLKR_CTRL_MASK;
+
+ if (ctrl == HBLKR_CTRL_ERRBUSY) {
+ param[++new_idx] = param[i+1];
+ continue;
+ }
+
+ BUG_ON(ctrl != HBLKR_CTRL_SUCCESS
+ && ctrl != HBLKR_CTRL_ERRNOTFOUND);
+ }
+
+ /*
+ * If there were entries found busy, retry these entries if requested,
+ * of if all the entries have to be retried.
+ */
+ if (new_idx && (retry_busy || new_idx == (PLPAR_HCALL9_BUFSIZE-1))) {
+ idx = new_idx + 1;
+ goto again;
+ }
+
+ return new_idx;
+}
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
/*
* Limit iterations holding pSeries_lpar_tlbie_lock to 3. We also need
@@ -424,17 +497,57 @@ static void pSeries_lpar_hpte_invalidate(unsigned long slot, unsigned long vpn,
*/
#define PPC64_HUGE_HPTE_BATCH 12
-static void __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
- unsigned long *vpn, int count,
- int psize, int ssize)
+static void hugepage_block_invalidate(unsigned long *slot, unsigned long *vpn,
+ int count, int psize, int ssize)
{
unsigned long param[PLPAR_HCALL9_BUFSIZE];
- int i = 0, pix = 0, rc;
- unsigned long flags = 0;
- int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+ unsigned long shift, current_vpgb, vpgb;
+ int i, pix = 0;
- if (lock_tlbie)
- spin_lock_irqsave(&pSeries_lpar_tlbie_lock, flags);
+ shift = mmu_psize_defs[psize].shift;
+
+ for (i = 0; i < count; i++) {
+ /*
+ * Shifting 3 bits more on the right to get a
+ * 8 pages aligned virtual addresse.
+ */
+ vpgb = (vpn[i] >> (shift - VPN_SHIFT + 3));
+ if (!pix || vpgb != current_vpgb) {
+ /*
+ * Need to start a new 8 pages block, flush
+ * the current one if needed.
+ */
+ if (pix)
+ (void)call_block_remove(pix, param, true);
+ current_vpgb = vpgb;
+ param[0] = hpte_encode_avpn(vpn[i], psize, ssize);
+ pix = 1;
+ }
+
+ param[pix++] = HBR_REQUEST | HBLKR_AVPN | slot[i];
+ if (pix == PLPAR_HCALL9_BUFSIZE) {
+ pix = call_block_remove(pix, param, false);
+ /*
+ * pix = 0 means that all the entries were
+ * removed, we can start a new block.
+ * Otherwise, this means that there are entries
+ * to retry, and pix points to latest one, so
+ * we should increment it and try to continue
+ * the same block.
+ */
+ if (pix)
+ pix++;
+ }
+ }
+ if (pix)
+ (void)call_block_remove(pix, param, true);
+}
+
+static void hugepage_bulk_invalidate(unsigned long *slot, unsigned long *vpn,
+ int count, int psize, int ssize)
+{
+ unsigned long param[PLPAR_HCALL9_BUFSIZE];
+ int i = 0, pix = 0, rc;
for (i = 0; i < count; i++) {
@@ -462,6 +575,23 @@ static void __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
param[6], param[7]);
BUG_ON(rc != H_SUCCESS);
}
+}
+
+static inline void __pSeries_lpar_hugepage_invalidate(unsigned long *slot,
+ unsigned long *vpn,
+ int count, int psize,
+ int ssize)
+{
+ unsigned long flags = 0;
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+
+ if (lock_tlbie)
+ spin_lock_irqsave(&pSeries_lpar_tlbie_lock, flags);
+
+ if (firmware_has_feature(FW_FEATURE_BLOCK_REMOVE))
+ hugepage_block_invalidate(slot, vpn, count, psize, ssize);
+ else
+ hugepage_bulk_invalidate(slot, vpn, count, psize, ssize);
if (lock_tlbie)
spin_unlock_irqrestore(&pSeries_lpar_tlbie_lock, flags);
@@ -564,6 +694,68 @@ static inline unsigned long compute_slot(real_pte_t pte,
return slot;
}
+/**
+ * The hcall H_BLOCK_REMOVE implies that the virtual pages to processed are
+ * "all within the same naturally aligned 8 page virtual address block".
+ */
+static void do_block_remove(unsigned long number, struct ppc64_tlb_batch *batch,
+ unsigned long *param)
+{
+ unsigned long vpn;
+ unsigned long i, pix = 0;
+ unsigned long index, shift, slot, current_vpgb, vpgb;
+ real_pte_t pte;
+ int psize, ssize;
+
+ psize = batch->psize;
+ ssize = batch->ssize;
+
+ for (i = 0; i < number; i++) {
+ vpn = batch->vpn[i];
+ pte = batch->pte[i];
+ pte_iterate_hashed_subpages(pte, psize, vpn, index, shift) {
+ /*
+ * Shifting 3 bits more on the right to get a
+ * 8 pages aligned virtual addresse.
+ */
+ vpgb = (vpn >> (shift - VPN_SHIFT + 3));
+ if (!pix || vpgb != current_vpgb) {
+ /*
+ * Need to start a new 8 pages block, flush
+ * the current one if needed.
+ */
+ if (pix)
+ (void)call_block_remove(pix, param,
+ true);
+ current_vpgb = vpgb;
+ param[0] = hpte_encode_avpn(vpn, psize,
+ ssize);
+ pix = 1;
+ }
+
+ slot = compute_slot(pte, vpn, index, shift, ssize);
+ param[pix++] = HBR_REQUEST | HBLKR_AVPN | slot;
+
+ if (pix == PLPAR_HCALL9_BUFSIZE) {
+ pix = call_block_remove(pix, param, false);
+ /*
+ * pix = 0 means that all the entries were
+ * removed, we can start a new block.
+ * Otherwise, this means that there are entries
+ * to retry, and pix points to latest one, so
+ * we should increment it and try to continue
+ * the same block.
+ */
+ if (pix)
+ pix++;
+ }
+ } pte_iterate_hashed_end();
+ }
+
+ if (pix)
+ (void)call_block_remove(pix, param, true);
+}
+
/*
* Take a spinlock around flushes to avoid bouncing the hypervisor tlbie
* lock.
@@ -583,6 +775,11 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
if (lock_tlbie)
spin_lock_irqsave(&pSeries_lpar_tlbie_lock, flags);
+ if (firmware_has_feature(FW_FEATURE_BLOCK_REMOVE)) {
+ do_block_remove(number, batch, param);
+ goto out;
+ }
+
psize = batch->psize;
ssize = batch->ssize;
pix = 0;
@@ -621,6 +818,7 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
BUG_ON(rc != H_SUCCESS);
}
+out:
if (lock_tlbie)
spin_unlock_irqrestore(&pSeries_lpar_tlbie_lock, flags);
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] powerpc/pseries/mm: factorize PTE slot computation
From: Laurent Dufour @ 2018-08-20 14:29 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: aneesh.kumar, mpe, benh, paulus, npiggin
In-Reply-To: <1534775376-22480-1-git-send-email-ldufour@linux.vnet.ibm.com>
This part of code will be called also when dealing with H_BLOCK_REMOVE.
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/lpar.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index d3992ced0782..ebc852e3607d 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -546,6 +546,24 @@ static int pSeries_lpar_hpte_removebolted(unsigned long ea,
return 0;
}
+
+static inline unsigned long compute_slot(real_pte_t pte,
+ unsigned long vpn,
+ unsigned long index,
+ unsigned long shift,
+ int ssize)
+{
+ unsigned long slot, hash, hidx;
+
+ hash = hpt_hash(vpn, shift, ssize);
+ hidx = __rpte_to_hidx(pte, index);
+ if (hidx & _PTEIDX_SECONDARY)
+ hash = ~hash;
+ slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
+ slot += hidx & _PTEIDX_GROUP_IX;
+ return slot;
+}
+
/*
* Take a spinlock around flushes to avoid bouncing the hypervisor tlbie
* lock.
@@ -558,7 +576,7 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
struct ppc64_tlb_batch *batch = this_cpu_ptr(&ppc64_tlb_batch);
int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
unsigned long param[PLPAR_HCALL9_BUFSIZE];
- unsigned long hash, index, shift, hidx, slot;
+ unsigned long index, shift, slot;
real_pte_t pte;
int psize, ssize;
@@ -572,12 +590,7 @@ static void pSeries_lpar_flush_hash_range(unsigned long number, int local)
vpn = batch->vpn[i];
pte = batch->pte[i];
pte_iterate_hashed_subpages(pte, psize, vpn, index, shift) {
- hash = hpt_hash(vpn, shift, ssize);
- hidx = __rpte_to_hidx(pte, index);
- if (hidx & _PTEIDX_SECONDARY)
- hash = ~hash;
- slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
- slot += hidx & _PTEIDX_GROUP_IX;
+ slot = compute_slot(pte, vpn, index, shift, ssize);
if (!firmware_has_feature(FW_FEATURE_BULK_REMOVE)) {
/*
* lpar doesn't use the passed actual page size
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] powerpc/pseries/mm: Introducing FW_FEATURE_BLOCK_REMOVE
From: Laurent Dufour @ 2018-08-20 14:29 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel; +Cc: aneesh.kumar, mpe, benh, paulus, npiggin
In-Reply-To: <1534775376-22480-1-git-send-email-ldufour@linux.vnet.ibm.com>
This feature tells if the hcall H_BLOCK_REMOVE is available.
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/firmware.h | 3 ++-
arch/powerpc/platforms/pseries/firmware.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/firmware.h b/arch/powerpc/include/asm/firmware.h
index 7a051bd21f87..2aca2655fe30 100644
--- a/arch/powerpc/include/asm/firmware.h
+++ b/arch/powerpc/include/asm/firmware.h
@@ -52,6 +52,7 @@
#define FW_FEATURE_PRRN ASM_CONST(0x0000000200000000)
#define FW_FEATURE_DRMEM_V2 ASM_CONST(0x0000000400000000)
#define FW_FEATURE_DRC_INFO ASM_CONST(0x0000000800000000)
+#define FW_FEATURE_BLOCK_REMOVE ASM_CONST(0x0000001000000000)
#ifndef __ASSEMBLY__
@@ -69,7 +70,7 @@ enum {
FW_FEATURE_SET_MODE | FW_FEATURE_BEST_ENERGY |
FW_FEATURE_TYPE1_AFFINITY | FW_FEATURE_PRRN |
FW_FEATURE_HPT_RESIZE | FW_FEATURE_DRMEM_V2 |
- FW_FEATURE_DRC_INFO,
+ FW_FEATURE_DRC_INFO | FW_FEATURE_BLOCK_REMOVE,
FW_FEATURE_PSERIES_ALWAYS = 0,
FW_FEATURE_POWERNV_POSSIBLE = FW_FEATURE_OPAL,
FW_FEATURE_POWERNV_ALWAYS = 0,
diff --git a/arch/powerpc/platforms/pseries/firmware.c b/arch/powerpc/platforms/pseries/firmware.c
index a3bbeb43689e..1624501386f4 100644
--- a/arch/powerpc/platforms/pseries/firmware.c
+++ b/arch/powerpc/platforms/pseries/firmware.c
@@ -65,6 +65,7 @@ hypertas_fw_features_table[] = {
{FW_FEATURE_SET_MODE, "hcall-set-mode"},
{FW_FEATURE_BEST_ENERGY, "hcall-best-energy-1*"},
{FW_FEATURE_HPT_RESIZE, "hcall-hpt-resize"},
+ {FW_FEATURE_BLOCK_REMOVE, "hcall-block-remove"},
};
/* Build up the firmware features bitmask using the contents of
--
2.7.4
^ permalink raw reply related
* Re: [RFC 07/15] PCI/ACPI: clean up acpi_pci_root_create()
From: Arnd Bergmann @ 2018-08-20 11:36 UTC (permalink / raw)
To: Rafael Wysocki
Cc: linux-pci, Bjorn Helgaas, Linux Kernel Mailing List,
Christoph Hellwig, Lorenzo Pieralisi, Benjamin Herrenschmidt,
linuxppc-dev, ACPI Devel Maling List
In-Reply-To: <CAJZ5v0gu_agFQBS7UjTMY3FR7woPPN-riJ6frwk1QoetGoVjfA@mail.gmail.com>
On Mon, Aug 20, 2018 at 1:24 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Aug 20, 2018 at 1:20 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Aug 20, 2018 at 10:23 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > On Fri, Aug 17, 2018 at 12:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > @@ -909,8 +881,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> > > > int ret, busnum = root->secondary.start;
> > > > struct acpi_device *device = root->device;
> > > > int node = acpi_get_node(device->handle);
> > > > - struct pci_bus *bus;
> > > > - struct pci_host_bridge *host_bridge;
> > > > + struct pci_host_bridge *bridge;
> > >
> > > Why "bridge" and not "host" or even something to stand for "root complex"?
> > >
> > > Or maybe it can still be "host_bridge"?
> >
> > I did this for consistency with the naming in drivers/pci/probe.c,
> > which always declares the local variable as 'struct pci_host_bridge *bridge'.
> > It's easy to change here if you feel strongly about it (I don't).
>
> I would leave host_bridge here. It would make the patch smaller too I think.
Ok, I've changed my local copy as you suggested now.
Arnd
^ permalink raw reply
* Re: [PATCH v8 5/5] powernv/pseries: consolidate code for mce early handling.
From: Nicholas Piggin @ 2018-08-20 11:34 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: linuxppc-dev, Ananth Narayan, Laurent Dufour, Aneesh Kumar K.V,
Michal Suchanek, Michael Ellerman
In-Reply-To: <153469851942.21878.15396539991879060950.stgit@jupiter.in.ibm.com>
On Sun, 19 Aug 2018 22:38:39 +0530
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> Now that other platforms also implements real mode mce handler,
> lets consolidate the code by sharing existing powernv machine check
> early code. Rename machine_check_powernv_early to
> machine_check_common_early and reuse the code.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 155 ++++++----------------------------
> 1 file changed, 28 insertions(+), 127 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 12f056179112..2f85a7baf026 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -243,14 +243,13 @@ EXC_REAL_BEGIN(machine_check, 0x200, 0x100)
> SET_SCRATCH0(r13) /* save r13 */
> EXCEPTION_PROLOG_0(PACA_EXMC)
> BEGIN_FTR_SECTION
> - b machine_check_powernv_early
> + b machine_check_common_early
> FTR_SECTION_ELSE
> b machine_check_pSeries_0
> ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
> EXC_REAL_END(machine_check, 0x200, 0x100)
> EXC_VIRT_NONE(0x4200, 0x100)
> -TRAMP_REAL_BEGIN(machine_check_powernv_early)
> -BEGIN_FTR_SECTION
> +TRAMP_REAL_BEGIN(machine_check_common_early)
> EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)
> /*
> * Register contents:
> @@ -306,7 +305,9 @@ BEGIN_FTR_SECTION
> /* Save r9 through r13 from EXMC save area to stack frame. */
> EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
> mfmsr r11 /* get MSR value */
> +BEGIN_FTR_SECTION
> ori r11,r11,MSR_ME /* turn on ME bit */
> +END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
> ori r11,r11,MSR_RI /* turn on RI bit */
> LOAD_HANDLER(r12, machine_check_handle_early)
> 1: mtspr SPRN_SRR0,r12
> @@ -325,7 +326,6 @@ BEGIN_FTR_SECTION
> andc r11,r11,r10 /* Turn off MSR_ME */
> b 1b
> b . /* prevent speculative execution */
> -END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
>
> TRAMP_REAL_BEGIN(machine_check_pSeries)
> .globl machine_check_fwnmi
> @@ -333,7 +333,7 @@ machine_check_fwnmi:
> SET_SCRATCH0(r13) /* save r13 */
> EXCEPTION_PROLOG_0(PACA_EXMC)
> BEGIN_FTR_SECTION
> - b machine_check_pSeries_early
> + b machine_check_common_early
> END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
> machine_check_pSeries_0:
> EXCEPTION_PROLOG_1(PACA_EXMC, KVMTEST_PR, 0x200)
> @@ -346,103 +346,6 @@ machine_check_pSeries_0:
>
> TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
>
> -TRAMP_REAL_BEGIN(machine_check_pSeries_early)
> -BEGIN_FTR_SECTION
> - EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)
> - mr r10,r1 /* Save r1 */
> - lhz r11,PACA_IN_MCE(r13)
> - cmpwi r11,0 /* Are we in nested machine check */
> - bne 0f /* Yes, we are. */
> - /* First machine check entry */
> - ld r1,PACAMCEMERGSP(r13) /* Use MC emergency stack */
> -0: subi r1,r1,INT_FRAME_SIZE /* alloc stack frame */
> - addi r11,r11,1 /* increment paca->in_mce */
> - sth r11,PACA_IN_MCE(r13)
> - /* Limit nested MCE to level 4 to avoid stack overflow */
> - cmpwi r11,MAX_MCE_DEPTH
> - bgt 1f /* Check if we hit limit of 4 */
> - mfspr r11,SPRN_SRR0 /* Save SRR0 */
> - mfspr r12,SPRN_SRR1 /* Save SRR1 */
> - EXCEPTION_PROLOG_COMMON_1()
> - EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
> - EXCEPTION_PROLOG_COMMON_3(0x200)
> - addi r3,r1,STACK_FRAME_OVERHEAD
> - BRANCH_LINK_TO_FAR(machine_check_early) /* Function call ABI */
> - ld r12,_MSR(r1)
> - andi. r11,r12,MSR_PR /* See if coming from user. */
> - bne 2f /* continue in V mode if we are. */
> -
> - /*
> - * At this point we are not sure about what context we come from.
> - * We may be in the middle of swithing stack. r1 may not be valid.
> - * Hence stay on emergency stack, call machine_check_exception and
> - * return from the interrupt.
> - * But before that, check if this is an un-recoverable exception.
> - * If yes, then stay on emergency stack and panic.
> - */
> - andi. r11,r12,MSR_RI
> - beq 1f
> -
> - /*
> - * Check if we have successfully handled/recovered from error, if not
> - * then stay on emergency stack and panic.
> - */
> - cmpdi r3,0 /* see if we handled MCE successfully */
> - beq 1f /* if !handled then panic */
> -
> - /* Stay on emergency stack and return from interrupt. */
> - LOAD_HANDLER(r10,mce_return)
> - mtspr SPRN_SRR0,r10
> - ld r10,PACAKMSR(r13)
> - mtspr SPRN_SRR1,r10
> - RFI_TO_KERNEL
> - b .
> -
> -1: LOAD_HANDLER(r10,unrecover_mce)
> - mtspr SPRN_SRR0,r10
> - ld r10,PACAKMSR(r13)
> - /*
> - * We are going down. But there are chances that we might get hit by
> - * another MCE during panic path and we may run into unstable state
> - * with no way out. Hence, turn ME bit off while going down, so that
> - * when another MCE is hit during panic path, hypervisor will
> - * power cycle the lpar, instead of getting into MCE loop.
> - */
> - li r3,MSR_ME
> - andc r10,r10,r3 /* Turn off MSR_ME */
> - mtspr SPRN_SRR1,r10
> - RFI_TO_KERNEL
> - b .
> -
> - /* Move original SRR0 and SRR1 into the respective regs */
> -2: ld r9,_MSR(r1)
> - mtspr SPRN_SRR1,r9
> - ld r3,_NIP(r1)
> - mtspr SPRN_SRR0,r3
> - ld r9,_CTR(r1)
> - mtctr r9
> - ld r9,_XER(r1)
> - mtxer r9
> - ld r9,_LINK(r1)
> - mtlr r9
> - REST_GPR(0, r1)
> - REST_8GPRS(2, r1)
> - REST_GPR(10, r1)
> - ld r11,_CCR(r1)
> - mtcr r11
> - /* Decrement paca->in_mce. */
> - lhz r12,PACA_IN_MCE(r13)
> - subi r12,r12,1
> - sth r12,PACA_IN_MCE(r13)
> - REST_GPR(11, r1)
> - REST_2GPRS(12, r1)
> - /* restore original r1. */
> - ld r1,GPR1(r1)
> - SET_SCRATCH0(r13) /* save r13 */
> - EXCEPTION_PROLOG_0(PACA_EXMC)
> - b machine_check_pSeries_0
> -END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
> -
> EXC_COMMON_BEGIN(machine_check_common)
> /*
> * Machine check is different because we use a different
> @@ -541,6 +444,9 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
> bl machine_check_early
> std r3,RESULT(r1) /* Save result */
> ld r12,_MSR(r1)
> +BEGIN_FTR_SECTION
> + b 4f
> +END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
>
> #ifdef CONFIG_PPC_P7_NAP
> /*
> @@ -564,10 +470,11 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
> */
> rldicl. r11,r12,4,63 /* See if MC hit while in HV mode. */
> beq 5f
> - andi. r11,r12,MSR_PR /* See if coming from user. */
> +4: andi. r11,r12,MSR_PR /* See if coming from user. */
> bne 9f /* continue in V mode if we are. */
>
> 5:
> +BEGIN_FTR_SECTION
> #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> /*
> * We are coming from kernel context. Check if we are coming from
> @@ -578,6 +485,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
> cmpwi r11,0 /* Check if coming from guest */
> bne 9f /* continue if we are. */
> #endif
> +END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
Put these inside the ifdef?
> /*
> * At this point we are not sure about what context we come from.
> * Queue up the MCE event and return from the interrupt.
> @@ -611,6 +519,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
> cmpdi r3,0 /* see if we handled MCE successfully */
>
> beq 1b /* if !handled then panic */
> +BEGIN_FTR_SECTION
> /*
> * Return from MC interrupt.
> * Queue up the MCE event so that we can log it later, while
> @@ -619,10 +528,24 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
> bl machine_check_queue_event
> MACHINE_CHECK_HANDLER_WINDUP
> RFI_TO_USER_OR_KERNEL
> +FTR_SECTION_ELSE
> + /*
> + * pSeries: Return from MC interrupt. Before that stay on emergency
> + * stack and call machine_check_exception to log the MCE event.
> + */
> + LOAD_HANDLER(r10,mce_return)
> + mtspr SPRN_SRR0,r10
> + ld r10,PACAKMSR(r13)
> + mtspr SPRN_SRR1,r10
> + RFI_TO_KERNEL
> + b .
> +ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
Do you still need mce_return? Why can't you consolidate it as well? ...
Hmm, okay so now I look back at patch 2, I don't think you should call
machine_check_exception there. You're supposed to call
machine_check_queue_event here and it will be handled by irq work.
I think when you do that more of this code should fall out and be
consolidated. Sorry for not picking that up earlier.
Thanks,
Nick
^ permalink raw reply
* Re: [RFC 08/15] x86: PCI: clean up pcibios_scan_root()
From: Rafael J. Wysocki @ 2018-08-20 11:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafael J. Wysocki, Linux PCI, Bjorn Helgaas,
Linux Kernel Mailing List, Christoph Hellwig, Lorenzo Pieralisi,
Benjamin Herrenschmidt, linuxppc-dev, ACPI Devel Maling List
In-Reply-To: <CAK8P3a1KWn0=xwrqZ+sF27O-WE6paDxQPg6PPZFcgCrgXGaX2A@mail.gmail.com>
On Mon, Aug 20, 2018 at 1:17 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Aug 20, 2018 at 10:31 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Fri, Aug 17, 2018 at 12:32 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> > > -static struct pci_bus *pci_scan_root_bus(struct device *parent, int bus,
> > > - struct pci_ops *ops, void *sysdata, struct list_head *resources)
> > > +void pcibios_scan_root(int busnum)
> > > {
> > > + struct pci_sysdata *sd;
> > > struct pci_host_bridge *bridge;
> > > int error;
> > >
> > > - bridge = pci_alloc_host_bridge(0);
> > > - if (!bridge)
> > > - return NULL;
> > > + bridge = pci_alloc_host_bridge(sizeof(sd));
> > > + if (!bridge) {
> > > + printk(KERN_ERR "PCI: OOM, skipping PCI bus %02x\n", busnum);
> > > + return;
> > > + }
> > > + sd = pci_host_bridge_priv(bridge);
> >
> > This looks fishy, as bridge->private is not set at this point AFAICS,
> > unless one of the previous patches changes that.
>
> bridge->private what comes after the bridge structure, and it's allocated
> by pci_alloc_host_bridge() passing the size of the structure we want
> for this private area.
I see, sorry for the noise.
^ permalink raw reply
* Re: [RFC 07/15] PCI/ACPI: clean up acpi_pci_root_create()
From: Rafael J. Wysocki @ 2018-08-20 11:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rafael J. Wysocki, Linux PCI, Bjorn Helgaas,
Linux Kernel Mailing List, Christoph Hellwig, Lorenzo Pieralisi,
Benjamin Herrenschmidt, linuxppc-dev, ACPI Devel Maling List
In-Reply-To: <CAK8P3a31Ds14Ke1qLoMapK1Wq1M4tR6n+nL1VOKzR8+oN0eOBw@mail.gmail.com>
On Mon, Aug 20, 2018 at 1:20 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Aug 20, 2018 at 10:23 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > On Fri, Aug 17, 2018 at 12:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > @@ -909,8 +881,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> > > int ret, busnum = root->secondary.start;
> > > struct acpi_device *device = root->device;
> > > int node = acpi_get_node(device->handle);
> > > - struct pci_bus *bus;
> > > - struct pci_host_bridge *host_bridge;
> > > + struct pci_host_bridge *bridge;
> >
> > Why "bridge" and not "host" or even something to stand for "root complex"?
> >
> > Or maybe it can still be "host_bridge"?
>
> I did this for consistency with the naming in drivers/pci/probe.c,
> which always declares the local variable as 'struct pci_host_bridge *bridge'.
> It's easy to change here if you feel strongly about it (I don't).
I would leave host_bridge here. It would make the patch smaller too I think.
^ permalink raw reply
* Re: [PATCH v8 4/5] powerpc/pseries: Dump the SLB contents on SLB MCE errors.
From: Nicholas Piggin @ 2018-08-20 11:20 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: linuxppc-dev, Aneesh Kumar K.V, Michael Ellerman, Ananth Narayan,
Laurent Dufour, Aneesh Kumar K.V, Michal Suchanek
In-Reply-To: <153469851207.21878.16970346624861719956.stgit@jupiter.in.ibm.com>
On Sun, 19 Aug 2018 22:38:32 +0530
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> If we get a machine check exceptions due to SLB errors then dump the
> current SLB contents which will be very much helpful in debugging the
> root cause of SLB errors. Introduce an exclusive buffer per cpu to hold
> faulty SLB entries. In real mode mce handler saves the old SLB contents
> into this buffer accessible through paca and print it out later in virtual
> mode.
>
> With this patch the console will log SLB contents like below on SLB MCE
> errors:
>
> [ 507.297236] SLB contents of cpu 0x1
> [ 507.297237] Last SLB entry inserted at slot 16
> [ 507.297238] 00 c000000008000000 400ea1b217000500
> [ 507.297239] 1T ESID= c00000 VSID= ea1b217 LLP:100
> [ 507.297240] 01 d000000008000000 400d43642f000510
> [ 507.297242] 1T ESID= d00000 VSID= d43642f LLP:110
> [ 507.297243] 11 f000000008000000 400a86c85f000500
> [ 507.297244] 1T ESID= f00000 VSID= a86c85f LLP:100
> [ 507.297245] 12 00007f0008000000 4008119624000d90
> [ 507.297246] 1T ESID= 7f VSID= 8119624 LLP:110
> [ 507.297247] 13 0000000018000000 00092885f5150d90
> [ 507.297247] 256M ESID= 1 VSID= 92885f5150 LLP:110
> [ 507.297248] 14 0000010008000000 4009e7cb50000d90
> [ 507.297249] 1T ESID= 1 VSID= 9e7cb50 LLP:110
> [ 507.297250] 15 d000000008000000 400d43642f000510
> [ 507.297251] 1T ESID= d00000 VSID= d43642f LLP:110
> [ 507.297252] 16 d000000008000000 400d43642f000510
> [ 507.297253] 1T ESID= d00000 VSID= d43642f LLP:110
> [ 507.297253] ----------------------------------
> [ 507.297254] SLB cache ptr value = 3
> [ 507.297254] Valid SLB cache entries:
> [ 507.297255] 00 EA[0-35]= 7f000
> [ 507.297256] 01 EA[0-35]= 1
> [ 507.297257] 02 EA[0-35]= 1000
> [ 507.297257] Rest of SLB cache entries:
> [ 507.297258] 03 EA[0-35]= 7f000
> [ 507.297258] 04 EA[0-35]= 1
> [ 507.297259] 05 EA[0-35]= 1000
> [ 507.297260] 06 EA[0-35]= 12
> [ 507.297260] 07 EA[0-35]= 7f000
>
> Suggested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> ---
>
> Changes in V8:
> - Limit the slb saving to single level of mce recursion.
Thanks, that looks good now.
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
^ permalink raw reply
* Re: [RFC 07/15] PCI/ACPI: clean up acpi_pci_root_create()
From: Arnd Bergmann @ 2018-08-20 11:19 UTC (permalink / raw)
To: Rafael Wysocki
Cc: linux-pci, Bjorn Helgaas, Linux Kernel Mailing List,
Christoph Hellwig, Lorenzo Pieralisi, Benjamin Herrenschmidt,
linuxppc-dev, ACPI Devel Maling List
In-Reply-To: <CAJZ5v0iCgQxxuoCB9B4-Ho3xeLwb4v99Xyw-9e-tT53mRD+YVQ@mail.gmail.com>
On Mon, Aug 20, 2018 at 10:23 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Aug 17, 2018 at 12:33 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > @@ -909,8 +881,7 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> > int ret, busnum = root->secondary.start;
> > struct acpi_device *device = root->device;
> > int node = acpi_get_node(device->handle);
> > - struct pci_bus *bus;
> > - struct pci_host_bridge *host_bridge;
> > + struct pci_host_bridge *bridge;
>
> Why "bridge" and not "host" or even something to stand for "root complex"?
>
> Or maybe it can still be "host_bridge"?
I did this for consistency with the naming in drivers/pci/probe.c,
which always declares the local variable as 'struct pci_host_bridge *bridge'.
It's easy to change here if you feel strongly about it (I don't).
Arnd
^ permalink raw reply
* Re: [RFC 08/15] x86: PCI: clean up pcibios_scan_root()
From: Arnd Bergmann @ 2018-08-20 11:16 UTC (permalink / raw)
To: Rafael Wysocki
Cc: linux-pci, Bjorn Helgaas, Linux Kernel Mailing List,
Christoph Hellwig, Lorenzo Pieralisi, Benjamin Herrenschmidt,
linuxppc-dev, ACPI Devel Maling List
In-Reply-To: <CAJZ5v0jjZx3xCbPK5vfx-OCRNtMt59WQOxCYkWNj33Js_2Xi=A@mail.gmail.com>
On Mon, Aug 20, 2018 at 10:31 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Aug 17, 2018 at 12:32 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > -static struct pci_bus *pci_scan_root_bus(struct device *parent, int bus,
> > - struct pci_ops *ops, void *sysdata, struct list_head *resources)
> > +void pcibios_scan_root(int busnum)
> > {
> > + struct pci_sysdata *sd;
> > struct pci_host_bridge *bridge;
> > int error;
> >
> > - bridge = pci_alloc_host_bridge(0);
> > - if (!bridge)
> > - return NULL;
> > + bridge = pci_alloc_host_bridge(sizeof(sd));
> > + if (!bridge) {
> > + printk(KERN_ERR "PCI: OOM, skipping PCI bus %02x\n", busnum);
> > + return;
> > + }
> > + sd = pci_host_bridge_priv(bridge);
>
> This looks fishy, as bridge->private is not set at this point AFAICS,
> unless one of the previous patches changes that.
bridge->private what comes after the bridge structure, and it's allocated
by pci_alloc_host_bridge() passing the size of the structure we want
for this private area.
Arnd
^ permalink raw reply
* Re: [PATCH v8 2/5] powerpc/pseries: flush SLB contents on SLB MCE errors.
From: Nicholas Piggin @ 2018-08-20 10:58 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: linuxppc-dev, Michal Suchanek, Ananth Narayan, Laurent Dufour,
Aneesh Kumar K.V, Michael Ellerman
In-Reply-To: <153469849725.21878.4415545320115735468.stgit@jupiter.in.ibm.com>
On Sun, 19 Aug 2018 22:38:17 +0530
Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> On pseries, as of today system crashes if we get a machine check
> exceptions due to SLB errors. These are soft errors and can be fixed by
> flushing the SLBs so the kernel can continue to function instead of
> system crash. We do this in real mode before turning on MMU. Otherwise
> we would run into nested machine checks. This patch now fetches the
> rtas error log in real mode and flushes the SLBs on SLB errors.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
> Signed-off-by: Michal Suchanek <msuchanek@suse.com>
> ---
>
> Changes in V8:
> - Use flush_and_reload_slb() from mce_power.c.
> ---
> arch/powerpc/include/asm/machdep.h | 1
> arch/powerpc/include/asm/mce.h | 3 +
> arch/powerpc/kernel/exceptions-64s.S | 129 ++++++++++++++++++++++++++++++
> arch/powerpc/kernel/mce.c | 15 +++
> arch/powerpc/kernel/mce_power.c | 2
> arch/powerpc/platforms/powernv/setup.c | 11 +++
> arch/powerpc/platforms/pseries/pseries.h | 1
> arch/powerpc/platforms/pseries/ras.c | 54 ++++++++++++-
> arch/powerpc/platforms/pseries/setup.c | 1
> 9 files changed, 212 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
> index a47de82fb8e2..b4831f1338db 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -108,6 +108,7 @@ struct machdep_calls {
>
> /* Early exception handlers called in realmode */
> int (*hmi_exception_early)(struct pt_regs *regs);
> + long (*machine_check_early)(struct pt_regs *regs);
>
> /* Called during machine check exception to retrive fixup address. */
> bool (*mce_check_early_recovery)(struct pt_regs *regs);
> diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
> index 3a1226e9b465..78a1da95a394 100644
> --- a/arch/powerpc/include/asm/mce.h
> +++ b/arch/powerpc/include/asm/mce.h
> @@ -210,4 +210,7 @@ extern void release_mce_event(void);
> extern void machine_check_queue_event(void);
> extern void machine_check_print_event_info(struct machine_check_event *evt,
> bool user_mode);
> +#ifdef CONFIG_PPC_BOOK3S_64
> +extern void flush_and_reload_slb(void);
> +#endif /* CONFIG_PPC_BOOK3S_64 */
> #endif /* __ASM_PPC64_MCE_H__ */
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 285c6465324a..12f056179112 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -332,6 +332,9 @@ TRAMP_REAL_BEGIN(machine_check_pSeries)
> machine_check_fwnmi:
> SET_SCRATCH0(r13) /* save r13 */
> EXCEPTION_PROLOG_0(PACA_EXMC)
> +BEGIN_FTR_SECTION
> + b machine_check_pSeries_early
> +END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
> machine_check_pSeries_0:
> EXCEPTION_PROLOG_1(PACA_EXMC, KVMTEST_PR, 0x200)
> /*
> @@ -343,6 +346,103 @@ machine_check_pSeries_0:
>
> TRAMP_KVM_SKIP(PACA_EXMC, 0x200)
>
> +TRAMP_REAL_BEGIN(machine_check_pSeries_early)
> +BEGIN_FTR_SECTION
> + EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)
> + mr r10,r1 /* Save r1 */
> + lhz r11,PACA_IN_MCE(r13)
> + cmpwi r11,0 /* Are we in nested machine check */
> + bne 0f /* Yes, we are. */
> + /* First machine check entry */
> + ld r1,PACAMCEMERGSP(r13) /* Use MC emergency stack */
> +0: subi r1,r1,INT_FRAME_SIZE /* alloc stack frame */
> + addi r11,r11,1 /* increment paca->in_mce */
> + sth r11,PACA_IN_MCE(r13)
> + /* Limit nested MCE to level 4 to avoid stack overflow */
> + cmpwi r11,MAX_MCE_DEPTH
> + bgt 1f /* Check if we hit limit of 4 */
> + mfspr r11,SPRN_SRR0 /* Save SRR0 */
> + mfspr r12,SPRN_SRR1 /* Save SRR1 */
> + EXCEPTION_PROLOG_COMMON_1()
> + EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
> + EXCEPTION_PROLOG_COMMON_3(0x200)
> + addi r3,r1,STACK_FRAME_OVERHEAD
> + BRANCH_LINK_TO_FAR(machine_check_early) /* Function call ABI */
> + ld r12,_MSR(r1)
> + andi. r11,r12,MSR_PR /* See if coming from user. */
> + bne 2f /* continue in V mode if we are. */
> +
> + /*
> + * At this point we are not sure about what context we come from.
> + * We may be in the middle of swithing stack. r1 may not be valid.
> + * Hence stay on emergency stack, call machine_check_exception and
> + * return from the interrupt.
> + * But before that, check if this is an un-recoverable exception.
> + * If yes, then stay on emergency stack and panic.
> + */
> + andi. r11,r12,MSR_RI
> + beq 1f
> +
> + /*
> + * Check if we have successfully handled/recovered from error, if not
> + * then stay on emergency stack and panic.
> + */
> + cmpdi r3,0 /* see if we handled MCE successfully */
> + beq 1f /* if !handled then panic */
> +
> + /* Stay on emergency stack and return from interrupt. */
> + LOAD_HANDLER(r10,mce_return)
> + mtspr SPRN_SRR0,r10
> + ld r10,PACAKMSR(r13)
> + mtspr SPRN_SRR1,r10
> + RFI_TO_KERNEL
> + b .
> +
> +1: LOAD_HANDLER(r10,unrecover_mce)
> + mtspr SPRN_SRR0,r10
> + ld r10,PACAKMSR(r13)
> + /*
> + * We are going down. But there are chances that we might get hit by
> + * another MCE during panic path and we may run into unstable state
> + * with no way out. Hence, turn ME bit off while going down, so that
> + * when another MCE is hit during panic path, hypervisor will
> + * power cycle the lpar, instead of getting into MCE loop.
> + */
> + li r3,MSR_ME
> + andc r10,r10,r3 /* Turn off MSR_ME */
> + mtspr SPRN_SRR1,r10
> + RFI_TO_KERNEL
> + b .
> +
> + /* Move original SRR0 and SRR1 into the respective regs */
> +2: ld r9,_MSR(r1)
> + mtspr SPRN_SRR1,r9
> + ld r3,_NIP(r1)
> + mtspr SPRN_SRR0,r3
> + ld r9,_CTR(r1)
> + mtctr r9
> + ld r9,_XER(r1)
> + mtxer r9
> + ld r9,_LINK(r1)
> + mtlr r9
> + REST_GPR(0, r1)
> + REST_8GPRS(2, r1)
> + REST_GPR(10, r1)
> + ld r11,_CCR(r1)
> + mtcr r11
> + /* Decrement paca->in_mce. */
> + lhz r12,PACA_IN_MCE(r13)
> + subi r12,r12,1
> + sth r12,PACA_IN_MCE(r13)
> + REST_GPR(11, r1)
> + REST_2GPRS(12, r1)
> + /* restore original r1. */
> + ld r1,GPR1(r1)
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXMC)
> + b machine_check_pSeries_0
> +END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
> +
> EXC_COMMON_BEGIN(machine_check_common)
> /*
> * Machine check is different because we use a different
> @@ -536,6 +636,35 @@ EXC_COMMON_BEGIN(unrecover_mce)
> bl unrecoverable_exception
> b 1b
>
> +EXC_COMMON_BEGIN(mce_return)
> + /* Invoke machine_check_exception to print MCE event and return. */
> + addi r3,r1,STACK_FRAME_OVERHEAD
> + bl machine_check_exception
> + ld r9,_MSR(r1)
> + mtspr SPRN_SRR1,r9
> + ld r3,_NIP(r1)
> + mtspr SPRN_SRR0,r3
> + ld r9,_CTR(r1)
> + mtctr r9
> + ld r9,_XER(r1)
> + mtxer r9
> + ld r9,_LINK(r1)
> + mtlr r9
> + REST_GPR(0, r1)
> + REST_8GPRS(2, r1)
> + REST_GPR(10, r1)
> + ld r11,_CCR(r1)
> + mtcr r11
> + /* Decrement paca->in_mce. */
> + lhz r12,PACA_IN_MCE(r13)
> + subi r12,r12,1
> + sth r12,PACA_IN_MCE(r13)
> + REST_GPR(11, r1)
> + REST_2GPRS(12, r1)
> + /* restore original r1. */
> + ld r1,GPR1(r1)
> + RFI_TO_KERNEL
> + b .
>
> EXC_REAL(data_access, 0x300, 0x80)
> EXC_VIRT(data_access, 0x4300, 0x80, 0x300)
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index efdd16a79075..ae17d8aa60c4 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -488,10 +488,19 @@ long machine_check_early(struct pt_regs *regs)
> {
> long handled = 0;
>
> - __this_cpu_inc(irq_stat.mce_exceptions);
> + /*
> + * For pSeries we count mce when we go into virtual mode machine
> + * check handler. Hence skip it. Also, We can't access per cpu
> + * variables in real mode for LPAR.
> + */
> + if (early_cpu_has_feature(CPU_FTR_HVMODE))
> + __this_cpu_inc(irq_stat.mce_exceptions);
Could this be moved into powernv's virtual mode handler as well, do you
think?
>
> - if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> - handled = cur_cpu_spec->machine_check_early(regs);
> + /*
> + * See if platform is capable of handling machine check.
> + */
> + if (ppc_md.machine_check_early)
> + handled = ppc_md.machine_check_early(regs);
> return handled;
> }
>
> diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
> index 368eb23f27c2..135b0b5a702e 100644
> --- a/arch/powerpc/kernel/mce_power.c
> +++ b/arch/powerpc/kernel/mce_power.c
> @@ -60,7 +60,7 @@ static unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
>
> /* flush SLBs and reload */
> #ifdef CONFIG_PPC_BOOK3S_64
> -static void flush_and_reload_slb(void)
> +void flush_and_reload_slb(void)
> {
> /* Invalidate all SLBs */
> slb_flush_all_realmode();
> diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
> index f96df0a25d05..b74c93bc2e55 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -431,6 +431,16 @@ static unsigned long pnv_get_proc_freq(unsigned int cpu)
> return ret_freq;
> }
>
> +static long pnv_machine_check_early(struct pt_regs *regs)
> +{
> + long handled = 0;
> +
> + if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
> + handled = cur_cpu_spec->machine_check_early(regs);
> +
> + return handled;
> +}
> +
> define_machine(powernv) {
> .name = "PowerNV",
> .probe = pnv_probe,
> @@ -442,6 +452,7 @@ define_machine(powernv) {
> .machine_shutdown = pnv_shutdown,
> .power_save = NULL,
> .calibrate_decr = generic_calibrate_decr,
> + .machine_check_early = pnv_machine_check_early,
> #ifdef CONFIG_KEXEC_CORE
> .kexec_cpu_down = pnv_kexec_cpu_down,
> #endif
> diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
> index 60db2ee511fb..ec2a5f61d4a4 100644
> --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -24,6 +24,7 @@ struct pt_regs;
>
> extern int pSeries_system_reset_exception(struct pt_regs *regs);
> extern int pSeries_machine_check_exception(struct pt_regs *regs);
> +extern long pSeries_machine_check_realmode(struct pt_regs *regs);
>
> #ifdef CONFIG_SMP
> extern void smp_init_pseries(void);
> diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
> index 4a0b201e25aa..73500a24e9c2 100644
> --- a/arch/powerpc/platforms/pseries/ras.c
> +++ b/arch/powerpc/platforms/pseries/ras.c
> @@ -27,6 +27,7 @@
> #include <asm/machdep.h>
> #include <asm/rtas.h>
> #include <asm/firmware.h>
> +#include <asm/mce.h>
>
> #include "pseries.h"
>
> @@ -523,6 +524,37 @@ int pSeries_system_reset_exception(struct pt_regs *regs)
> return 0; /* need to perform reset */
> }
>
> +static int mce_handle_error(struct rtas_error_log *errp)
> +{
> + struct pseries_errorlog *pseries_log;
> + struct pseries_mc_errorlog *mce_log;
> + int disposition = rtas_error_disposition(errp);
> + uint8_t error_type;
> +
> + if (!rtas_error_extended(errp))
> + goto out;
> +
> + pseries_log = get_pseries_errorlog(errp, PSERIES_ELOG_SECT_ID_MCE);
> + if (pseries_log == NULL)
> + goto out;
> +
> + mce_log = (struct pseries_mc_errorlog *)pseries_log->data;
> + error_type = mce_log->error_type;
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
> + if ((disposition == RTAS_DISP_NOT_RECOVERED) &&
> + (error_type == MC_ERROR_TYPE_SLB)) {
> + /* Store the old slb content someplace. */
> + flush_and_reload_slb();
> + disposition = RTAS_DISP_FULLY_RECOVERED;
> + rtas_set_disposition_recovered(errp);
> + }
> +#endif
I suppose this is the right thing to do here, and the hardware or
firmware should upgrade to a UE error if this keeps failing?
For a later patch series, but you could flush the ERAT and recover
ERAT errors here too. TLB would be possible in the guest too when
hypervisor allows tlbie access. For phyp presumably the HV should
take care of flushing the TLB and not pass that down to the guest
(unless there is a guest hypercall to flush the TLB).
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Thanks,
Nick
^ permalink raw reply
* Re: [RFC PATCH 1/5] powerpc/64s/hash: convert SLB miss handlers to C
From: Nicholas Piggin @ 2018-08-20 10:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K . V
In-Reply-To: <20180820094200.13003-2-npiggin@gmail.com>
On Mon, 20 Aug 2018 19:41:56 +1000
Nicholas Piggin <npiggin@gmail.com> wrote:
> +long do_slb_fault(struct pt_regs *regs, unsigned long ea)
> +{
> + unsigned long id = REGION_ID(ea);
> +
> + /* IRQs are not reconciled here, so can't check irqs_disabled */
> + VM_WARN_ON(mfmsr() & MSR_EE);
> +
> + /*
> + * SLB kernel faults must be very careful not to touch anything
> + * that is not bolted. E.g., PACA and global variables are okay,
> + * mm->context stuff is not.
> + *
> + * SLB user faults can access all of kernel memory, but must be
> + * careful not to touch things like IRQ state because it is not
> + * "reconciled" here. The difficulty is that we must use
> + * fast_exception_return to return from kernel SLB faults without
> + * looking at possible non-bolted memory. We could test user vs
> + * kernel faults in the interrupt handler asm and do a full fault,
> + * reconcile, ret_from_except for user faults which would make them
> + * first class kernel code. But for performance it's probably nicer
> + * if they go via fast_exception_return too.
> + */
> + if (id >= KERNEL_REGION_ID) {
> + return slb_allocate_kernel(ea, id);
> + } else {
> + struct mm_struct *mm = current->mm;
> +
> + if (unlikely(!mm))
> + return -EFAULT;
>
> - handle_multi_context_slb_miss(context, ea);
> - exception_exit(prev_state);
> - return;
> + return slb_allocate_user(mm, ea);
> + }
> +}
>
> -slb_bad_addr:
> +void do_bad_slb_fault(struct pt_regs *regs, unsigned long ea, long err)
> +{
> if (user_mode(regs))
> _exception(SIGSEGV, regs, SEGV_BNDERR, ea);
> else
> bad_page_fault(regs, ea, SIGSEGV);
> - exception_exit(prev_state);
> }
I knew I forgot something -- forgot to test MSR[RI] here. That can be
done just by returning a different error from do_slb_fault if RI is
clear, and do_bad_slb_fault will call unrecoverable_exception() if it
sees that code.
Thanks,
Nick
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox