[PATCH] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
This patch adds basic kernel enablement for reading power values, fan
speed rpm and temperature values on powernv platforms which will
be exported to user space through sysfs interface.
Test results:
-
[root@tul163p1 ~]# sensors
ibmpowernv-isa-
Adapter: ISA adapter
fan1:5294 RPM (min =0 RPM)
fan2:4945 RPM (min =0 RPM)
fan3:5831 RPM (min =0 RPM)
fan4:5212 RPM (min =0 RPM)
fan5: 0 RPM (min =0 RPM)
fan6: 0 RPM (min =0 RPM)
fan7:7472 RPM (min =0 RPM)
fan8:7920 RPM (min =0 RPM)
temp1:+39.0°C (high = +0.0°C)
power1: 192.00 W
[root@tul163p1 ~]#
[root@tul163p1 ~]# ls /sys/devices/platform/ibmpowernv.0/
driver fan2_minfan4_minfan6_minfan8_min modalias uevent
fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
fan1_minfan3_minfan5_minfan7_minin2_fault subsystem
fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
[root@tul163p1 ~]#
[root@tul163p1 ~]# ls /sys/class/hwmon/hwmon0/device/
driver fan2_minfan4_minfan6_minfan8_min modalias uevent
fan1_fault fan3_fault fan5_fault fan7_fault hwmon name
fan1_input fan3_input fan5_input fan7_input in1_fault power1_input
fan1_minfan3_minfan5_minfan7_minin2_fault subsystem
fan2_fault fan4_fault fan6_fault fan8_fault in3_fault temp1_input
fan2_input fan4_input fan6_input fan8_input in4_fault temp1_max
[root@tul163p1 ~]#
Signed-off-by: Shivaprasad G Bhat
Signed-off-by: Neelesh Gupta
---
drivers/hwmon/Kconfig |8 +
drivers/hwmon/Makefile |1
drivers/hwmon/ibmpowernv.c | 386
3 files changed, 395 insertions(+)
create mode 100644 drivers/hwmon/ibmpowernv.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index bc196f4..3e308fa 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -554,6 +554,14 @@ config SENSORS_IBMPEX
This driver can also be built as a module. If so, the module
will be called ibmpex.
+config SENSORS_IBMPOWERNV
+ tristate "IBM POWERNV platform sensors"
+ depends on PPC_POWERNV
+ default y
+ help
+ If you say yes here you get support for the temperature/fan/power
+ sensors on your platform.
+
config SENSORS_IIO_HWMON
tristate "Hwmon driver that uses channels specified via iio maps"
depends on IIO
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index c48f987..199c401 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_SENSORS_ULTRA45) += ultra45_env.o
obj-$(CONFIG_SENSORS_I5K_AMB) += i5k_amb.o
obj-$(CONFIG_SENSORS_IBMAEM) += ibmaem.o
obj-$(CONFIG_SENSORS_IBMPEX) += ibmpex.o
+obj-$(CONFIG_SENSORS_IBMPOWERNV)+= ibmpowernv.o
obj-$(CONFIG_SENSORS_IIO_HWMON) += iio_hwmon.o
obj-$(CONFIG_SENSORS_INA209) += ina209.o
obj-$(CONFIG_SENSORS_INA2XX) += ina2xx.o
diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
new file mode 100644
index 000..e5cffce
--- /dev/null
+++ b/drivers/hwmon/ibmpowernv.c
@@ -0,0 +1,386 @@
+/*
+ * IBM PowerNV platform sensors for temperature/fan/power
+ * Copyright (C) 2014 IBM
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define DRVNAME"ibmpowernv"
+#define MAX_ATTR_LEN 32
+
+/* Sensor suffix name from DT */
+#define DT_FAULT_ATTR_SUFFIX "faulted"
+#define DT_DATA_ATTR_SUFFIX"data"
+#define DT_THRESHOLD_ATTR_SUFFIX "thrs"
+
+/* Enumerates all the sensors in the POWERNV platform and also index into
+ * 'struct sensor_name'
+ */
+enum sensors {
+ FAN,
+ AMBIENT_TEMP,
+ POWERSUPPLY,
+ POWER,
+ MAX_SENSOR_TYPE,
+};
+
+static struct sensor_name {
+ char *name;
+ char *compatible;
+} sensor_names[] = {
+ {"fan", "ibm,opal-sensor-cooling-fan"},
+ {"temp", "ibm,opal-sensor-amb-temp"},
+ {"in",
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 10:16:51PM -0700, Guenter Roeck wrote: > any idea what might cause this one, by any chance ? > > arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': > (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against > symbol `interrupt_base_book3e' defined in .text section in > arch/powerpc/kernel/built-in.o > arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': > (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against > symbol `interrupt_end_book3e' defined in .text section in > arch/powerpc/kernel/built-in.o > arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': > > I see this if I try to build powerpc:ppc64e_defconfig or > powerpc:chroma_defconfig > with gcc 4.8.2 and binutils 2.24. Blame me. I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/13/2014 10:51 PM, Pedro Alves wrote: > I wonder whether people are getting Roland's address from? > > It's frequent that ptrace related patches end up CCed to > rol...@redhat.com, but, he's not been at Red Hat for a few years > now. Roland, do you still want to be CCed on ptrace-related > issues? If so, there's probably a script somewhere in the > kernel that needs updating. If not, well, it'd be good > if it were updated anyway. :-) > > It's a little annoying, as Red Hat's servers outright reject > email sent from a @redhat.com address if one tries to send > an email that includes a CC/FROM to a user that no longer > exists in the @redhat.com domain. Got the email address from some of the previous ptrace related commits. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/13/2014 10:43 PM, Pedro Alves wrote: > On 05/05/14 08:54, Anshuman Khandual wrote: >> This patch enables get and set of transactional memory related register >> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing >> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR, >> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new >> ELF core note types added previously in this regard. >> >> (1) NT_PPC_TM_SPR >> (2) NT_PPC_TM_CGPR >> (3) NT_PPC_TM_CFPR >> (4) NT_PPC_TM_CVMX > > Sorry that I couldn't tell this from the code, but, what does the > kernel return when the ptracer requests these registers and the > program is not in a transaction? Specifically I'm wondering whether > this follows the same semantics as the s390 port. > Right now, it still returns the saved state of the registers from thread struct. I had assumed that the user must know the state of the transaction before initiating the ptrace request. I guess its better to check for the transaction status before processing the request. In case if TM is not active on that thread, we should return -EINVAL. I am not familiar with the s390 side of code. But if we look at the s390_tdb_get function it checks for (regs->int_code & 0x200) before processing the request. Not sure what 0x200 signifies though. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Wed, May 14, 2014 at 01:34:34PM +1000, Stephen Rothwell wrote: > OK, this appears to be an assembler bug. Agreed. Upgrade binutils! > $ cat test.s > .text > x: > .pushsectionb, "a" > beq y > .popsection > .=0x8 > y: > $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version > GNU assembler (GNU Binutils) 2.22 > This assembler was configured for a target of `powerpc64-linux'. > $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o > test.o test.s > test.s: Assembler messages: > test.s:4: Error: operand out of range (0x0008 is not between > 0x8000 and 0x7ffc) > $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version > GNU assembler (GNU Binutils) 2.23.52.20130512 > This assembler was configured for a target of `powerpc64-linux'. > $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o > test.o test.s > (no error) > > Alan, can you shed light on when it was fixed? 2012-11-05 https://sourceware.org/ml/binutils/2012-11/msg00043.html git show 3b8b57a9495016b2b02fbc2612dd1607d4b6f9ba The part that actually fixes this problem is "Leave insn field zero...". -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a couple of fixes for 3.15. One from Anton fixes a nasty regression I introduced when trying to fix a loss of irq_work whose consequences is that we can completely lose timer interrupts on a CPU... not pretty. The other one is a change to our PCIe reset hook to use a firmware call instead of direct config space accesses to trigger a fundamental reset on the root port. This is necessary so that the FW gets a chance to disable the link down error monitoring, which would otherwise trip and cause subsequent fatal EEH error. Cheers, Ben. The following changes since commit e4565362c7adc31201135c4b6d649fc1bdc3bf20: powerpc/4xx: Fix section mismatch in ppc4xx_pci.c (2014-04-28 16:32:53 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 8050936caf125fbe54111ba5e696b68a360556ba: powerpc: irq work racing with timer interrupt can result in timer interrupt hang (2014-05-12 14:29:28 +1000) Anton Blanchard (1): powerpc: irq work racing with timer interrupt can result in timer interrupt hang Gavin Shan (1): powerpc/powernv: Reset root port in firmware arch/powerpc/kernel/time.c| 3 --- arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++- 2 files changed, 2 insertions(+), 4 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/13/2014 08:34 PM, Stephen Rothwell wrote: Hi Guenter, On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck wrote: On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. It works for me with gcc 4.8.2 (build from yocto 1.6.0). Is asking people to use gcc 4.7.3 or later acceptable ? OK, this appears to be an assembler bug. $ cat test.s .text x: .pushsectionb, "a" beq y .popsection .=0x8 y: $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.22 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s test.s: Assembler messages: test.s:4: Error: operand out of range (0x0008 is not between 0x8000 and 0x7ffc) $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.23.52.20130512 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s (no error) Alan, can you shed light on when it was fixed? Hi Stephen, any idea what might cause this one, by any chance ? arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': I see this if I try to build powerpc:ppc64e_defconfig or powerpc:chroma_defconfig with gcc 4.8.2 and binutils 2.24. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/8] powerpc/powernv: Implement ppc_call_opal()
If we're running PowerNV platform, ppc_firmware() will be directed
to ppc_call_opal() where we can call to OPAL API accordingly. In
ppc_call_opal(), the input argument are parsed out and call to
appropriate OPAL API to handle that. Each request passed to the
function is identified with token. As we get to the function either
from host owned application (e.g. errinjct) or VM, we always have
the first parameter (so-called "virtual") to differentiate the
cases.
The patch implements above logic and OPAL call handler dynamica
registeration mechanism so that the handlers could be distributed.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/opal.h | 3 +-
arch/powerpc/platforms/powernv/opal.c | 90 ++-
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index ca55d9c..7c4ffd0 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -997,7 +997,8 @@ extern void opal_lpc_init(void);
struct opal_sg_list *opal_vmalloc_to_sg_list(void *vmalloc_addr,
unsigned long vmalloc_size);
void opal_free_sg_list(struct opal_sg_list *sg);
-
+int opal_call_handler_register(bool virt, int token,
+ int (*fn)(struct rtas_args *));
#endif /* __ASSEMBLY__ */
#endif /* __OPAL_H */
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv/opal.c
index ad33c2b..c84823c 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -38,6 +38,13 @@ struct opal {
u64 size;
} opal;
+struct opal_call_handler {
+ bool virt;
+ int token;
+ int (*fn)(struct rtas_args *args);
+ struct list_head list;
+};
+
struct mcheck_recoverable_range {
u64 start_addr;
u64 end_addr;
@@ -47,6 +54,10 @@ struct mcheck_recoverable_range {
static struct mcheck_recoverable_range *mc_recoverable_range;
static int mc_recoverable_range_len;
+/* OPAL call handler */
+static LIST_HEAD(opal_call_handler_list);
+static DEFINE_SPINLOCK(opal_call_lock);
+
struct device_node *opal_node;
static DEFINE_SPINLOCK(opal_write_lock);
extern u64 opal_mc_secondary_handler[];
@@ -703,8 +714,83 @@ void opal_free_sg_list(struct opal_sg_list *sg)
}
}
-/* Extend it later */
-int ppc_call_opal(struct rtas_args *args)
+int opal_call_handler_register(bool virt, int token,
+ int (*fn)(struct rtas_args *))
{
+ struct opal_call_handler *h, *handler;
+
+ if (!token || !fn) {
+ pr_warn("%s: Invalid parameters\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ handler = kzalloc(sizeof(*handler), GFP_KERNEL);
+ if (!handler) {
+ pr_warn("%s: Out of memory\n",
+ __func__);
+ return -ENOMEM;
+ }
+ handler->token = token;
+ handler->virt = virt;
+ handler->fn = fn;
+ INIT_LIST_HEAD(&handler->list);
+
+ spin_lock(&opal_call_lock);
+ list_for_each_entry(h, &opal_call_handler_list, list) {
+ if (h->token == token &&
+ h->virt == virt) {
+ spin_unlock(&opal_call_lock);
+ pr_warn("%s: Handler existing (%s, %x)\n",
+ __func__, virt ? "T" : "F", token);
+ kfree(handler);
+ return -EEXIST;
+ }
+ }
+
+ list_add_tail(&handler->list, &opal_call_handler_list);
+ spin_unlock(&opal_call_lock);
+
return 0;
}
+
+/*
+ * It's usually invoked from syscall ppc_firmware() by host
+ * owned application or VM. The information carried in the
+ * input arguments is different. So we always have the first
+ * argument to differentiate it.
+ *
+ * Also, we have to extend 32-bits address to 64-bits. So
+ * for each address sensitive field, it will require 8
+ * bytes.
+ */
+int ppc_call_opal(struct rtas_args *args)
+{
+ bool virt, found;
+ int token;
+ struct opal_call_handler *h;
+
+ /* We should have "virt" at least */
+ if (args->nargs < 1)
+ return -EINVAL;
+ virt = !!args->args[0];
+ token = args->token;
+
+ /* Do we have handler ? */
+ found = false;
+ spin_lock(&opal_call_lock);
+ list_for_each_entry(h, &opal_call_handler_list, list) {
+ if (h->token == token &&
+ h->virt == virt) {
+ found = true;
+ break;
+ }
+ }
+ spin_unlock(&opal_call_lock);
+
+ /* Call to handler */
+ if (!found)
+ return -ERANGE;
+
+ return h->fn(args);
+}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listin
[PATCH 4/8] powerpc/eeh: Avoid event on passed PE
If we detects frozen state on PE that has been passed to guest, we
needn't handle it. Instead, we rely on the guest to detect and recover
it. The patch avoid EEH event on the frozen passed PE so that the guest
can have chance to handle that.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 8
arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 9c6b899..6543f05 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -400,6 +400,14 @@ int eeh_dev_check_failure(struct eeh_dev *edev)
if (ret > 0)
return ret;
+ /*
+* If the PE has been passed to guest, we won't check the
+* state. Instead, let the guest handle it if the PE has
+* been frozen.
+*/
+ if (eeh_pe_passed(pe))
+ return 0;
+
/* If we already have a pending isolation event for this
* slot, we know it's bad already, we don't need to check.
* Do this checking under a lock; as multiple PCI devices
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 1b5982f..03a3ed2 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -890,7 +890,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
opal_pci_eeh_freeze_clear(phb->opal_id,
frozen_pe_no,
OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
ret = EEH_NEXT_ERR_NONE;
- } else if ((*pe)->state & EEH_PE_ISOLATED) {
+ } else if ((*pe)->state & EEH_PE_ISOLATED ||
+ eeh_pe_passed(*pe)) {
ret = EEH_NEXT_ERR_NONE;
} else {
pr_err("EEH: Frozen PHB#%x-PE#%x (%s)
detected\n",
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/8] powerpc: Extend syscall ppc_rtas()
Originally, syscall ppc_rtas() can be used to invoke RTAS call from
user space. Utility "errinjct" is using it to inject various errors
to the system for testing purpose. The patch intends to extend the
syscall to support both pSeries and PowerNV platform. With that,
RTAS and OPAL call can be invoked from user space. In turn, utility
"errinjct" can be supported on pSeries and PowerNV platform at same
time.
The original syscall handler ppc_rtas() is renamed to ppc_firmware(),
which calls ppc_call_rtas() or ppc_call_opal() depending on the
running platform. The data transported between userland and kerenl is
by "struct rtas_args". It's platform specific on how to use the data.
Signed-off-by: Mike Qiu
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/rtas.h| 10 +-
arch/powerpc/include/asm/syscalls.h| 2 +-
arch/powerpc/include/asm/systbl.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 2 +-
arch/powerpc/kernel/rtas.c | 57 +++---
arch/powerpc/kernel/syscalls.c | 50 +
arch/powerpc/platforms/powernv/opal.c | 7 +
kernel/sys_ni.c| 2 +-
8 files changed, 82 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index b390f55..3428524 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -20,7 +20,7 @@
#define RTAS_UNKNOWN_SERVICE (-1)
#define RTAS_INSTANTIATE_MAX (1ULL<<30) /* Don't instantiate rtas at/above
this value */
-/* Buffer size for ppc_rtas system call. */
+/* Buffer size for ppc_firmware system call. */
#define RTAS_RMOBUF_MAX (64 * 1024)
/* RTAS return status codes */
@@ -427,9 +427,17 @@ static inline int page_is_rtas_user_buf(unsigned long pfn)
/* Not the best place to put pSeries_coalesce_init, will be fixed when we
* move some of the rtas suspend-me stuff to pseries */
extern void pSeries_coalesce_init(void);
+extern int ppc_call_rtas(struct rtas_args *args);
#else
static inline int page_is_rtas_user_buf(unsigned long pfn) { return 0;}
static inline void pSeries_coalesce_init(void) { }
+static inline int ppc_call_rtas(struct rtas_args *args) { return -ENXIO; }
+#endif
+
+#ifdef CONFIG_PPC_POWERNV
+extern int ppc_call_opal(struct rtas_args *args);
+#else
+static inline int ppc_call_opal(struct rtas_arts *args) { return -ENXIO; }
#endif
extern int call_rtas(const char *, int, int, unsigned long *, ...);
diff --git a/arch/powerpc/include/asm/syscalls.h
b/arch/powerpc/include/asm/syscalls.h
index 23be8f1..3383e50 100644
--- a/arch/powerpc/include/asm/syscalls.h
+++ b/arch/powerpc/include/asm/syscalls.h
@@ -15,7 +15,7 @@ asmlinkage unsigned long sys_mmap2(unsigned long addr, size_t
len,
unsigned long prot, unsigned long flags,
unsigned long fd, unsigned long pgoff);
asmlinkage long ppc64_personality(unsigned long personality);
-asmlinkage int ppc_rtas(struct rtas_args __user *uargs);
+asmlinkage int ppc_firmware(struct rtas_args __user *uargs);
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_SYSCALLS_H */
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index 3ddf702..00f8bb2 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -259,7 +259,7 @@ COMPAT_SYS_SPU(utimes)
COMPAT_SYS_SPU(statfs64)
COMPAT_SYS_SPU(fstatfs64)
SYSX(sys_ni_syscall, ppc_fadvise64_64, ppc_fadvise64_64)
-PPC_SYS_SPU(rtas)
+PPC_SYS_SPU(firmware)
OLDSYS(debug_setcontext)
SYSCALL(ni_syscall)
COMPAT_SYS(migrate_pages)
diff --git a/arch/powerpc/include/uapi/asm/unistd.h
b/arch/powerpc/include/uapi/asm/unistd.h
index 881bf2e..3aee765 100644
--- a/arch/powerpc/include/uapi/asm/unistd.h
+++ b/arch/powerpc/include/uapi/asm/unistd.h
@@ -273,7 +273,7 @@
#ifndef __powerpc64__
#define __NR_fadvise64_64 254
#endif
-#define __NR_rtas 255
+#define __NR_firmware 255
#define __NR_sys_debug_setcontext 256
/* Number 257 is reserved for vserver */
#define __NR_migrate_pages 258
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 8cd5ed0..5d829a72 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1017,59 +1017,32 @@ struct pseries_errorlog *get_pseries_errorlog(struct
rtas_error_log *log,
}
/* We assume to be passed big endian arguments */
-asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
+int ppc_call_rtas(struct rtas_args *args)
{
- struct rtas_args args;
unsigned long flags;
char *buff_copy, *errbuf = NULL;
- int nargs, nret, token;
int rc;
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
-
- if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
- return -EFAULT;
-
- nargs = be32_to_cpu(args.nargs);
- nret = be32_to_cpu(args.nret);
- token = be32_to_cpu(args.token);
-
- if (nargs > ARRA
[PATCH 3/8] drivers/vfio: New IOCTL command VFIO_EEH_INFO
The patch adds new IOCTL command VFIO_EEH_INFO to VFIO container
to support EEH functionality for PCI devices, which have been
passed from host to guest via VFIO.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/Makefile | 1 +
arch/powerpc/platforms/powernv/eeh-vfio.c | 593 ++
drivers/vfio/vfio_iommu_spapr_tce.c | 12 +
include/uapi/linux/vfio.h | 57 +++
4 files changed, 663 insertions(+)
create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 63cebb9..2b15a03 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -6,5 +6,6 @@ obj-y += opal-msglog.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o
+obj-$(CONFIG_VFIO_EEH) += eeh-vfio.o
obj-$(CONFIG_PPC_SCOM) += opal-xscom.o
obj-$(CONFIG_MEMORY_FAILURE) += opal-memory-errors.o
diff --git a/arch/powerpc/platforms/powernv/eeh-vfio.c
b/arch/powerpc/platforms/powernv/eeh-vfio.c
new file mode 100644
index 000..69d5f2d
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/eeh-vfio.c
@@ -0,0 +1,593 @@
+/*
+ * The file intends to support EEH funtionality for those PCI devices,
+ * which have been passed through from host to guest via VFIO. So this
+ * file is naturally part of VFIO implementation on PowerNV platform.
+ *
+ * Copyright Benjamin Herrenschmidt & Gavin Shan, IBM Corporation 2014.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "powernv.h"
+#include "pci.h"
+
+static int powernv_eeh_vfio_map(struct vfio_eeh_info *info)
+{
+ struct pci_bus *bus, *pe_bus;
+ struct pci_dev *pdev;
+ struct eeh_dev *edev;
+ struct eeh_pe *pe;
+ int domain, bus_no, devfn;
+
+ /* Host address */
+ domain = info->map.host_domain;
+ bus_no = (info->map.host_cfg_addr >> 8) & 0xff;
+ devfn = info->map.host_cfg_addr & 0xff;
+
+ /* Find PCI bus */
+ bus = pci_find_bus(domain, bus_no);
+ if (!bus) {
+ pr_warn("%s: PCI bus %04x:%02x not found\n",
+ __func__, domain, bus_no);
+ return -ENODEV;
+ }
+
+ /* Find PCI device */
+ pdev = pci_get_slot(bus, devfn);
+ if (!pdev) {
+ pr_warn("%s: PCI device %04x:%02x:%02x.%01x not found\n",
+ __func__, domain, bus_no,
+ PCI_SLOT(devfn), PCI_FUNC(devfn));
+ return -ENODEV;
+ }
+
+ /* No EEH device - almost impossible */
+ edev = pci_dev_to_eeh_dev(pdev);
+ if (unlikely(!edev)) {
+ pci_dev_put(pdev);
+ pr_warn("%s: No EEH dev for PCI device %s\n",
+ __func__, pci_name(pdev));
+ return -ENODEV;
+ }
+
+ /* Doesn't support PE migration between different PHBs */
+ pe = edev->pe;
+ if (!eeh_pe_passed(pe)) {
+ pe_bus = eeh_pe_bus_get(pe);
+ BUG_ON(!pe_bus);
+
+ /* PE# has format 00BBSS00 */
+ pe->guest_addr.buid= info->map.guest_buid;
+ pe->guest_addr.pe_addr = pe_bus->number << 16;
+ eeh_pe_set_passed(pe, true);
+ } else if (pe->guest_addr.buid != info->map.guest_buid) {
+ pci_dev_put(pdev);
+ pr_warn("%s: Mismatched PHB BUID (0x%llx, 0x%llx)\n",
+ __func__, pe->guest_addr.buid, info->map.guest_buid);
+ return -EINVAL;
+ }
+
+ edev->guest_addr.buid = info->map.guest_buid;
+ edev->guest_addr.config_addr = info->map.guest_cfg_addr;
+ eeh_dev_set_passed(edev, true);
+
+ pr_debug("EEH: Host PCI dev %s to %llx-%02x:%02x.%01x\n",
+pci_name(pdev), info->map.guest_buid,
+(info->map.guest_cfg_addr >> 8) & 0xFF,
+PCI_SLOT(info->map.guest_cfg_addr & 0xFF),
+PCI_FUNC(info->map.guest_cfg_addr & 0xFF));
+
+ pci_dev_put(pdev);
+ return 0;
+}
+
+static int powernv_eeh_vfio_unmap(struct vfio_eeh_info *info)
+{
+ struct eeh_vfio_pci_addr addr;
+ struct pci_dev *pdev;
+ struct eeh_dev *edev, *tmp;
+ struct eeh_pe *pe;
+ bool passed;
+
+ /* Get EEH device */
+ addr.buid = info->unmap.buid;
+ addr.config_addr = info->unmap.cfg_addr;
+ edev = eeh_vfio_dev
[PATCH 8/8] powerpc/powernv: Error injection infrastructure
The patch intends to implement the error injection infrastructure
for PowerNV platform. The predetermined handlers will be called
according to the type of injected error (e.g. OpalErrinjctTypeIoaBusError).
For now, we just support PCI error injection. We need support
injecting other types of errors in future.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/opal.h| 6 +
arch/powerpc/platforms/powernv/Makefile| 2 +-
arch/powerpc/platforms/powernv/errinject.c | 224 +
3 files changed, 231 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/powernv/errinject.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7c4ffd0..7bf86ba 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -794,6 +794,12 @@ typedef struct oppanel_line {
uint64_tline_len;
} oppanel_line_t;
+enum OpalCallToken{
+ OPAL_CALL_TOKEN_MIN = 0,
+ OPAL_CALL_TOKEN_ERRINJCT,
+ OPAL_CALL_TOKEN_MAX
+};
+
/* /sys/firmware/opal */
extern struct kobject *opal_kobj;
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 2b15a03..5ae8257 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y += setup.o opal-takeover.o opal-wrappers.o opal.o
opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o
opal-sensor.o
-obj-y += opal-msglog.o
+obj-y += opal-msglog.o errinject.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/errinject.c
b/arch/powerpc/platforms/powernv/errinject.c
new file mode 100644
index 000..aa892d4
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/errinject.c
@@ -0,0 +1,224 @@
+/*
+ * The file intends to support error injection requests from host OS
+ * owned utility (e.g. errinjct) or VM. We need parse the information
+ * passed from user space and call to appropriate OPAL API accordingly.
+ *
+ * Copyright Benjamin Herrenschmidt & Gavin Shan, IBM Corporation 2014.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "powernv.h"
+#include "pci.h"
+
+static int powernv_errinjct_ioa(struct rtas_args *args)
+{
+ return -ENXIO;
+}
+
+static int powernv_errinjct_ioa64(struct rtas_args *args)
+{
+ return -ENXIO;
+}
+
+#ifdef CONFIG_VFIO_EEH
+static int powernv_errinjct_ioa_virt(struct rtas_args *args)
+{
+ uint32_t addr, mask, cfg_addr;
+ uint32_t buid_hi, buid_lo, op;
+ uint64_t buf_addr = ((uint64_t)(args->args[3])) << 32 |
+ args->args[4];
+ void __user *buf = (void __user *)buf_addr;
+ struct eeh_vfio_pci_addr vfio_addr;
+ struct pnv_phb *phb;
+ struct eeh_pe *pe;
+ struct OpalErrinjct ej;
+
+ /* Extract parameters */
+ if (get_user(addr, (uint32_t __user *)buf) ||
+ get_user(mask, (uint32_t __user *)(buf + 4)) ||
+ get_user(cfg_addr, (uint32_t __user *)(buf + 8)) ||
+ get_user(buid_hi, (uint32_t __user *)(buf + 12)) ||
+ get_user(buid_lo, (uint32_t __user *)(buf + 16)) ||
+ get_user(op, (uint32_t __user *)(buf + 20)))
+ return -EFAULT;
+
+ /* Check opcode */
+ if (op < OpalEjtIoaLoadMemAddr ||
+ op > OpalEjtIoaDmaWriteMemTarget)
+ return -EINVAL;
+
+ /* Find PE */
+ vfio_addr.buid = uint64_t)buid_hi) << 32) | buid_lo);
+ vfio_addr.pe_addr = cfg_addr;
+ pe = eeh_vfio_pe_get(&vfio_addr);
+ if (!pe)
+ return -ENODEV;
+ phb = pe->phb->private_data;
+
+ /* OPAL call */
+ ej.type = OpalErrinjctTypeIoaBusError;
+ ej.ioa.addr = addr;
+ ej.ioa.mask = mask;
+ ej.ioa.phb_id = phb->opal_id;
+ ej.ioa.pe = pe->addr;
+ ej.ioa.function = op;
+ if (opal_err_injct(&ej) != OPAL_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int powernv_errinjct_ioa64_virt(struct rtas_args *args)
+{
+ uint32_t addr_hi, addr_lo, mask_hi, mask_lo;
+ uint32_t cfg_addr, buid_hi, buid_lo, op;
+ uint64_t buf_addr = ((uint64_t)(args->args[3])) << 32 |
+ args->args[4];
+ void __user *buf = (void __user *)buf_addr;
+ struct eeh_vfio_pci_addr vfio_addr;
+ struct
[PATCH 5/8] powerpc/powernv: Sync OPAL header file with firmware
The patch synchronizes OPAL header file with firmware so that the
host kernel can make OPAL call to do error injection.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/opal.h| 65 ++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
2 files changed, 66 insertions(+)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 66ad7a7..ca55d9c 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -175,6 +175,7 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_SET_PARAM 90
#define OPAL_DUMP_RESEND 91
#define OPAL_DUMP_INFO294
+#define OPAL_ERR_INJECT96
#ifndef __ASSEMBLY__
@@ -219,6 +220,69 @@ enum OpalPciErrorSeverity {
OPAL_EEH_SEV_INF= 5
};
+enum OpalErrinjctType {
+ OpalErrinjctTypeFirst = 0,
+ OpalErrinjctTypeFatal = 1,
+ OpalErrinjctTypeRecoverRandomEvent = 2,
+ OpalErrinjctTypeRecoverSpecialEvent = 3,
+ OpalErrinjctTypeCorruptedPage = 4,
+ OpalErrinjctTypeCorruptedSlb= 5,
+ OpalErrinjctTypeTranslatorFailure = 6,
+ OpalErrinjctTypeIoaBusError = 7,
+ OpalErrinjctTypeIoaBusError64 = 8,
+ OpalErrinjctTypePlatformSpecific= 9,
+ OpalErrinjctTypeDcacheStart = 10,
+ OpalErrinjctTypeDcacheEnd = 11,
+ OpalErrinjctTypeIcacheStart = 12,
+ OpalErrinjctTypeIcacheEnd = 13,
+ OpalErrinjctTypeTlbStart= 14,
+ OpalErrinjctTypeTlbEnd = 15,
+ OpalErrinjctTypeUpstreamIoError = 16,
+ OpalErrinjctTypeLast= 17,
+
+ /* IoaBusError & IoaBusError64 */
+ OpalEjtIoaLoadMemAddr = 0,
+ OpalEjtIoaLoadMemData = 1,
+ OpalEjtIoaLoadIoAddr= 2,
+ OpalEjtIoaLoadIoData= 3,
+ OpalEjtIoaLoadConfigAddr= 4,
+ OpalEjtIoaLoadConfigData= 5,
+ OpalEjtIoaStoreMemAddr = 6,
+ OpalEjtIoaStoreMemData = 7,
+ OpalEjtIoaStoreIoAddr = 8,
+ OpalEjtIoaStoreIoData = 9,
+ OpalEjtIoaStoreConfigAddr = 10,
+ OpalEjtIoaStoreConfigData = 11,
+ OpalEjtIoaDmaReadMemAddr= 12,
+ OpalEjtIoaDmaReadMemData= 13,
+ OpalEjtIoaDmaReadMemMaster = 14,
+ OpalEjtIoaDmaReadMemTarget = 15,
+ OpalEjtIoaDmaWriteMemAddr = 16,
+ OpalEjtIoaDmaWriteMemData = 17,
+ OpalEjtIoaDmaWriteMemMaster = 18,
+ OpalEjtIoaDmaWriteMemTarget = 19,
+};
+
+struct OpalErrinjct {
+ int32_t type;
+ union {
+ struct {
+ uint32_t addr;
+ uint32_t mask;
+ uint64_t phb_id;
+ uint32_t pe;
+ uint32_t function;
+ }ioa;
+ struct {
+ uint64_t addr;
+ uint64_t mask;
+ uint64_t phb_id;
+ uint32_t pe;
+ uint32_t function;
+ }ioa64;
+ };
+};
+
enum OpalShpcAction {
OPAL_SHPC_GET_LINK_STATE = 0,
OPAL_SHPC_GET_SLOT_STATE = 1
@@ -839,6 +903,7 @@ int64_t opal_pci_get_phb_diag_data(uint64_t phb_id, void
*diag_buffer,
uint64_t diag_buffer_len);
int64_t opal_pci_get_phb_diag_data2(uint64_t phb_id, void *diag_buffer,
uint64_t diag_buffer_len);
+int64_t opal_err_injct(void *data);
int64_t opal_pci_fence_phb(uint64_t phb_id);
int64_t opal_pci_reinit(uint64_t phb_id, uint64_t reinit_scope, uint64_t data);
int64_t opal_pci_mask_pe_error(uint64_t phb_id, uint16_t pe_number, uint8_t
error_type, uint8_t mask_action);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index f531ffe..46265de 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -119,6 +119,7 @@ OPAL_CALL(opal_pci_next_error,
OPAL_PCI_NEXT_ERROR);
OPAL_CALL(opal_pci_poll, OPAL_PCI_POLL);
OPAL_CALL(opal_pci_msi_eoi,OPAL_PCI_MSI_EOI);
OPAL_CALL(opal_pci_get_phb_diag_data2, OPAL_PCI_GET_PHB_DIAG_DATA2);
+OPAL_CALL(opal_err_injct, OPAL_ERR_INJECT);
OPAL_CALL(opal_xscom_read, OPAL_XSCOM_READ);
OPAL_CALL(opal_xscom_write,OPAL_XSCOM
[PATCH 2/8] powerpc/eeh: Info to trace passed devices
The address of passed PCI devices (domain:bus:slot:func) might be
quite different from the perspective of host and guest. We have to
trace the address mapping so that we can emulate EEH RTAS requests
from guest. The patch introduces additional fields to eeh_pe and
eeh_dev for the purpose.
Also, the patch adds function eeh_vfio_pe_get() and eeh_vfio_dev_get()
to search EEH PE or device according to the given guest address. Both
of them will be used by subsequent patches.
Signed-off-by: Gavin Shan
---
arch/powerpc/include/asm/eeh.h | 52 +++
arch/powerpc/kernel/eeh_pe.c | 80 ++
2 files changed, 132 insertions(+)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 7782056..96dabfc 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -48,6 +48,14 @@ struct device_node;
#define EEH_PE_RST_HOLD_TIME 250
#define EEH_PE_RST_SETTLE_TIME 1800
+#ifdef CONFIG_VFIO_EEH
+struct eeh_vfio_pci_addr {
+ uint64_tbuid; /* PHB BUID */
+ uint16_tconfig_addr;/* Bus/Device/Function number */
+ uint32_tpe_addr;/* PE configuration address */
+};
+#endif /* CONFIG_VFIO_EEH */
+
/*
* The struct is used to trace PE related EEH functionality.
* In theory, there will have one instance of the struct to
@@ -72,6 +80,7 @@ struct device_node;
#define EEH_PE_RESET (1 << 2)/* PE reset in progress */
#define EEH_PE_KEEP(1 << 8)/* Keep PE on hotplug */
+#define EEH_PE_PASSTHROUGH (1 << 9)/* PE owned by guest*/
struct eeh_pe {
int type; /* PE type: PHB/Bus/Device */
@@ -85,6 +94,9 @@ struct eeh_pe {
struct timeval tstamp; /* Time on first-time freeze*/
int false_positives;/* Times of reported #ff's */
struct eeh_pe *parent; /* Parent PE*/
+#ifdef CONFIG_VFIO_EEH
+ struct eeh_vfio_pci_addr guest_addr;
+#endif
struct list_head child_list;/* Link PE to the child list*/
struct list_head edevs; /* Link list of EEH devices */
struct list_head child; /* Child PEs*/
@@ -93,6 +105,21 @@ struct eeh_pe {
#define eeh_pe_for_each_dev(pe, edev, tmp) \
list_for_each_entry_safe(edev, tmp, &pe->edevs, list)
+static inline bool eeh_pe_passed(struct eeh_pe *pe)
+{
+ return pe ? !!(pe->state & EEH_PE_PASSTHROUGH) : false;
+}
+
+static inline void eeh_pe_set_passed(struct eeh_pe *pe, bool passed)
+{
+ if (pe) {
+ if (passed)
+ pe->state |= EEH_PE_PASSTHROUGH;
+ else
+ pe->state &= ~EEH_PE_PASSTHROUGH;
+ }
+}
+
/*
* The struct is used to trace EEH state for the associated
* PCI device node or PCI device. In future, it might
@@ -110,6 +137,7 @@ struct eeh_pe {
#define EEH_DEV_SYSFS (1 << 9)/* Sysfs created*/
#define EEH_DEV_REMOVED(1 << 10) /* Removed permanently
*/
#define EEH_DEV_FRESET (1 << 11) /* Fundamental reset*/
+#define EEH_DEV_PASSTHROUGH(1 << 12) /* Owned by guest */
struct eeh_dev {
int mode; /* EEH mode */
@@ -126,6 +154,9 @@ struct eeh_dev {
struct device_node *dn; /* Associated device node */
struct pci_dev *pdev; /* Associated PCI device*/
struct pci_bus *bus;/* PCI bus for partial hotplug */
+#ifdef CONFIG_VFIO_EEH
+ struct eeh_vfio_pci_addr guest_addr;
+#endif
};
static inline struct device_node *eeh_dev_to_of_node(struct eeh_dev *edev)
@@ -138,6 +169,21 @@ static inline struct pci_dev *eeh_dev_to_pci_dev(struct
eeh_dev *edev)
return edev ? edev->pdev : NULL;
}
+static inline bool eeh_dev_passed(struct eeh_dev *dev)
+{
+ return dev ? !!(dev->mode & EEH_DEV_PASSTHROUGH) : false;
+}
+
+static inline void eeh_dev_set_passed(struct eeh_dev *dev, bool passed)
+{
+ if (dev) {
+ if (passed)
+ dev->mode |= EEH_DEV_PASSTHROUGH;
+ else
+ dev->mode &= ~EEH_DEV_PASSTHROUGH;
+ }
+}
+
/* Return values from eeh_ops::next_error */
enum {
EEH_NEXT_ERR_NONE = 0,
@@ -335,6 +381,12 @@ static inline void eeh_remove_device(struct pci_dev *dev)
{ }
#define EEH_IO_ERROR_VALUE(size) (-1UL)
#endif /* CONFIG_EEH */
+
+#ifdef CONFIG_VFIO_EEH
+struct eeh_dev *eeh_vfio_dev_get(struct eeh_vfio_pci_addr *addr);
+struct eeh_pe *eeh_vfio_pe_get(struct eeh_vfio_pci_addr *addr);
+#endif /* CONFIG_VFIO_EEH */
+
#ifdef CONFIG_PPC64
/*
* MMIO read/write operations with EEH support.
diff --git a/arch/powerpc/kernel/eeh_pe.c b/arch/powerpc/kerne
[PATCH 1/8] drivers/vfio: Introduce CONFIG_VFIO_EEH
The patch introduces CONFIG_VFIO_EEH for more IOCTL commands on tce_iommu_driver_ops to support EEH funtionality for PCI devices that are passed through from host to guest. Signed-off-by: Gavin Shan --- drivers/vfio/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index af7b204..4f3293b 100644 --- a/drivers/vfio/Kconfig +++ b/drivers/vfio/Kconfig @@ -8,11 +8,17 @@ config VFIO_IOMMU_SPAPR_TCE depends on VFIO && SPAPR_TCE_IOMMU default n +config VFIO_EEH + tristate + depends on EEH && VFIO_IOMMU_SPAPR_TCE + default n + menuconfig VFIO tristate "VFIO Non-Privileged userspace driver framework" depends on IOMMU_API select VFIO_IOMMU_TYPE1 if X86 select VFIO_IOMMU_SPAPR_TCE if (PPC_POWERNV || PPC_PSERIES) + select VFIO_EEH if PPC_POWERNV select ANON_INODES help VFIO provides a framework for secure userspace device drivers. -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH RFC v3 0/8] EEH Support for VFIO PCI device
The series of patches intends to support EEH for PCI devices, which are passed through to PowerKVM based guest via VFIO. The implementation is straightforward based on the issues or problems we have to resolve to support EEH for PowerKVM based guest. - Emulation for EEH RTAS requests. All EEH RTAS requests goes to QEMU firstly. If QEMU can't handle it, the request will be sent to host via newly introduced VFIO container IOCTL command (VFIO_EEH_INFO) and gets handled in host kernel. - The error injection infrastructure need support request from the userland utility "errinjct" and PowerKVM based guest. The userland utility "errinjct" works on pSeries platform well with dedicated syscall, which helps invoking RTAS service to fulfil error injection in kernel. From the perspective, it's reasonable to extend the syscall to support PowerNV platform so that OPAL call can be invoked in host kernel for injecting errors. The data transported between userland and kerenl is still following "struct rtas_args" for both cases of PowerNV (OPAL) and pSeries (RTAS). The series of patches requires corresponding firmware changes from Mike Qiu to support error injection and QEMU changes to support EEH for guest. QEMU patchset will be sent separately. Change log == v1 -> v2: * EEH RTAS requests are routed to QEMU, and then possiblly to host kerenl. The mechanism KVM in-kernel handling is dropped. * Error injection is reimplemented based syscall, instead of KVM in-kerenl handling. The logic for error injection token management is moved to QEMU. The error injection request is routed to QEMU and then possiblly to host kernel. v2 -> v3: * Make the fields in struct eeh_vfio_pci_addr, struct vfio_eeh_info based on the comments from Alexey. * Define macros for EEH VFIO operations (Alexey). * Clear frozen state after successful PE reset. * Merge original [PATCH 1/2/3] to one. Testing on P7 = - Emulex adapter Testing on P8 = - Need more testing after design is finalized. - Gavin Shan (8): drivers/vfio: Introduce CONFIG_VFIO_EEH powerpc/eeh: Info to trace passed devices drivers/vfio: New IOCTL command VFIO_EEH_INFO powerpc/eeh: Avoid event on passed PE powerpc/powernv: Sync OPAL header file with firmware powerpc: Extend syscall ppc_rtas() powerpc/powernv: Implement ppc_call_opal() powerpc/powernv: Error injection infrastructure arch/powerpc/include/asm/eeh.h | 52 +++ arch/powerpc/include/asm/opal.h| 74 ++- arch/powerpc/include/asm/rtas.h| 10 +- arch/powerpc/include/asm/syscalls.h| 2 +- arch/powerpc/include/asm/systbl.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 2 +- arch/powerpc/kernel/eeh.c | 8 + arch/powerpc/kernel/eeh_pe.c | 80 arch/powerpc/kernel/rtas.c | 57 +-- arch/powerpc/kernel/syscalls.c | 50 +++ arch/powerpc/platforms/powernv/Makefile| 3 +- arch/powerpc/platforms/powernv/eeh-ioda.c | 3 +- arch/powerpc/platforms/powernv/eeh-vfio.c | 593 + arch/powerpc/platforms/powernv/errinject.c | 224 ++ arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + arch/powerpc/platforms/powernv/opal.c | 93 drivers/vfio/Kconfig | 6 + drivers/vfio/vfio_iommu_spapr_tce.c| 12 + include/uapi/linux/vfio.h | 57 +++ kernel/sys_ni.c| 2 +- 20 files changed, 1278 insertions(+), 53 deletions(-) create mode 100644 arch/powerpc/platforms/powernv/eeh-vfio.c create mode 100644 arch/powerpc/platforms/powernv/errinject.c Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
Hi Guenter, On Tue, 13 May 2014 10:17:49 -0700 Guenter Roeck wrote: > > On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: > > > > > After applying this patch, I get > > > > > > arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range > > > (0x814c is not between 0x8000 and > > > 0x7ffc) > > > arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range > > > (0x814c is not between 0x8000 and > > > 0x7ffc) > > > > > > with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and > > > powerpc:maple_defconfig. > > > > > > This is on top of v3.15-rc5. Any idea what is going on ? > > > > > > Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). > > > > Interesting... works with all my test configs using 4.7.3... > > > > I don't have my tree at hand right now, I'll check what that means > > tomorrow see if I can find a workaround. > > > It works for me with gcc 4.8.2 (build from yocto 1.6.0). > > Is asking people to use gcc 4.7.3 or later acceptable ? OK, this appears to be an assembler bug. $ cat test.s .text x: .pushsectionb, "a" beq y .popsection .=0x8 y: $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.22 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.6.3-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s test.s: Assembler messages: test.s:4: Error: operand out of range (0x0008 is not between 0x8000 and 0x7ffc) $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as --version GNU assembler (GNU Binutils) 2.23.52.20130512 This assembler was configured for a target of `powerpc64-linux'. $ /opt/cross/gcc-4.8.1-nolibc/powerpc64-linux/bin/powerpc64-linux-as -o test.o test.s (no error) Alan, can you shed light on when it was fixed? -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: relocate "config DTL" so KConfig nests properly
On Tue, 2014-05-13 at 00:12 -0700, Cody P Schafer wrote: > On 05/12/2014 11:23 PM, Michael Neuling wrote: > >> powerpc/pseries: relocate "config DTL" so KConfig nests properly > > > > I don't know what that means. Can you describe it in more detail? > > > > So the "config DTL" refers to the configuration entry. > > The "nests properly" refers to the indent that 'make menuconfig' shows > when a config-option that depends on the config-option proceeding it. > > In this case, moving config DTL up so it is below config PPC_SPLPAR > means that menuconfig will show config DTL nicely indented right below > config PPC_SPLPAR when PPC_SPLPAR is enabled. > > To contrast that, right now if I enable PPC_SPLPAR in menuconfig, all I > can immediately tell is that "something showed up further down the list > where I wasn't looking", and I end up having to toggle the option a few > times to figure out what showed up, or look at the KConfig to find out > that config DTL depends on config PPC_SPLPAR. > > Essentially, this enables menuconfig to provide a visual hint about the > dependencies between options. Sounds like a good idea. Can you repost the patch with that same info in the commit log. Mikey > > Mikey > > > > > > On Mon, 2014-05-12 at 20:09 -0700, Cody P Schafer wrote: > >> Signed-off-by: Cody P Schafer > >> --- > >> arch/powerpc/platforms/pseries/Kconfig | 20 ++-- > >> 1 file changed, 10 insertions(+), 10 deletions(-) > >> > >> diff --git a/arch/powerpc/platforms/pseries/Kconfig > >> b/arch/powerpc/platforms/pseries/Kconfig > >> index 2cb8b77..e00dd4d 100644 > >> --- a/arch/powerpc/platforms/pseries/Kconfig > >> +++ b/arch/powerpc/platforms/pseries/Kconfig > >> @@ -33,6 +33,16 @@ config PPC_SPLPAR > >> processors, that is, which share physical processors between > >> two or more partitions. > >> > >> +config DTL > >> + bool "Dispatch Trace Log" > >> + depends on PPC_SPLPAR && DEBUG_FS > >> + help > >> +SPLPAR machines can log hypervisor preempt & dispatch events to a > >> +kernel buffer. Saying Y here will enable logging these events, > >> +which are accessible through a debugfs file. > >> + > >> +Say N if you are unsure. > >> + > >> config PSERIES_MSI > >> bool > >> depends on PCI_MSI && PPC_PSERIES && EEH > >> @@ -122,13 +132,3 @@ config HV_PERF_CTRS > >> systems. 24x7 is available on Power 8 systems. > >> > >> If unsure, select Y. > >> - > >> -config DTL > >> - bool "Dispatch Trace Log" > >> - depends on PPC_SPLPAR && DEBUG_FS > >> - help > >> -SPLPAR machines can log hypervisor preempt & dispatch events to a > >> -kernel buffer. Saying Y here will enable logging these events, > >> -which are accessible through a debugfs file. > >> - > >> -Say N if you are unsure. > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] printk/of_serial: fix serial console cessation part way through boot.
Commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
"serial_core: Unregister console in uart_remove_one_port()"
fixed a crash where a serial port was removed but
not deregistered as a console.
There is a side effect of that commit for platforms having serial consoles
and of_serial configured (CONFIG_SERIAL_OF_PLATFORM). The serial console
is disabled midway through the boot process.
This cessation of the serial console affects PowerPC computers
such as the MVME5100 and SAM440EP.
The sequence is:
bootconsole [udbg0] enabled
serial8250/16550 driver initialises and registers its UARTS,
one of these is the serial console.
console [ttyS0] enabled
of_serial probes "platform" devices, registering them as it goes.
One of these is the serial console.
console [ttyS0] disabled.
The disabling of the serial console is due to:
a. unregister_console in printk not clearing the
CONS_ENABLED bit in the console flags,
even though it has announced that the console is disabled; and
b. of_platform_serial_probe in of_serial not setting the port type
before it registers with serial8250_register_8250_port.
This patch ensures that the serial console is re-enabled when of_serial
registers a serial port that corresponds to the designated console.
Signed-off-by: Stephen Chivers
Tested-by: Stephen Chivers
Acked-by: Geert Uytterhoeven [unregister_console]
===
The above failure was identified in Linux-3.15-rc2.
Tested using MVME5100 and SAM440EP PowerPC computers with
kernels built from Linux-3.15-rc5 and tty-next.
The continued operation of the serial console is vital for computers
such as the MVME5100 as that Single Board Computer does not
have any grapical/display hardware.
---
drivers/tty/serial/of_serial.c |1 +
kernel/printk/printk.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 9924660..27981e2 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -173,6 +173,7 @@ static int of_platform_serial_probe(struct platform_device
*ofdev)
{
struct uart_8250_port port8250;
memset(&port8250, 0, sizeof(port8250));
+ port.type = port_type;
port8250.port = port;
if (port.fifosize)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 7228258..221229c 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2413,6 +2413,7 @@ int unregister_console(struct console *console)
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
+ console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info
Sukadev Bhattiprolu wrote on 05/09/2014 09:46:38 PM: > From: Sukadev Bhattiprolu > To: Arnaldo Carvalho de Melo , > Cc: linux-ker...@vger.kernel.org, Anton Blanchard > , ulrich.weig...@de.ibm.com, Michael Ellerman > , Maynard Johnson/Rochester/IBM@IBMUS, > linuxppc-dev@lists.ozlabs.org > Date: 05/09/2014 09:46 PM > Subject: [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info > > [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info Acked-by: Maynard Johnson Reviewed and tested. Thanks, Suka. -Maynard > > When saving the callchain on Power, the kernel conservatively saves excess > entries in the callchain. A few of these entries are needed in some cases > but not others. > > Eg: the value in the link register (LR) is needed only when it holds the > return address of a function. At other times it must be ignored. > > If the unnecessary entries are not ignored, we end up with duplicate arcs > in the call-graphs. > > Use DWARF debug information to ignore the unnecessary entries. > > Callgraph before the patch: > > 14.67% 2234 sprintft libc-2.18.so [.] __random > | > --- __random >| >|--61.12%-- __random >| | >| |--97.15%-- rand >| | do_my_sprintf >| | main >| | generic_start_main.isra.0 >| | __libc_start_main >| | 0x0 >| | >| --2.85%-- do_my_sprintf >| main >| generic_start_main.isra.0 >| __libc_start_main >| 0x0 >| > --38.88%-- rand > | > |--94.01%-- rand > | do_my_sprintf > | main > | generic_start_main.isra.0 > | __libc_start_main > | 0x0 > | >--5.99%-- do_my_sprintf > main > generic_start_main.isra.0 > __libc_start_main > 0x0 > > Callgraph after the patch: > > 14.67% 2234 sprintft libc-2.18.so [.] __random > | > --- __random >| >|--95.93%-- rand >| do_my_sprintf >| main >| generic_start_main.isra.0 >| __libc_start_main >| 0x0 >| > --4.07%-- do_my_sprintf > main > generic_start_main.isra.0 > __libc_start_main > 0x0 > > TODO: For split-debug info objects like glibc, we can only determine >the call-frame-address only when both .eh_frame and .debug_info >sections are available. We should be able to determin the CFA >even without the .eh_frame section. > > Thanks to Ulrich Weigand for help with DWARF debug information. > > Fix suggested by Anton Blanchard. > > Reported-by: Maynard Johnson > Signed-off-by: Sukadev Bhattiprolu > --- > tools/perf/arch/powerpc/Makefile| 1 + > tools/perf/arch/powerpc/util/adjust-callchain.c | 278 + > +++ > tools/perf/config/Makefile | 5 + > tools/perf/util/callchain.h | 12 + > tools/perf/util/machine.c | 16 +- > 5 files changed, 310 insertions(+), 2 deletions(-) > create mode 100644 tools/perf/arch/powerpc/util/adjust-callchain.c > [snip]___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
From: Wilfried Klaebe Date: Sun, 11 May 2014 00:12:32 + > net: get rid of SET_ETHTOOL_OPS > > Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. > This does that. > > Mostly done via coccinelle script: > @@ > struct ethtool_ops *ops; > struct net_device *dev; > @@ > - SET_ETHTOOL_OPS(dev, ops); > + dev->ethtool_ops = ops; > > Compile tested only, but I'd seriously wonder if this broke anything. > > Suggested-by: Dave Miller > Signed-off-by: Wilfried Klaebe Applied to net-next, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: > > > After applying this patch, I get > > > > arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range > > (0x814c is not between 0x8000 and > > 0x7ffc) > > arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range > > (0x814c is not between 0x8000 and > > 0x7ffc) > > > > with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and > > powerpc:maple_defconfig. > > > > This is on top of v3.15-rc5. Any idea what is going on ? > > > > Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). > > Interesting... works with all my test configs using 4.7.3... > > I don't have my tree at hand right now, I'll check what that means > tomorrow see if I can find a workaround. > Drives me crazy. With gcc 4.8.2, powerpc:allmodconfig builds, but now I get failures with ppc64e_defconfig and chroma_defconfig: arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': (.text+0x1679e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e': (.text+0x167b2): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `skpinv': arch/powerpc/kernel/exceptions-64e.o:(.text+0x178c6): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+178e0 arch/powerpc/kernel/built-in.o: In function `a2_tlbinit_after_linear_map': (.text+0x17966): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+17974 arch/powerpc/kernel/built-in.o: In function `.init_core_book3e': arch/powerpc/kernel/exceptions-64e.o:(.text+0x17a7e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o Worse, that happens even without your patch applied, and the patch does not make a difference :-(. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
I wonder whether people are getting Roland's address from?
It's frequent that ptrace related patches end up CCed to
rol...@redhat.com, but, he's not been at Red Hat for a few years
now. Roland, do you still want to be CCed on ptrace-related
issues? If so, there's probably a script somewhere in the
kernel that needs updating. If not, well, it'd be good
if it were updated anyway. :-)
It's a little annoying, as Red Hat's servers outright reject
email sent from a @redhat.com address if one tries to send
an email that includes a CC/FROM to a user that no longer
exists in the @redhat.com domain.
--
Pedro Alves
On 05/05/14 08:54, Anshuman Khandual wrote:
> This patch enables get and set of transactional memory related register
> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing
> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR,
> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new
> ELF core note types added previously in this regard.
>
> (1) NT_PPC_TM_SPR
> (2) NT_PPC_TM_CGPR
> (3) NT_PPC_TM_CFPR
> (4) NT_PPC_TM_CVMX
>
> Signed-off-by: Anshuman Khandual
> ---
> arch/powerpc/include/asm/switch_to.h | 8 +
> arch/powerpc/kernel/process.c| 24 ++
> arch/powerpc/kernel/ptrace.c | 683
> +--
> 3 files changed, 687 insertions(+), 28 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/switch_to.h
> b/arch/powerpc/include/asm/switch_to.h
> index 0e83e7d..2737f46 100644
> --- a/arch/powerpc/include/asm/switch_to.h
> +++ b/arch/powerpc/include/asm/switch_to.h
> @@ -80,6 +80,14 @@ static inline void flush_spe_to_thread(struct task_struct
> *t)
> }
> #endif
>
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> +extern void flush_tmregs_to_thread(struct task_struct *);
> +#else
> +static inline void flush_tmregs_to_thread(struct task_struct *t)
> +{
> +}
> +#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
> +
> static inline void clear_task_ebb(struct task_struct *t)
> {
> #ifdef CONFIG_PPC_BOOK3S_64
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 31d0215..e247898 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -695,6 +695,30 @@ static inline void __switch_to_tm(struct task_struct
> *prev)
> }
> }
>
> +void flush_tmregs_to_thread(struct task_struct *tsk)
> +{
> + /*
> + * If task is not current, it should have been flushed
> + * already to it's thread_struct during __switch_to().
> + */
> + if (tsk != current)
> + return;
> +
> + preempt_disable();
> + if (tsk->thread.regs) {
> + /*
> + * If we are still current, the TM state need to
> + * be flushed to thread_struct as it will be still
> + * present in the current cpu.
> + */
> + if (MSR_TM_ACTIVE(tsk->thread.regs->msr)) {
> + __switch_to_tm(tsk);
> + tm_recheckpoint_new_task(tsk);
> + }
> + }
> + preempt_enable();
> +}
> +
> /*
> * This is called if we are on the way out to userspace and the
> * TIF_RESTORE_TM flag is set. It checks if we need to reload
> diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
> index 2e3d2bf..92faded 100644
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -357,6 +357,17 @@ static int gpr_set(struct task_struct *target, const
> struct user_regset *regset,
> return ret;
> }
>
> +/*
> + * When any transaction is active, "thread_struct->transact_fp" holds
> + * the current running value of all FPR registers and "thread_struct->
> + * fp_state" holds the last checkpointed FPR registers state for the
> + * current transaction.
> + *
> + * struct data {
> + * u64 fpr[32];
> + * u64 fpscr;
> + * };
> + */
> static int fpr_get(struct task_struct *target, const struct user_regset
> *regset,
> unsigned int pos, unsigned int count,
> void *kbuf, void __user *ubuf)
> @@ -365,21 +376,41 @@ static int fpr_get(struct task_struct *target, const
> struct user_regset *regset,
> u64 buf[33];
> int i;
> #endif
> - flush_fp_to_thread(target);
> + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
> + flush_fp_to_thread(target);
> + flush_altivec_to_thread(target);
> + flush_tmregs_to_thread(target);
> + } else {
> + flush_fp_to_thread(target);
> + }
>
> #ifdef CONFIG_VSX
> /* copy to local buffer then write that out */
> - for (i = 0; i < 32 ; i++)
> - buf[i] = target->thread.TS_FPR(i);
> - buf[32] = target->thread.fp_state.fpscr;
> + if (MSR_TM_ACTIVE(target->thread.regs->msr)) {
> + for (i = 0; i < 32 ; i++)
> + buf[i] = target->thread.TS_TRANS_FPR(i);
> + buf[32] = target->thread.transact
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Tue, May 13, 2014 at 07:16:41PM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: > > > After applying this patch, I get > > > > arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range > > (0x814c is not between 0x8000 and > > 0x7ffc) > > arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range > > (0x814c is not between 0x8000 and > > 0x7ffc) > > > > with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and > > powerpc:maple_defconfig. > > > > This is on top of v3.15-rc5. Any idea what is going on ? > > > > Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). > > Interesting... works with all my test configs using 4.7.3... > > I don't have my tree at hand right now, I'll check what that means > tomorrow see if I can find a workaround. > It works for me with gcc 4.8.2 (build from yocto 1.6.0). Is asking people to use gcc 4.7.3 or later acceptable ? Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/05/14 08:54, Anshuman Khandual wrote: > This patch enables get and set of transactional memory related register > sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing > four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR, > REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new > ELF core note types added previously in this regard. > > (1) NT_PPC_TM_SPR > (2) NT_PPC_TM_CGPR > (3) NT_PPC_TM_CFPR > (4) NT_PPC_TM_CVMX Sorry that I couldn't tell this from the code, but, what does the kernel return when the ptracer requests these registers and the program is not in a transaction? Specifically I'm wondering whether this follows the same semantics as the s390 port. -- Pedro Alves ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info
Maynard Johnson [mpj...@us.ibm.com] wrote: | > [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info | | Acked-by: Maynard Johnson | | Reviewed and tested. Thanks, Suka. Thanks Maynard. This updated patch also fixes whitespace damage. From: Sukadev Bhattiprolu Date: Fri, 9 May 2014 19:00:35 -0500 Subject: [PATCH 1/1] powerpc/perf: Adjust callchain based on DWARF debug info When saving the callchain on Power, the kernel conservatively saves excess entries in the callchain. A few of these entries are needed in some cases but not others. We should use the DWARF debug information to determine when the entries are needed. Eg: the value in the link register (LR) is needed only when it holds the return address of a function. At other times it must be ignored. If the unnecessary entries are not ignored, we end up with duplicate arcs in the call-graphs. Use the DWARF debug information to determine if any callchain entries should be ignored when building call-graphs. Callgraph before the patch: 14.67% 2234 sprintft libc-2.18.so [.] __random | --- __random | |--61.12%-- __random | | | |--97.15%-- rand | | do_my_sprintf | | main | | generic_start_main.isra.0 | | __libc_start_main | | 0x0 | | | --2.85%-- do_my_sprintf | main | generic_start_main.isra.0 | __libc_start_main | 0x0 | --38.88%-- rand | |--94.01%-- rand | do_my_sprintf | main | generic_start_main.isra.0 | __libc_start_main | 0x0 | --5.99%-- do_my_sprintf main generic_start_main.isra.0 __libc_start_main 0x0 Callgraph after the patch: 14.67% 2234 sprintft libc-2.18.so [.] __random | --- __random | |--95.93%-- rand | do_my_sprintf | main | generic_start_main.isra.0 | __libc_start_main | 0x0 | --4.07%-- do_my_sprintf main generic_start_main.isra.0 __libc_start_main 0x0 TODO: For split-debug info objects like glibc, we can only determine the call-frame-address only when both .eh_frame and .debug_info sections are available. We should be able to determin the CFA even without the .eh_frame section. Fix suggested by Anton Blanchard. Thanks to valuable input on DWARF debug information from Ulrich Weigand. Reported-by: Maynard Johnson Signed-off-by: Sukadev Bhattiprolu Tested-by: Maynard Johnson Acked-by: Maynard Johnson --- tools/perf/arch/powerpc/Makefile| 1 + tools/perf/arch/powerpc/util/adjust-callchain.c | 276 tools/perf/config/Makefile | 5 + tools/perf/util/callchain.h | 12 ++ tools/perf/util/machine.c | 16 +- 5 files changed, 308 insertions(+), 2 deletions(-) create mode 100644 tools/perf/arch/powerpc/util/adjust-callchain.c diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile index 744e629..512cc8d 100644 --- a/tools/perf/arch/powerpc/Makefile +++ b/tools/perf/arch/powerpc/Makefile @@ -3,3 +3,4 @@ PERF_HAVE_DWARF_REGS := 1 LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o endif LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o +LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/adjust-callchain.o diff --git a/tools/perf/arch/powerpc/util/adjust-callchain.c b/tools/perf/arch/powerpc/util/adjust-callchain.c new file mode 100644 index 000..0689dd8 --- /dev/null +++ b/tools/perf/arch/powerpc/util/adjust-callchain.c @@ -0,0 +1,276 @@ +/* + * Use DWARF Debug information to skip unnecessary callchain entries. + * + * Copyright (C) 2014 Sukadev Bhattiprolu, IBM Corporation. + * Copyright (C) 2014 Ulrich Weigand, IBM Corporation. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either versio
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On 05/13/2014 02:16 AM, Benjamin Herrenschmidt wrote: On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: After applying this patch, I get arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range (0x814c is not between 0x8000 and 0x7ffc) with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and powerpc:maple_defconfig. This is on top of v3.15-rc5. Any idea what is going on ? Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. Maybe something is wrong with my toolchain. I'll try to find a more recent one. Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Boot problems with a PA6T board
On 05.05.2014 07:48, Michael Ellerman wrote: On Sun, 2014-05-04 at 18:02 +0200, Christian Zigotzky wrote: Hi All, The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a Radeon HD 6870 graphics card. Screenshot: http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view The kernel 3.14 starts without any problems. Has anyone a tip for me, please? The line that says "starting cpu hw idx 0... failed" looks a little worrying. Do you see that on 3.14 as well? Otherwise bisection is probably your best bet. cheers Hi All, I have found out which patch is responsible for the boot problems. It's patch 9000c17dc0f9c910267d2661225c9d33a227b27e. Link: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9000c17dc0f9c910267d2661225c9d33a227b27e Experimental protocol: git checkout -f 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44; git clean -fdx (from 02/04/14) -> Kernel boots git checkout -f f1553174a207f68a4ec19d436003097e0a4dc405; git clean -fdx (from 03/04/14) -> Kernel boots git checkout -f d40326f4b9f9617cdfd30f83a2db57d47e9c5bac; git clean -fdx (from 04/04/14) -> Kernel boots git checkout -f 930b440cd8256f3861bdb0a59d26efaadac7941a; git clean -fdx (from 05/04/14) -> doesn't boot (rtc error) git checkout -f 2b3a8fd735f86ebeb2b9d061054003000c36b654; git clean -fdx (from 06/04/14) -> doesn't boot (rtc error) git checkout -f 26c12d93348f0bda0756aff83f4867d9ae58a5a6; git clean -fdx (from 07/04/14) -> doesn't boot (rtc error) git checkout -f a6c8aff022d4d06e4b41455ae9b2a5d3d503bf76; git clean -fdx (from 08/04/14) -> Kernel boots git checkout -f 035328c202d26a824b8632fd3b00635db5aee5a2; git clean -fdx (from 08/04/14) -> Kernel boots git checkout -f 9000c17dc0f9c910267d2661225c9d33a227b27e; git clean -fdx (from 08/04/14) powerpc/powernv: Fix endian issues with sensor code One OPAL call and one device tree property needed byte swapping. -> doesn't boot (prom_init) git checkout -f d3d35d957a9d0733dc51f14b5abc0bff5d3c5f3a; git clean -fdx (from 08/04/14) -> doesn't boot (prom_init) git checkout -f c4586256f0c440bc2bdb29d2cbb915f0ca785d26; git clean -fdx (from 09/04/14) -> doesn't boot (prom_init) I'm not a programmer but what can I do to solve this boot problem? Cheers, Christian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] pci-scan: Fix setting the limit
On 05/13/2014 08:48 PM, Alexey Kardashevskiy wrote:
> PCI spec says that lower 20 bits are assumed 0xF. The existing code
> seems to get it right in pci-bridge-set-mem-limit.
>
> However pci-bridge-set-mem-base does not account 0xF and poison
> the limit. Since the limit is not stored anywhere in SLOF and only
> besides in the config space, it remains broken.
>
> This fixes pci-bridge-set-mem-base.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
>
> I have doubts this is the right fix as I tried to "fix"
> pci-bridge-set-mmio-base (while I am here) and it broke the guest.
>
> The problem I am fixing by this is that QEMU started as below is
> unable to initialize virtio-net device because there are overlapping
> virtio's BAR and bridge's "ranges" property. Note that virtio-net is
> attached to the PHB, not that additional bridge.
>
> /home/aik/qemu-system-ppc64 \
> -enable-kvm \
> -m 1024 \
> -machine pseries \
> -nographic \
> -vga none \
> -device pci-bridge,id=id0,bus=pci.0,addr=5.0,chassis_nr=7 \
> -netdev tap,id=id1,ifname=tap1,script=ifup.sh,downscript=ifdown.sh \
> -device virtio-net-pci,id=id2,netdev=id1 \
> -initrd 1.cpio \
> -kernel vml315rc3 \
>
> This is from the guest:
>
> PCI host bridge /pci@8002000 ranges:
> IO 0x01008000..0x01008000 -> 0x
> MEM 0x0100a000..0x0100bfff -> 0x8000
>
> PCI::00:00.0 Resource 0 00010020-0001003f [40101]
> PCI::00:00.0 Resource 1 0100b000-0100bfff [40200]
> PCI::00:00.0 Resource 6 0100b004-0100b007 [4c200]
>
> PCI::00:05.0 Bus rsrc 1 9010-a00f [40200]
> PCI::00:05.0 Bus rsrc 2 0100a000-0100b00f [42208]
> PCI: PHB (bus 0) bridge rsrc 4: 0001-0001 [0x100],
> parent c0f765b8 (PCI IO)
> PCI: PHB (bus 0) bridge rsrc 5: 0100a000-0100bfff [0x200],
> parent c0f76580 (PCI mem)
> PCI: Allocating :00:00.0: Resource 0: 00010020..0001003f
> [40101]
> PCI: Allocating :00:00.0: Resource 1: 0100b000..0100bfff
> [40200]
> PCI: Cannot allocate resource region 1 of device :00:00.0, will remap
>
> This are PHB and bridge "ranges":
> [root@erif_root ~]# hexdump -e '7/4 "%08x "' -e '"\n"'
> /proc/device-tree/pci@8002000/ranges
> 0100 0100 8000 0001
> 0200 8000 0100 a000 2000
> [root@erif_root ~]# hexdump -e '8/4 "%08x "' -e '"\n"'
> /proc/device-tree/pci@8002000/pci@5/ranges
> 0200 9010 0200 9010 1000
> 4200 8000 4200 8000 1010
>
> And virtio-net BARs:
> [root@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
> /proc/device-tree/pci@8002000/ethernet@0/reg
>
> 0110 0020
> 0214 1000
> 0230 0004
> [root@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
> /proc/device-tree/pci@8002000/ethernet@0/assigned-addres
> es
> 8230 9004 0004
> 8110 0020 0020
> 8214 9000 1000
Hm. The patch seems to remove non-prefetch range from the PCI bridge
(pci@5/ranges) and made weird start address. So it is wrong. Oh...
[root@erif_root ~]# hexdump -e '7/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ranges
0100 0100 8000 0001
0200 8000 0100 a000 2000
[root@erif_root ~]# hexdump -e '8/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/pci@5/ranges
4200 7ff0 4200 7ff0 0010
[root@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ethernet@0/reg
0110 0020
0214 1000
0230 0004
es ot@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ethernet@0/assigned-addresse
8230 9004 0004
8110 0020 0020
8214 9000 1000
> ---
> slof/fs/pci-scan.fs | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/slof/fs/pci-scan.fs b/slof/fs/pci-scan.fs
> index ec9bd27..53b3b2c 100644
> --- a/slof/fs/pci-scan.fs
> +++ b/slof/fs/pci-scan.fs
> @@ -115,6 +115,7 @@ here 100 allot CONSTANT pci-device-vec
> THEN\ FI
> 10 rshift \ keep upper 16 bits
> pci-max-mem @ and or \ and Insert mmem Limit (set
> it to max)
> +1-
> swa
[PATCH] powerpc/pseries: hcall functions are exported to modules, need _GLOBAL_TOC()
The hcall macros may call out to c code for tracing, so we need to set up a valid r2. This fixes an oops found when testing ibmvscsi as a module. Signed-off-by: Anton Blanchard --- diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S index 7891a86..99ecf0a 100644 --- a/arch/powerpc/platforms/pseries/hvCall.S +++ b/arch/powerpc/platforms/pseries/hvCall.S @@ -106,7 +106,7 @@ END_FTR_SECTION(0, 1); \ .text -_GLOBAL(plpar_hcall_norets) +_GLOBAL_TOC(plpar_hcall_norets) HMT_MEDIUM mfcrr0 @@ -122,7 +122,7 @@ _GLOBAL(plpar_hcall_norets) mtcrf 0xff,r0 blr /* return r3 = status */ -_GLOBAL(plpar_hcall) +_GLOBAL_TOC(plpar_hcall) HMT_MEDIUM mfcrr0 @@ -188,7 +188,7 @@ _GLOBAL(plpar_hcall_raw) blr /* return r3 = status */ -_GLOBAL(plpar_hcall9) +_GLOBAL_TOC(plpar_hcall9) HMT_MEDIUM mfcrr0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] pci-scan: Fix setting the limit
PCI spec says that lower 20 bits are assumed 0xF. The existing code
seems to get it right in pci-bridge-set-mem-limit.
However pci-bridge-set-mem-base does not account 0xF and poison
the limit. Since the limit is not stored anywhere in SLOF and only
besides in the config space, it remains broken.
This fixes pci-bridge-set-mem-base.
Signed-off-by: Alexey Kardashevskiy
---
I have doubts this is the right fix as I tried to "fix"
pci-bridge-set-mmio-base (while I am here) and it broke the guest.
The problem I am fixing by this is that QEMU started as below is
unable to initialize virtio-net device because there are overlapping
virtio's BAR and bridge's "ranges" property. Note that virtio-net is
attached to the PHB, not that additional bridge.
/home/aik/qemu-system-ppc64 \
-enable-kvm \
-m 1024 \
-machine pseries \
-nographic \
-vga none \
-device pci-bridge,id=id0,bus=pci.0,addr=5.0,chassis_nr=7 \
-netdev tap,id=id1,ifname=tap1,script=ifup.sh,downscript=ifdown.sh \
-device virtio-net-pci,id=id2,netdev=id1 \
-initrd 1.cpio \
-kernel vml315rc3 \
This is from the guest:
PCI host bridge /pci@8002000 ranges:
IO 0x01008000..0x01008000 -> 0x
MEM 0x0100a000..0x0100bfff -> 0x8000
PCI::00:00.0 Resource 0 00010020-0001003f [40101]
PCI::00:00.0 Resource 1 0100b000-0100bfff [40200]
PCI::00:00.0 Resource 6 0100b004-0100b007 [4c200]
PCI::00:05.0 Bus rsrc 1 9010-a00f [40200]
PCI::00:05.0 Bus rsrc 2 0100a000-0100b00f [42208]
PCI: PHB (bus 0) bridge rsrc 4: 0001-0001 [0x100],
parent c0f765b8 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 5: 0100a000-0100bfff [0x200],
parent c0f76580 (PCI mem)
PCI: Allocating :00:00.0: Resource 0: 00010020..0001003f
[40101]
PCI: Allocating :00:00.0: Resource 1: 0100b000..0100bfff
[40200]
PCI: Cannot allocate resource region 1 of device :00:00.0, will remap
This are PHB and bridge "ranges":
[root@erif_root ~]# hexdump -e '7/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ranges
0100 0100 8000 0001
0200 8000 0100 a000 2000
[root@erif_root ~]# hexdump -e '8/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/pci@5/ranges
0200 9010 0200 9010 1000
4200 8000 4200 8000 1010
And virtio-net BARs:
[root@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ethernet@0/reg
0110 0020
0214 1000
0230 0004
[root@erif_root ~]# hexdump -e '5/4 "%08x "' -e '"\n"'
/proc/device-tree/pci@8002000/ethernet@0/assigned-addres
es
8230 9004 0004
8110 0020 0020
8214 9000 1000
---
slof/fs/pci-scan.fs | 1 +
1 file changed, 1 insertion(+)
diff --git a/slof/fs/pci-scan.fs b/slof/fs/pci-scan.fs
index ec9bd27..53b3b2c 100644
--- a/slof/fs/pci-scan.fs
+++ b/slof/fs/pci-scan.fs
@@ -115,6 +115,7 @@ here 100 allot CONSTANT pci-device-vec
THEN\ FI
10 rshift \ keep upper 16 bits
pci-max-mem @ and or \ and Insert mmem Limit (set
it to max)
+1-
swap 24 + rtas-config-l!\ and write it into the bridge
;
--
1.9.rc0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/ppc64: Allow allmodconfig to build (finally !)
On Mon, 2014-05-12 at 17:28 -0700, Guenter Roeck wrote: > After applying this patch, I get > > arch/powerpc/kernel/exceptions-64s.S:269: Error: operand out of range > (0x814c is not between 0x8000 and 0x7ffc) > arch/powerpc/kernel/exceptions-64s.S:729: Error: operand out of range > (0x814c is not between 0x8000 and 0x7ffc) > > with powerpc:defconfig, powerpc:allmodconfig, powerpc:cell_defconfig, and > powerpc:maple_defconfig. > > This is on top of v3.15-rc5. Any idea what is going on ? > > Compiler is powerpc64-poky-linux-gcc (GCC) 4.7.2 (from poky 1.4.0-1). Interesting... works with all my test configs using 4.7.3... I don't have my tree at hand right now, I'll check what that means tomorrow see if I can find a workaround. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pseries: relocate "config DTL" so KConfig nests properly
On 05/12/2014 11:23 PM, Michael Neuling wrote: powerpc/pseries: relocate "config DTL" so KConfig nests properly I don't know what that means. Can you describe it in more detail? So the "config DTL" refers to the configuration entry. The "nests properly" refers to the indent that 'make menuconfig' shows when a config-option that depends on the config-option proceeding it. In this case, moving config DTL up so it is below config PPC_SPLPAR means that menuconfig will show config DTL nicely indented right below config PPC_SPLPAR when PPC_SPLPAR is enabled. To contrast that, right now if I enable PPC_SPLPAR in menuconfig, all I can immediately tell is that "something showed up further down the list where I wasn't looking", and I end up having to toggle the option a few times to figure out what showed up, or look at the KConfig to find out that config DTL depends on config PPC_SPLPAR. Essentially, this enables menuconfig to provide a visual hint about the dependencies between options. Mikey On Mon, 2014-05-12 at 20:09 -0700, Cody P Schafer wrote: Signed-off-by: Cody P Schafer --- arch/powerpc/platforms/pseries/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 2cb8b77..e00dd4d 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -33,6 +33,16 @@ config PPC_SPLPAR processors, that is, which share physical processors between two or more partitions. +config DTL + bool "Dispatch Trace Log" + depends on PPC_SPLPAR && DEBUG_FS + help + SPLPAR machines can log hypervisor preempt & dispatch events to a + kernel buffer. Saying Y here will enable logging these events, + which are accessible through a debugfs file. + + Say N if you are unsure. + config PSERIES_MSI bool depends on PCI_MSI && PPC_PSERIES && EEH @@ -122,13 +132,3 @@ config HV_PERF_CTRS systems. 24x7 is available on Power 8 systems. If unsure, select Y. - -config DTL - bool "Dispatch Trace Log" - depends on PPC_SPLPAR && DEBUG_FS - help - SPLPAR machines can log hypervisor preempt & dispatch events to a - kernel buffer. Saying Y here will enable logging these events, - which are accessible through a debugfs file. - - Say N if you are unsure. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] booke/powerpc: define wimge shift mask to fix compilation error
This fixes below compilation error on SOCs where CONFIG_PHYS_64BIT is not defined: arch/powerpc/kvm/e500_mmu_host.c: In function 'kvmppc_e500_shadow_map': | arch/powerpc/kvm/e500_mmu_host.c:631:20: error: 'PTE_WIMGE_SHIFT' undeclared (first use in this function) |wimg = (*ptep >> PTE_WIMGE_SHIFT) & MAS2_WIMGE_MASK; | ^ | arch/powerpc/kvm/e500_mmu_host.c:631:20: note: each undeclared identifier is reported only once for each function it appears in | make[1]: *** [arch/powerpc/kvm/e500_mmu_host.o] Error 1 Signed-off-by: Bharat Bhushan --- arch/powerpc/include/asm/pte-fsl-booke.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/pte-fsl-booke.h b/arch/powerpc/include/asm/pte-fsl-booke.h index 2c12be5..e84dd7e 100644 --- a/arch/powerpc/include/asm/pte-fsl-booke.h +++ b/arch/powerpc/include/asm/pte-fsl-booke.h @@ -37,5 +37,7 @@ #define _PMD_PRESENT_MASK (PAGE_MASK) #define _PMD_BAD (~PAGE_MASK) +#define PTE_WIMGE_SHIFT (6) + #endif /* __KERNEL__ */ #endif /* _ASM_POWERPC_PTE_FSL_BOOKE_H */ -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
