* [PATCH] powerpc/papr_scm: Make access mode of 'perf_stats' attribute file to '0400'
From: Vaibhav Jain @ 2020-08-07 12:31 UTC (permalink / raw)
To: linuxppc-dev, linux-nvdimm
Cc: Santosh Sivaraj, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams, Ira Weiny
The newly introduced 'perf_stats' attribute uses the default access
mode of 0444 letting non-root users access performance stats of an
nvdimm and potentially force the kernel into issuing large number of
expensive HCALLs. Since the information exposed by this attribute
cannot be cached hence its better to ward of access to this attribute
from non-root users.
Hence this patch updates the access-mode of 'perf_stats' sysfs
attribute file to 0400 to make it only readable to root-users.
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/platforms/pseries/papr_scm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index f439f0dfea7d1..31864d167a2ce 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -822,7 +822,7 @@ static ssize_t perf_stats_show(struct device *dev,
kfree(stats);
return rc ? rc : seq_buf_used(&s);
}
-DEVICE_ATTR_RO(perf_stats);
+DEVICE_ATTR(perf_stats, 0400, perf_stats_show, NULL);
static ssize_t flags_show(struct device *dev,
struct device_attribute *attr, char *buf)
--
2.26.2
^ permalink raw reply related
* Re: [PATCH V6 0/2] tools/perf: Add extended regs support for powerpc
From: Arnaldo Carvalho de Melo @ 2020-08-07 12:24 UTC (permalink / raw)
To: Athira Rajeev; +Cc: ravi.bangoria, mikey, maddy, jolsa, kjain, linuxppc-dev
In-Reply-To: <1596795079-23601-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Em Fri, Aug 07, 2020 at 06:11:17AM -0400, Athira Rajeev escreveu:
> Patch set to add perf tools support for perf extended register capability
> in powerpc.
>
> Patch 1/2 adds extended regs for power9 ( mmcr0, mmcr1 and mmcr2 )
> to sample_reg_mask in the tool side to use with `-I?`.
> Patch 2/2 adds extended regs for power10 ( mmcr3, sier2, sier3)
> to sample_reg_mask in the tool side.
>
> Ravi bangoria found an issue with `perf record -I` while testing the
> changes. The same issue is currently being worked on here:
> https://lkml.org/lkml/2020/7/19/413 and will be resolved once fix
> from Jin Yao is merged.
>
> This includes the perf tools side changes to support extended regs.
> kernel side changes are sent as separate patchset.
Thanks, applied.
- Arnaldo
^ permalink raw reply
* Re: [PATCH 1/2] lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state
From: peterz @ 2020-08-07 11:11 UTC (permalink / raw)
To: Nicholas Piggin
Cc: linux-arch, Alexey Kardashevskiy, linuxppc-dev, linux-kernel,
Ingo Molnar, Will Deacon
In-Reply-To: <20200723105615.1268126-1-npiggin@gmail.com>
What's wrong with something like this?
AFAICT there's no reason to actually try and add IRQ tracing here, it's
just a hand full of instructions at the most.
---
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index 3a0db7b0b46e..6be22c1838e2 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -196,33 +196,6 @@ static inline bool arch_irqs_disabled(void)
arch_local_irq_restore(flags); \
} while(0)
-#ifdef CONFIG_TRACE_IRQFLAGS
-#define powerpc_local_irq_pmu_save(flags) \
- do { \
- raw_local_irq_pmu_save(flags); \
- trace_hardirqs_off(); \
- } while(0)
-#define powerpc_local_irq_pmu_restore(flags) \
- do { \
- if (raw_irqs_disabled_flags(flags)) { \
- raw_local_irq_pmu_restore(flags); \
- trace_hardirqs_off(); \
- } else { \
- trace_hardirqs_on(); \
- raw_local_irq_pmu_restore(flags); \
- } \
- } while(0)
-#else
-#define powerpc_local_irq_pmu_save(flags) \
- do { \
- raw_local_irq_pmu_save(flags); \
- } while(0)
-#define powerpc_local_irq_pmu_restore(flags) \
- do { \
- raw_local_irq_pmu_restore(flags); \
- } while (0)
-#endif /* CONFIG_TRACE_IRQFLAGS */
-
#endif /* CONFIG_PPC_BOOK3S */
#ifdef CONFIG_PPC_BOOK3E
diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h
index bc4bd19b7fc2..b357a35672b1 100644
--- a/arch/powerpc/include/asm/local.h
+++ b/arch/powerpc/include/asm/local.h
@@ -32,9 +32,9 @@ static __inline__ void local_##op(long i, local_t *l) \
{ \
unsigned long flags; \
\
- powerpc_local_irq_pmu_save(flags); \
+ raw_powerpc_local_irq_pmu_save(flags); \
l->v c_op i; \
- powerpc_local_irq_pmu_restore(flags); \
+ raw_powerpc_local_irq_pmu_restore(flags); \
}
#define LOCAL_OP_RETURN(op, c_op) \
@@ -43,9 +43,9 @@ static __inline__ long local_##op##_return(long a, local_t *l) \
long t; \
unsigned long flags; \
\
- powerpc_local_irq_pmu_save(flags); \
+ raw_powerpc_local_irq_pmu_save(flags); \
t = (l->v c_op a); \
- powerpc_local_irq_pmu_restore(flags); \
+ raw_powerpc_local_irq_pmu_restore(flags); \
\
return t; \
}
@@ -81,11 +81,11 @@ static __inline__ long local_cmpxchg(local_t *l, long o, long n)
long t;
unsigned long flags;
- powerpc_local_irq_pmu_save(flags);
+ raw_powerpc_local_irq_pmu_save(flags);
t = l->v;
if (t == o)
l->v = n;
- powerpc_local_irq_pmu_restore(flags);
+ raw_powerpc_local_irq_pmu_restore(flags);
return t;
}
@@ -95,10 +95,10 @@ static __inline__ long local_xchg(local_t *l, long n)
long t;
unsigned long flags;
- powerpc_local_irq_pmu_save(flags);
+ raw_powerpc_local_irq_pmu_save(flags);
t = l->v;
l->v = n;
- powerpc_local_irq_pmu_restore(flags);
+ raw_powerpc_local_irq_pmu_restore(flags);
return t;
}
@@ -117,12 +117,12 @@ static __inline__ int local_add_unless(local_t *l, long a, long u)
unsigned long flags;
int ret = 0;
- powerpc_local_irq_pmu_save(flags);
+ raw_powerpc_local_irq_pmu_save(flags);
if (l->v != u) {
l->v += a;
ret = 1;
}
- powerpc_local_irq_pmu_restore(flags);
+ raw_powerpc_local_irq_pmu_restore(flags);
return ret;
}
^ permalink raw reply related
* [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-08-07 10:18 UTC (permalink / raw)
To: Michael Ellerman
Cc: Alexey Kardashevskiy, Oliver O'Halloran, linuxppc-dev,
Cédric Le Goater
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
guest OS to clear all page table entries related to the adapter. If
some are still present, the RTAS call which isolates the PCI slot
returns error 9001 "valid outstanding translations" and the removal of
the IO adapter fails. This is because when the PHBs are scanned, Linux
maps automatically the INTx interrupts in the Linux interrupt number
space but these are never removed.
To solve this problem, we introduce a PPC platform specific
pcibios_remove_bus() routine which clears all interrupt mappings when
the bus is removed. This also clears the associated page table entries
of the ESB pages when using XIVE.
For this purpose, we record the logical interrupt numbers of the
mapped interrupt under the PHB structure and let pcibios_remove_bus()
do the clean up.
Since some PCI adapters, like GPUs, use the "interrupt-map" property
to describe interrupt mappings other than the legacy INTx interrupts,
we can not restrict the size of the mapping array to PCI_NUM_INTX. The
number of interrupt mappings is computed from the "interrupt-map"
property and the mapping array is allocated accordingly.
Cc: "Oliver O'Halloran" <oohall@gmail.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
Changes since v2:
- merged 2 patches.
arch/powerpc/include/asm/pci-bridge.h | 6 ++
arch/powerpc/kernel/pci-common.c | 114 ++++++++++++++++++++++++++
2 files changed, 120 insertions(+)
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index b92e81b256e5..ca75cf264ddf 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -48,6 +48,9 @@ struct pci_controller_ops {
/*
* Structure of a PCI controller (host bridge)
+ *
+ * @irq_count: number of interrupt mappings
+ * @irq_map: interrupt mappings
*/
struct pci_controller {
struct pci_bus *bus;
@@ -127,6 +130,9 @@ struct pci_controller {
void *private_data;
struct npu *npu;
+
+ unsigned int irq_count;
+ unsigned int *irq_map;
};
/* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..deb831f0ae13 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,115 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+/*
+ * Assumption is made on the interrupt parent. All interrupt-map
+ * entries are considered to have the same parent.
+ */
+static int pcibios_irq_map_count(struct pci_controller *phb)
+{
+ const __be32 *imap;
+ int imaplen;
+ struct device_node *parent;
+ u32 intsize, addrsize, parintsize, paraddrsize;
+
+ if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
+ return 0;
+ if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
+ return 0;
+
+ imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
+ if (!imap) {
+ pr_debug("%pOF : no interrupt-map\n", phb->dn);
+ return 0;
+ }
+ imaplen /= sizeof(u32);
+ pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
+
+ if (imaplen < (addrsize + intsize + 1))
+ return 0;
+
+ imap += intsize + addrsize;
+ parent = of_find_node_by_phandle(be32_to_cpup(imap));
+ if (!parent) {
+ pr_debug("%pOF : no imap parent found !\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
+ pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
+ paraddrsize = 0;
+
+ return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
+}
+
+static void pcibios_irq_map_init(struct pci_controller *phb)
+{
+ phb->irq_count = pcibios_irq_map_count(phb);
+ if (phb->irq_count < PCI_NUM_INTX)
+ phb->irq_count = PCI_NUM_INTX;
+
+ pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
+
+ phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
+ GFP_KERNEL);
+}
+
+static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
+{
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ int i;
+
+ if (!phb->irq_map)
+ return;
+
+ for (i = 0; i < phb->irq_count; i++) {
+ /*
+ * Look for an empty or an equivalent slot, as INTx
+ * interrupts can be shared between adapters.
+ */
+ if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
+ phb->irq_map[i] = virq;
+ break;
+ }
+ }
+
+ if (i == phb->irq_count)
+ pr_err("PCI:%s all platform interrupts mapped\n",
+ pci_name(pdev));
+}
+
+/*
+ * Clearing the mapped interrupts will also clear the underlying
+ * mappings of the ESB pages of the interrupts when under XIVE. It is
+ * a requirement of PowerVM to clear all memory mappings before
+ * removing a PHB.
+ */
+static void pci_irq_map_dispose(struct pci_bus *bus)
+{
+ struct pci_controller *phb = pci_bus_to_host(bus);
+ int i;
+
+ if (!phb->irq_map)
+ return;
+
+ pr_debug("PCI: Clearing interrupt mappings for PHB %04x:%02x...\n",
+ pci_domain_nr(bus), bus->number);
+ for (i = 0; i < phb->irq_count; i++)
+ irq_dispose_mapping(phb->irq_map[i]);
+
+ kfree(phb->irq_map);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+ pci_irq_map_dispose(bus);
+}
+EXPORT_SYMBOL_GPL(pcibios_remove_bus);
+
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -401,6 +510,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
+ /* Record all interrut mappings for later removal of a PHB */
+ pci_irq_map_register(pci_dev, virq);
return 0;
}
@@ -1554,6 +1665,9 @@ void pcibios_scan_phb(struct pci_controller *hose)
pr_debug("PCI: Scanning PHB %pOF\n", node);
+ /* Allocate interrupt mappings array */
+ pcibios_irq_map_init(hose);
+
/* Get some IO space for the new PHB */
pcibios_setup_phb_io_space(hose);
--
2.25.4
^ permalink raw reply related
* [PATCH V6 2/2] tools/perf: Add perf tools support for extended regs in power10
From: Athira Rajeev @ 2020-08-07 10:11 UTC (permalink / raw)
To: mpe, acme, jolsa; +Cc: ravi.bangoria, mikey, maddy, linuxppc-dev, kjain
In-Reply-To: <1596795079-23601-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Added support for supported regs which are new in power10
( MMCR3, SIER2, SIER3 ) to sample_reg_mask in the tool side
to use with `-I?` option. Also added PVR check to send extended
mask for power10 at kernel while capturing extended regs in
each sample.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 6 ++++++
tools/perf/arch/powerpc/include/perf_regs.h | 3 +++
tools/perf/arch/powerpc/util/perf_regs.c | 6 ++++++
3 files changed, 15 insertions(+)
diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
index 225c64c..bdf5f10 100644
--- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -52,6 +52,9 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_MMCR0,
PERF_REG_POWERPC_MMCR1,
PERF_REG_POWERPC_MMCR2,
+ PERF_REG_POWERPC_MMCR3,
+ PERF_REG_POWERPC_SIER2,
+ PERF_REG_POWERPC_SIER3,
/* Max regs without the extended regs */
PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
@@ -60,6 +63,9 @@ enum perf_event_powerpc_regs {
/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31 */
+#define PERF_REG_PMU_MASK_31 (((1ULL << (PERF_REG_POWERPC_SIER3 + 1)) - 1) - PERF_REG_PMU_MASK)
#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
+#define PERF_REG_MAX_ISA_31 (PERF_REG_POWERPC_SIER3 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index 46ed00d..63f3ac9 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -68,6 +68,9 @@
[PERF_REG_POWERPC_MMCR0] = "mmcr0",
[PERF_REG_POWERPC_MMCR1] = "mmcr1",
[PERF_REG_POWERPC_MMCR2] = "mmcr2",
+ [PERF_REG_POWERPC_MMCR3] = "mmcr3",
+ [PERF_REG_POWERPC_SIER2] = "sier2",
+ [PERF_REG_POWERPC_SIER3] = "sier3",
};
static inline const char *perf_reg_name(int id)
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
index d64ba0c..2b6d470 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -14,6 +14,7 @@
#include <linux/kernel.h>
#define PVR_POWER9 0x004E
+#define PVR_POWER10 0x0080
const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
@@ -64,6 +65,9 @@
SMPL_REG(mmcr0, PERF_REG_POWERPC_MMCR0),
SMPL_REG(mmcr1, PERF_REG_POWERPC_MMCR1),
SMPL_REG(mmcr2, PERF_REG_POWERPC_MMCR2),
+ SMPL_REG(mmcr3, PERF_REG_POWERPC_MMCR3),
+ SMPL_REG(sier2, PERF_REG_POWERPC_SIER2),
+ SMPL_REG(sier3, PERF_REG_POWERPC_SIER3),
SMPL_REG_END
};
@@ -194,6 +198,8 @@ uint64_t arch__intr_reg_mask(void)
version = (((mfspr(SPRN_PVR)) >> 16) & 0xFFFF);
if (version == PVR_POWER9)
extended_mask = PERF_REG_PMU_MASK_300;
+ else if (version == PVR_POWER10)
+ extended_mask = PERF_REG_PMU_MASK_31;
else
return mask;
--
1.8.3.1
^ permalink raw reply related
* [PATCH V6 1/2] tools/perf: Add perf tools support for extended register capability in powerpc
From: Athira Rajeev @ 2020-08-07 10:11 UTC (permalink / raw)
To: mpe, acme, jolsa; +Cc: ravi.bangoria, mikey, maddy, linuxppc-dev, kjain
In-Reply-To: <1596795079-23601-1-git-send-email-atrajeev@linux.vnet.ibm.com>
From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Add extended regs to sample_reg_mask in the tool side to use
with `-I?` option. Perf tools side uses extended mask to display
the platform supported register names (with -I? option) to the user
and also send this mask to the kernel to capture the extended registers
in each sample. Hence decide the mask value based on the processor
version.
Currently definitions for `mfspr`, `SPRN_PVR` are part of
`arch/powerpc/util/header.c`. Move this to a header file so that
these definitions can be re-used in other source files as well.
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
[Decide extended mask at run time based on platform]
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 14 ++++++-
tools/perf/arch/powerpc/include/perf_regs.h | 5 ++-
| 9 +----
tools/perf/arch/powerpc/util/perf_regs.c | 49 +++++++++++++++++++++++++
| 15 ++++++++
5 files changed, 82 insertions(+), 10 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/utils_header.h
diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
index f599064..225c64c 100644
--- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -48,6 +48,18 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_DSISR,
PERF_REG_POWERPC_SIER,
PERF_REG_POWERPC_MMCRA,
- PERF_REG_POWERPC_MAX,
+ /* Extended registers */
+ PERF_REG_POWERPC_MMCR0,
+ PERF_REG_POWERPC_MMCR1,
+ PERF_REG_POWERPC_MMCR2,
+ /* Max regs without the extended regs */
+ PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
+
+#define PERF_REG_PMU_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
+#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+
+#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
index e18a355..46ed00d 100644
--- a/tools/perf/arch/powerpc/include/perf_regs.h
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -64,7 +64,10 @@
[PERF_REG_POWERPC_DAR] = "dar",
[PERF_REG_POWERPC_DSISR] = "dsisr",
[PERF_REG_POWERPC_SIER] = "sier",
- [PERF_REG_POWERPC_MMCRA] = "mmcra"
+ [PERF_REG_POWERPC_MMCRA] = "mmcra",
+ [PERF_REG_POWERPC_MMCR0] = "mmcr0",
+ [PERF_REG_POWERPC_MMCR1] = "mmcr1",
+ [PERF_REG_POWERPC_MMCR2] = "mmcr2",
};
static inline const char *perf_reg_name(int id)
--git a/tools/perf/arch/powerpc/util/header.c b/tools/perf/arch/powerpc/util/header.c
index d487007..1a95017 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -7,17 +7,10 @@
#include <string.h>
#include <linux/stringify.h>
#include "header.h"
+#include "utils_header.h"
#include "metricgroup.h"
#include <api/fs/fs.h>
-#define mfspr(rn) ({unsigned long rval; \
- asm volatile("mfspr %0," __stringify(rn) \
- : "=r" (rval)); rval; })
-
-#define SPRN_PVR 0x11F /* Processor Version Register */
-#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
-#define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
-
int
get_cpuid(char *buffer, size_t sz)
{
diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
index 0a52429..d64ba0c 100644
--- a/tools/perf/arch/powerpc/util/perf_regs.c
+++ b/tools/perf/arch/powerpc/util/perf_regs.c
@@ -6,9 +6,15 @@
#include "../../../util/perf_regs.h"
#include "../../../util/debug.h"
+#include "../../../util/event.h"
+#include "../../../util/header.h"
+#include "../../../perf-sys.h"
+#include "utils_header.h"
#include <linux/kernel.h>
+#define PVR_POWER9 0x004E
+
const struct sample_reg sample_reg_masks[] = {
SMPL_REG(r0, PERF_REG_POWERPC_R0),
SMPL_REG(r1, PERF_REG_POWERPC_R1),
@@ -55,6 +61,9 @@
SMPL_REG(dsisr, PERF_REG_POWERPC_DSISR),
SMPL_REG(sier, PERF_REG_POWERPC_SIER),
SMPL_REG(mmcra, PERF_REG_POWERPC_MMCRA),
+ SMPL_REG(mmcr0, PERF_REG_POWERPC_MMCR0),
+ SMPL_REG(mmcr1, PERF_REG_POWERPC_MMCR1),
+ SMPL_REG(mmcr2, PERF_REG_POWERPC_MMCR2),
SMPL_REG_END
};
@@ -163,3 +172,43 @@ int arch_sdt_arg_parse_op(char *old_op, char **new_op)
return SDT_ARG_VALID;
}
+
+uint64_t arch__intr_reg_mask(void)
+{
+ struct perf_event_attr attr = {
+ .type = PERF_TYPE_HARDWARE,
+ .config = PERF_COUNT_HW_CPU_CYCLES,
+ .sample_type = PERF_SAMPLE_REGS_INTR,
+ .precise_ip = 1,
+ .disabled = 1,
+ .exclude_kernel = 1,
+ };
+ int fd;
+ u32 version;
+ u64 extended_mask = 0, mask = PERF_REGS_MASK;
+
+ /*
+ * Get the PVR value to set the extended
+ * mask specific to platform.
+ */
+ version = (((mfspr(SPRN_PVR)) >> 16) & 0xFFFF);
+ if (version == PVR_POWER9)
+ extended_mask = PERF_REG_PMU_MASK_300;
+ else
+ return mask;
+
+ attr.sample_regs_intr = extended_mask;
+ attr.sample_period = 1;
+ event_attr_init(&attr);
+
+ /*
+ * check if the pmu supports perf extended regs, before
+ * returning the register mask to sample.
+ */
+ fd = sys_perf_event_open(&attr, 0, -1, -1, 0);
+ if (fd != -1) {
+ close(fd);
+ mask |= extended_mask;
+ }
+ return mask;
+}
--git a/tools/perf/arch/powerpc/util/utils_header.h b/tools/perf/arch/powerpc/util/utils_header.h
new file mode 100644
index 0000000..5788eb1
--- /dev/null
+++ b/tools/perf/arch/powerpc/util/utils_header.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PERF_UTIL_HEADER_H
+#define __PERF_UTIL_HEADER_H
+
+#include <linux/stringify.h>
+
+#define mfspr(rn) ({unsigned long rval; \
+ asm volatile("mfspr %0," __stringify(rn) \
+ : "=r" (rval)); rval; })
+
+#define SPRN_PVR 0x11F /* Processor Version Register */
+#define PVR_VER(pvr) (((pvr) >> 16) & 0xFFFF) /* Version field */
+#define PVR_REV(pvr) (((pvr) >> 0) & 0xFFFF) /* Revison field */
+
+#endif /* __PERF_UTIL_HEADER_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH V6 0/2] tools/perf: Add extended regs support for powerpc
From: Athira Rajeev @ 2020-08-07 10:11 UTC (permalink / raw)
To: mpe, acme, jolsa; +Cc: ravi.bangoria, mikey, maddy, linuxppc-dev, kjain
Patch set to add perf tools support for perf extended register capability
in powerpc.
Patch 1/2 adds extended regs for power9 ( mmcr0, mmcr1 and mmcr2 )
to sample_reg_mask in the tool side to use with `-I?`.
Patch 2/2 adds extended regs for power10 ( mmcr3, sier2, sier3)
to sample_reg_mask in the tool side.
Ravi bangoria found an issue with `perf record -I` while testing the
changes. The same issue is currently being worked on here:
https://lkml.org/lkml/2020/7/19/413 and will be resolved once fix
from Jin Yao is merged.
This includes the perf tools side changes to support extended regs.
kernel side changes are sent as separate patchset.
Changelog:
Changes from v5 -> v6
- Split perf tools side changes to one patchset as suggested by
Arnaldo
Link to previous series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=192624
Changes from v4 -> v5
- initialize `perf_reg_extended_max` to work on
all platforms as suggested by Ravi Bangoria
- Added Reviewed-and-Tested-by from Ravi Bangoria
Changes from v3 -> v4
- Split the series and send extended regs as separate patch set here.
Link to previous series :
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=190462&state=*
Other PMU patches are already merged in powerpc/next.
- Fixed kernel build issue when using config having
CONFIG_PERF_EVENTS set and without CONFIG_PPC_PERF_CTRS
reported by kernel build bot.
- Included Reviewed-by from Kajol Jain.
- Addressed review comments from Ravi Bangoria to initialize `perf_reg_extended_max`
and define it in lowercase since it is local variable.
Anju T Sudhakar (1):
tools/perf: Add perf tools support for extended register capability in
powerpc
Athira Rajeev (1):
tools/perf: Add perf tools support for extended regs in power10
tools/arch/powerpc/include/uapi/asm/perf_regs.h | 20 ++++++++-
tools/perf/arch/powerpc/include/perf_regs.h | 8 +++-
tools/perf/arch/powerpc/util/header.c | 9 +---
tools/perf/arch/powerpc/util/perf_regs.c | 55 +++++++++++++++++++++++++
tools/perf/arch/powerpc/util/utils_header.h | 15 +++++++
5 files changed, 97 insertions(+), 10 deletions(-)
create mode 100644 tools/perf/arch/powerpc/util/utils_header.h
--
1.8.3.1
^ permalink raw reply
* [PATCH V6 1/2] powerpc/perf: Add support for outputting extended regs in perf intr_regs
From: Athira Rajeev @ 2020-08-07 10:05 UTC (permalink / raw)
To: mpe; +Cc: ravi.bangoria, mikey, maddy, kjain, acme, jolsa, linuxppc-dev
In-Reply-To: <1596794701-23530-1-git-send-email-atrajeev@linux.vnet.ibm.com>
From: Anju T Sudhakar <anju@linux.vnet.ibm.com>
Add support for perf extended register capability in powerpc.
The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to indicate the
PMU which support extended registers. The generic code define the mask
of extended registers as 0 for non supported architectures.
Patch adds extended regs support for power9 platform by
exposing MMCR0, MMCR1 and MMCR2 registers.
REG_RESERVED mask needs update to include extended regs.
`PERF_REG_EXTENDED_MASK`, contains mask value of the supported registers,
is defined at runtime in the kernel based on platform since the supported
registers may differ from one processor version to another and hence the
MASK value.
with patch
----------
available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11
r12 r13 r14 r15 r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26
r27 r28 r29 r30 r31 nip msr orig_r3 ctr link xer ccr softe
trap dar dsisr sier mmcra mmcr0 mmcr1 mmcr2
PERF_RECORD_SAMPLE(IP, 0x1): 4784/4784: 0 period: 1 addr: 0
... intr regs: mask 0xffffffffffff ABI 64-bit
.... r0 0xc00000000012b77c
.... r1 0xc000003fe5e03930
.... r2 0xc000000001b0e000
.... r3 0xc000003fdcddf800
.... r4 0xc000003fc7880000
.... r5 0x9c422724be
.... r6 0xc000003fe5e03908
.... r7 0xffffff63bddc8706
.... r8 0x9e4
.... r9 0x0
.... r10 0x1
.... r11 0x0
.... r12 0xc0000000001299c0
.... r13 0xc000003ffffc4800
.... r14 0x0
.... r15 0x7fffdd8b8b00
.... r16 0x0
.... r17 0x7fffdd8be6b8
.... r18 0x7e7076607730
.... r19 0x2f
.... r20 0xc00000001fc26c68
.... r21 0xc0002041e4227e00
.... r22 0xc00000002018fb60
.... r23 0x1
.... r24 0xc000003ffec4d900
.... r25 0x80000000
.... r26 0x0
.... r27 0x1
.... r28 0x1
.... r29 0xc000000001be1260
.... r30 0x6008010
.... r31 0xc000003ffebb7218
.... nip 0xc00000000012b910
.... msr 0x9000000000009033
.... orig_r3 0xc00000000012b86c
.... ctr 0xc0000000001299c0
.... link 0xc00000000012b77c
.... xer 0x0
.... ccr 0x28002222
.... softe 0x1
.... trap 0xf00
.... dar 0x0
.... dsisr 0x80000000000
.... sier 0x0
.... mmcra 0x80000000000
.... mmcr0 0x82008090
.... mmcr1 0x1e000000
.... mmcr2 0x0
... thread: perf:4784
Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
[Defined PERF_REG_EXTENDED_MASK at run time to add support for different platforms ]
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[Fix build issue using CONFIG_PERF_EVENTS without CONFIG_PPC_PERF_CTRS]
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Nageswara R Sastry <nasastry@in.ibm.com>
Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/include/asm/perf_event.h | 3 +++
arch/powerpc/include/asm/perf_event_server.h | 5 ++++
arch/powerpc/include/uapi/asm/perf_regs.h | 14 +++++++++++-
arch/powerpc/perf/core-book3s.c | 1 +
arch/powerpc/perf/perf_regs.c | 34 +++++++++++++++++++++++++---
arch/powerpc/perf/power9-pmu.c | 6 +++++
6 files changed, 59 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
index 1e8b2e1..daec64d 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -40,4 +40,7 @@
/* To support perf_regs sier update */
extern bool is_sier_available(void);
+/* To define perf extended regs mask value */
+extern u64 PERF_REG_EXTENDED_MASK;
+#define PERF_REG_EXTENDED_MASK PERF_REG_EXTENDED_MASK
#endif
diff --git a/arch/powerpc/include/asm/perf_event_server.h b/arch/powerpc/include/asm/perf_event_server.h
index 86c9eb06..f6acabb 100644
--- a/arch/powerpc/include/asm/perf_event_server.h
+++ b/arch/powerpc/include/asm/perf_event_server.h
@@ -62,6 +62,11 @@ struct power_pmu {
int *blacklist_ev;
/* BHRB entries in the PMU */
int bhrb_nr;
+ /*
+ * set this flag with `PERF_PMU_CAP_EXTENDED_REGS` if
+ * the pmu supports extended perf regs capability
+ */
+ int capabilities;
};
/*
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h b/arch/powerpc/include/uapi/asm/perf_regs.h
index f599064..225c64c 100644
--- a/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -48,6 +48,18 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_DSISR,
PERF_REG_POWERPC_SIER,
PERF_REG_POWERPC_MMCRA,
- PERF_REG_POWERPC_MAX,
+ /* Extended registers */
+ PERF_REG_POWERPC_MMCR0,
+ PERF_REG_POWERPC_MMCR1,
+ PERF_REG_POWERPC_MMCR2,
+ /* Max regs without the extended regs */
+ PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
+
+#define PERF_REG_PMU_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
+#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+
+#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index e29c846..65a0b76 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -2317,6 +2317,7 @@ int register_power_pmu(struct power_pmu *pmu)
pmu->name);
power_pmu.attr_groups = ppmu->attr_groups;
+ power_pmu.capabilities |= (ppmu->capabilities & PERF_PMU_CAP_EXTENDED_REGS);
#ifdef MSR_HV
/*
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
index a213a0a..9301e68 100644
--- a/arch/powerpc/perf/perf_regs.c
+++ b/arch/powerpc/perf/perf_regs.c
@@ -13,9 +13,11 @@
#include <asm/ptrace.h>
#include <asm/perf_regs.h>
+u64 PERF_REG_EXTENDED_MASK;
+
#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
-#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
+#define REG_RESERVED (~(PERF_REG_EXTENDED_MASK | PERF_REG_PMU_MASK))
static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
PT_REGS_OFFSET(PERF_REG_POWERPC_R0, gpr[0]),
@@ -69,10 +71,26 @@
PT_REGS_OFFSET(PERF_REG_POWERPC_MMCRA, dsisr),
};
+/* Function to return the extended register values */
+static u64 get_ext_regs_value(int idx)
+{
+ switch (idx) {
+ case PERF_REG_POWERPC_MMCR0:
+ return mfspr(SPRN_MMCR0);
+ case PERF_REG_POWERPC_MMCR1:
+ return mfspr(SPRN_MMCR1);
+ case PERF_REG_POWERPC_MMCR2:
+ return mfspr(SPRN_MMCR2);
+ default: return 0;
+ }
+}
+
u64 perf_reg_value(struct pt_regs *regs, int idx)
{
- if (WARN_ON_ONCE(idx >= PERF_REG_POWERPC_MAX))
- return 0;
+ u64 perf_reg_extended_max = PERF_REG_POWERPC_MAX;
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300))
+ perf_reg_extended_max = PERF_REG_MAX_ISA_300;
if (idx == PERF_REG_POWERPC_SIER &&
(IS_ENABLED(CONFIG_FSL_EMB_PERF_EVENT) ||
@@ -85,6 +103,16 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
IS_ENABLED(CONFIG_PPC32)))
return 0;
+ if (idx >= PERF_REG_POWERPC_MAX && idx < perf_reg_extended_max)
+ return get_ext_regs_value(idx);
+
+ /*
+ * If the idx is referring to value beyond the
+ * supported registers, return 0 with a warning
+ */
+ if (WARN_ON_ONCE(idx >= perf_reg_extended_max))
+ return 0;
+
return regs_get_register(regs, pt_regs_offset[idx]);
}
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 05dae38..2a57e93 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -90,6 +90,8 @@ enum {
#define POWER9_MMCRA_IFM3 0x00000000C0000000UL
#define POWER9_MMCRA_BHRB_MASK 0x00000000C0000000UL
+extern u64 PERF_REG_EXTENDED_MASK;
+
/* Nasty Power9 specific hack */
#define PVR_POWER9_CUMULUS 0x00002000
@@ -434,6 +436,7 @@ static void power9_config_bhrb(u64 pmu_bhrb_filter)
.cache_events = &power9_cache_events,
.attr_groups = power9_pmu_attr_groups,
.bhrb_nr = 32,
+ .capabilities = PERF_PMU_CAP_EXTENDED_REGS,
};
int init_power9_pmu(void)
@@ -457,6 +460,9 @@ int init_power9_pmu(void)
}
}
+ /* Set the PERF_REG_EXTENDED_MASK here */
+ PERF_REG_EXTENDED_MASK = PERF_REG_PMU_MASK_300;
+
rc = register_power_pmu(&power9_pmu);
if (rc)
return rc;
--
1.8.3.1
^ permalink raw reply related
* [PATCH V6 2/2] powerpc/perf: Add extended regs support for power10 platform
From: Athira Rajeev @ 2020-08-07 10:05 UTC (permalink / raw)
To: mpe; +Cc: ravi.bangoria, mikey, maddy, kjain, acme, jolsa, linuxppc-dev
In-Reply-To: <1596794701-23530-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Include capability flag `PERF_PMU_CAP_EXTENDED_REGS` for power10
and expose MMCR3, SIER2, SIER3 registers as part of extended regs.
Also introduce `PERF_REG_PMU_MASK_31` to define extended mask
value at runtime for power10
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
[Fix build failure on PPC32 platform]
Suggested-by: Ryan Grimm <grimm@linux.ibm.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Nageswara R Sastry <nasastry@in.ibm.com>
Reviewed-and-tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
arch/powerpc/include/uapi/asm/perf_regs.h | 6 ++++++
arch/powerpc/perf/perf_regs.c | 12 +++++++++++-
arch/powerpc/perf/power10-pmu.c | 6 ++++++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h b/arch/powerpc/include/uapi/asm/perf_regs.h
index 225c64c..bdf5f10 100644
--- a/arch/powerpc/include/uapi/asm/perf_regs.h
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -52,6 +52,9 @@ enum perf_event_powerpc_regs {
PERF_REG_POWERPC_MMCR0,
PERF_REG_POWERPC_MMCR1,
PERF_REG_POWERPC_MMCR2,
+ PERF_REG_POWERPC_MMCR3,
+ PERF_REG_POWERPC_SIER2,
+ PERF_REG_POWERPC_SIER3,
/* Max regs without the extended regs */
PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
};
@@ -60,6 +63,9 @@ enum perf_event_powerpc_regs {
/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
+/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31 */
+#define PERF_REG_PMU_MASK_31 (((1ULL << (PERF_REG_POWERPC_SIER3 + 1)) - 1) - PERF_REG_PMU_MASK)
#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
+#define PERF_REG_MAX_ISA_31 (PERF_REG_POWERPC_SIER3 + 1)
#endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
index 9301e68..8e53f2f 100644
--- a/arch/powerpc/perf/perf_regs.c
+++ b/arch/powerpc/perf/perf_regs.c
@@ -81,6 +81,14 @@ static u64 get_ext_regs_value(int idx)
return mfspr(SPRN_MMCR1);
case PERF_REG_POWERPC_MMCR2:
return mfspr(SPRN_MMCR2);
+#ifdef CONFIG_PPC64
+ case PERF_REG_POWERPC_MMCR3:
+ return mfspr(SPRN_MMCR3);
+ case PERF_REG_POWERPC_SIER2:
+ return mfspr(SPRN_SIER2);
+ case PERF_REG_POWERPC_SIER3:
+ return mfspr(SPRN_SIER3);
+#endif
default: return 0;
}
}
@@ -89,7 +97,9 @@ u64 perf_reg_value(struct pt_regs *regs, int idx)
{
u64 perf_reg_extended_max = PERF_REG_POWERPC_MAX;
- if (cpu_has_feature(CPU_FTR_ARCH_300))
+ if (cpu_has_feature(CPU_FTR_ARCH_31))
+ perf_reg_extended_max = PERF_REG_MAX_ISA_31;
+ else if (cpu_has_feature(CPU_FTR_ARCH_300))
perf_reg_extended_max = PERF_REG_MAX_ISA_300;
if (idx == PERF_REG_POWERPC_SIER &&
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index f7cff7f..8314865 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -87,6 +87,8 @@
#define POWER10_MMCRA_IFM3 0x00000000C0000000UL
#define POWER10_MMCRA_BHRB_MASK 0x00000000C0000000UL
+extern u64 PERF_REG_EXTENDED_MASK;
+
/* Table of alternatives, sorted by column 0 */
static const unsigned int power10_event_alternatives[][MAX_ALT] = {
{ PM_RUN_CYC_ALT, PM_RUN_CYC },
@@ -397,6 +399,7 @@ static void power10_config_bhrb(u64 pmu_bhrb_filter)
.cache_events = &power10_cache_events,
.attr_groups = power10_pmu_attr_groups,
.bhrb_nr = 32,
+ .capabilities = PERF_PMU_CAP_EXTENDED_REGS,
};
int init_power10_pmu(void)
@@ -408,6 +411,9 @@ int init_power10_pmu(void)
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power10"))
return -ENODEV;
+ /* Set the PERF_REG_EXTENDED_MASK here */
+ PERF_REG_EXTENDED_MASK = PERF_REG_PMU_MASK_31;
+
rc = register_power_pmu(&power10_pmu);
if (rc)
return rc;
--
1.8.3.1
^ permalink raw reply related
* [PATCH V6 0/2] powerpc/perf: Add support for perf extended regs in powerpc
From: Athira Rajeev @ 2020-08-07 10:04 UTC (permalink / raw)
To: mpe; +Cc: ravi.bangoria, mikey, maddy, kjain, acme, jolsa, linuxppc-dev
Patch set to add support for perf extended register capability in
powerpc. The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to
indicate the PMU which support extended registers. The generic code
define the mask of extended registers as 0 for non supported architectures.
patch 1/2 defines the PERF_PMU_CAP_EXTENDED_REGS mask to output the
values of mmcr0,mmcr1,mmcr2 for POWER9. Defines `PERF_REG_EXTENDED_MASK`
at runtime which contains mask value of the supported registers under
extended regs.
patch 2/2 adds the extended regs support for power10 and exposes
MMCR3, SIER2, SIER3 registers as part of extended regs.
This patch series is based on powerpc/next and includes the kernel
side changes to support extended regs. perf tools side changes will
be sent as separate patchset.
Changelog:
Changes from v5 -> v6
- Split kernel changes to one patchset as suggested by
Arnaldo
Link to previous series:
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=192624
Changes from v4 -> v5
- initialize `perf_reg_extended_max` to work on
all platforms as suggested by Ravi Bangoria
- Added Reviewed-and-Tested-by from Ravi Bangoria
Changes from v3 -> v4
- Split the series and send extended regs as separate patch set here.
Link to previous series :
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=190462&state=*
Other PMU patches are already merged in powerpc/next.
- Fixed kernel build issue when using config having
CONFIG_PERF_EVENTS set and without CONFIG_PPC_PERF_CTRS
reported by kernel build bot.
- Included Reviewed-by from Kajol Jain.
- Addressed review comments from Ravi Bangoria to initialize `perf_reg_extended_max`
and define it in lowercase since it is local variable.
Anju T Sudhakar (1):
powerpc/perf: Add support for outputting extended regs in perf
intr_regs
Athira Rajeev (1):
powerpc/perf: Add extended regs support for power10 platform
arch/powerpc/include/asm/perf_event.h | 3 ++
arch/powerpc/include/asm/perf_event_server.h | 5 ++++
arch/powerpc/include/uapi/asm/perf_regs.h | 20 ++++++++++++-
arch/powerpc/perf/core-book3s.c | 1 +
arch/powerpc/perf/perf_regs.c | 44 ++++++++++++++++++++++++++--
arch/powerpc/perf/power10-pmu.c | 6 ++++
arch/powerpc/perf/power9-pmu.c | 6 ++++
7 files changed, 81 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
From: Michal Suchánek @ 2020-08-07 10:04 UTC (permalink / raw)
To: David Hildenbrand
Cc: Gautham R Shenoy, Andi Kleen, Srikar Dronamraju, Linus Torvalds,
linux-kernel, Michal Hocko, linux-mm, Satheesh Rajendran,
Mel Gorman, Kirill A. Shutemov, Andrew Morton, linuxppc-dev,
Christopher Lameter, Vlastimil Babka
In-Reply-To: <5688b358-36bc-ccf0-d24b-a65375a9f3c3@redhat.com>
On Fri, Aug 07, 2020 at 08:58:09AM +0200, David Hildenbrand wrote:
> On 07.08.20 06:32, Andrew Morton wrote:
> > On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
> >
> >>> The memory hotplug changes that somehow because you can hotremove numa
> >>> nodes and therefore make the nodemask sparse but that is not a common
> >>> case. I am not sure what would happen if a completely new node was added
> >>> and its corresponding node was already used by the renumbered one
> >>> though. It would likely conflate the two I am afraid. But I am not sure
> >>> this is really possible with x86 and a lack of a bug report would
> >>> suggest that nobody is doing that at least.
> >>>
> >>
> >> JFYI,
> >> Satheesh copied in this mailchain had opened a bug a year on crash with vcpu
> >> hotplug on memoryless node.
> >>
> >> https://bugzilla.kernel.org/show_bug.cgi?id=202187
> >
> > So... do we merge this patch or not? Seems that the overall view is
> > "risky but nobody is likely to do anything better any time soon"?
>
> I recall the issue Michal saw was "fix powerpc" vs. "break other
> architectures". @Michal how should we proceed? At least x86-64 won't be
> affected IIUC.
There is a patch to introduce the node remapping on ppc as well which
should eliminate the empty node 0.
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200731111916.243569-1-aneesh.kumar@linux.ibm.com/
Thanks
Michal
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/pci: unmap all interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-08-07 10:02 UTC (permalink / raw)
To: Alexey Kardashevskiy, Michael Ellerman
Cc: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <5d5e128d-ac5f-1003-0b3f-3017c612e1ea@ozlabs.ru>
On 8/7/20 8:01 AM, Alexey Kardashevskiy wrote:
>
>
> On 18/06/2020 02:29, Cédric Le Goater wrote:
>> Some PCI adapters, like GPUs, use the "interrupt-map" property to
>> describe interrupt mappings other than the legacy INTx interrupts.
>> There can be more than 4 mappings.
>>
>> To clear all interrupts when a PHB is removed, we need to increase the
>> 'irq_map' array in which mappings are recorded. Compute the number of
>> interrupt mappings from the "interrupt-map" property and allocate a
>> bigger 'irq_map' array.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> arch/powerpc/kernel/pci-common.c | 49 +++++++++++++++++++++++++++++++-
>> 1 file changed, 48 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>> index 515480a4bac6..deb831f0ae13 100644
>> --- a/arch/powerpc/kernel/pci-common.c
>> +++ b/arch/powerpc/kernel/pci-common.c
>> @@ -353,9 +353,56 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
>> return NULL;
>> }
>>
>> +/*
>> + * Assumption is made on the interrupt parent. All interrupt-map
>> + * entries are considered to have the same parent.
>> + */
>> +static int pcibios_irq_map_count(struct pci_controller *phb)
>
> I wonder if
> int of_irq_count(struct device_node *dev)
> could work here too. If it does not, then never mind.
I wished it would, but no.
> Other than that, the only other comment is - merge this one into 1/2 as
> 1/2 alone won't properly fix the problem but it may look like that it does:
>
> for phyp, the test machine just happens to have 4 entries in the map but
> this is the phyp implementation detail;
yes
> for qemu, there are more but we only unregister 4 but kvm does not care
> in general so it is ok which is also implementation detail;
>
> and 2/2 just makes these details not matter. Thanks,
OK. It will ease backport. Sending a v2.
Thanks for the review Alexey !
C.
>
>
>> +{
>> + const __be32 *imap;
>> + int imaplen;
>> + struct device_node *parent;
>> + u32 intsize, addrsize, parintsize, paraddrsize;
>> +
>> + if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
>> + return 0;
>> + if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
>> + return 0;
>> +
>> + imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
>> + if (!imap) {
>> + pr_debug("%pOF : no interrupt-map\n", phb->dn);
>> + return 0;
>> + }
>> + imaplen /= sizeof(u32);
>> + pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
>> +
>> + if (imaplen < (addrsize + intsize + 1))
>> + return 0;
>> +
>> + imap += intsize + addrsize;
>> + parent = of_find_node_by_phandle(be32_to_cpup(imap));
>> + if (!parent) {
>> + pr_debug("%pOF : no imap parent found !\n", phb->dn);
>> + return 0;
>> + }
>> +
>> + if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
>> + pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
>> + return 0;
>> + }
>> +
>> + if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
>> + paraddrsize = 0;
>> +
>> + return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
>> +}
>> +
>> static void pcibios_irq_map_init(struct pci_controller *phb)
>> {
>> - phb->irq_count = PCI_NUM_INTX;
>> + phb->irq_count = pcibios_irq_map_count(phb);
>> + if (phb->irq_count < PCI_NUM_INTX)
>> + phb->irq_count = PCI_NUM_INTX;
>>
>> pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
>>
>>
>
^ permalink raw reply
* [PATCH] ASoC: fsl_sai: Add -EPROBE_DEFER check for regmap init
From: Shengjiu Wang @ 2020-08-07 9:14 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
Regmap initialization may return -EPROBE_DEFER for clock
may not be ready, so check -EPROBE_DEFER error type before
start another Regmap initialization.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_sai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index a22562f2df47..eb933fe9b6d1 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -927,7 +927,7 @@ static int fsl_sai_probe(struct platform_device *pdev)
"bus", base, &fsl_sai_regmap_config);
/* Compatible with old DTB cases */
- if (IS_ERR(sai->regmap))
+ if (IS_ERR(sai->regmap) && PTR_ERR(sai->regmap) != -EPROBE_DEFER)
sai->regmap = devm_regmap_init_mmio_clk(&pdev->dev,
"sai", base, &fsl_sai_regmap_config);
if (IS_ERR(sai->regmap)) {
--
2.27.0
^ permalink raw reply related
* [PATCH v2 2/2] powerpc/topology: Override cpu_smt_mask
From: Srikar Dronamraju @ 2020-08-07 7:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Peter Zijlstra, Mel Gorman, LKML,
Valentin Schneider, linuxppc-dev, Ingo Molnar, Dietmar Eggemann
In-Reply-To: <20200807074517.27957-1-srikar@linux.vnet.ibm.com>
On Power9, a pair of SMT4 cores can be presented by the firmware as a SMT8
core for backward compatibility reasons, with the fusion of two SMT4 cores.
Powerpc allows LPARs to be live migrated from Power8 to Power9. Existing
software developed/configured for Power8, expects to see a SMT8 core.
In order to maintain userspace backward compatibility (with Power8 chips in
case of Power9) in enterprise Linux systems, the topology_sibling_cpumask
has to be set to SMT8 core.
cpu_smt_mask() should generally point to the cpu mask of the SMT4 core.
Hence override the default cpu_smt_mask() to be powerpc specific
allowing for better scheduling behaviour on Power.
schbench
(latency measured in usecs, so lesser is better)
Without patch With patch
Latency percentiles (usec) Latency percentiles (usec)
50.0000th: 34 50.0000th: 38
75.0000th: 47 75.0000th: 52
90.0000th: 54 90.0000th: 60
95.0000th: 57 95.0000th: 64
*99.0000th: 62 *99.0000th: 72
99.5000th: 65 99.5000th: 75
99.9000th: 76 99.9000th: 3452
min=0, max=9205 min=0, max=9344
schbench (With Cede disabled)
Without patch With patch
Latency percentiles (usec) Latency percentiles (usec)
50.0000th: 20 50.0000th: 21
75.0000th: 28 75.0000th: 29
90.0000th: 33 90.0000th: 34
95.0000th: 35 95.0000th: 37
*99.0000th: 40 *99.0000th: 40
99.5000th: 48 99.5000th: 42
99.9000th: 94 99.9000th: 79
min=0, max=791 min=0, max=791
perf bench sched pipe
usec/ops : lesser is better
Without patch
N Min Max Median Avg Stddev
101 5.095113 5.595269 5.204842 5.2298776 0.10762713
5.10 - 5.15 : ################################################## 23% (24)
5.15 - 5.20 : ############################################# 21% (22)
5.20 - 5.25 : ################################################## 23% (24)
5.25 - 5.30 : ######################### 11% (12)
5.30 - 5.35 : ########## 4% (5)
5.35 - 5.40 : ######## 3% (4)
5.40 - 5.45 : ######## 3% (4)
5.45 - 5.50 : #### 1% (2)
5.50 - 5.55 : ## 0% (1)
5.55 - 5.60 : #### 1% (2)
With patch
N Min Max Median Avg Stddev
101 5.134675 8.524719 5.207658 5.2780985 0.34911969
5.1 - 5.5 : ################################################## 94% (95)
5.5 - 5.8 : ## 3% (4)
5.8 - 6.2 : 0% (1)
6.2 - 6.5 :
6.5 - 6.8 :
6.8 - 7.2 :
7.2 - 7.5 :
7.5 - 7.8 :
7.8 - 8.2 :
8.2 - 8.5 :
perf bench sched pipe (cede disabled)
usec/ops : lesser is better
Without patch
N Min Max Median Avg Stddev
101 7.884227 12.576538 7.956474 8.0170722 0.46159054
7.9 - 8.4 : ################################################## 99% (100)
8.4 - 8.8 :
8.8 - 9.3 :
9.3 - 9.8 :
9.8 - 10.2 :
10.2 - 10.7 :
10.7 - 11.2 :
11.2 - 11.6 :
11.6 - 12.1 :
12.1 - 12.6 :
With patch
N Min Max Median Avg Stddev
101 7.956021 8.217284 8.015615 8.0283866 0.049844967
7.96 - 7.98 : ###################### 12% (13)
7.98 - 8.01 : ################################################## 28% (29)
8.01 - 8.03 : #################################### 20% (21)
8.03 - 8.06 : ######################### 14% (15)
8.06 - 8.09 : ###################### 12% (13)
8.09 - 8.11 : ###### 3% (4)
8.11 - 8.14 : ### 1% (2)
8.14 - 8.17 : ### 1% (2)
8.17 - 8.19 :
8.19 - 8.22 : # 0% (1)
Observations: With the patch, the initial run/iteration takes a slight
longer time. This can be attributed to the fact that now we pick a CPU
from a idle core which could be sleep mode. Once we remove the cede,
state the numbers improve in favour of the patch.
ebizzy:
transactions per second (higher is better)
without patch
N Min Max Median Avg Stddev
100 1018433 1304470 1193208 1182315.7 60018.733
1018433 - 1047037 : ###### 3% (3)
1047037 - 1075640 : ######## 4% (4)
1075640 - 1104244 : ######## 4% (4)
1104244 - 1132848 : ############### 7% (7)
1132848 - 1161452 : #################################### 17% (17)
1161452 - 1190055 : ########################## 12% (12)
1190055 - 1218659 : ############################################# 21% (21)
1218659 - 1247263 : ################################################## 23% (23)
1247263 - 1275866 : ######## 4% (4)
1275866 - 1304470 : ######## 4% (4)
with patch
N Min Max Median Avg Stddev
100 967014 1292938 1208819 1185281.8 69815.851
967014 - 999606 : ## 1% (1)
999606 - 1032199 : ## 1% (1)
1032199 - 1064791 : ############ 6% (6)
1064791 - 1097384 : ########## 5% (5)
1097384 - 1129976 : ################## 9% (9)
1129976 - 1162568 : #################### 10% (10)
1162568 - 1195161 : ########################## 13% (13)
1195161 - 1227753 : ############################################ 22% (22)
1227753 - 1260346 : ################################################## 25% (25)
1260346 - 1292938 : ############## 7% (7)
Observations: Not much changes, ebizzy is not much impacted.
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
---
Changelog v1->v2:
Modified commit msg as per mailing list discussion.
Added performance numbers
arch/powerpc/include/asm/cputhreads.h | 1 -
arch/powerpc/include/asm/smp.h | 13 +++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h
index deb99fd6e060..98c8bd155bf9 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -23,7 +23,6 @@
extern int threads_per_core;
extern int threads_per_subcore;
extern int threads_shift;
-extern bool has_big_cores;
extern cpumask_t threads_core_mask;
#else
#define threads_per_core 1
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 9cd0765633c5..bb06aa875131 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -131,6 +131,19 @@ static inline struct cpumask *cpu_smallcore_mask(int cpu)
extern int cpu_to_core_id(int cpu);
+extern bool has_big_cores;
+
+#define cpu_smt_mask cpu_smt_mask
+#ifdef CONFIG_SCHED_SMT
+static inline const struct cpumask *cpu_smt_mask(int cpu)
+{
+ if (has_big_cores)
+ return per_cpu(cpu_smallcore_map, cpu);
+
+ return per_cpu(cpu_sibling_map, cpu);
+}
+#endif /* CONFIG_SCHED_SMT */
+
/* Since OpenPIC has only 4 IPIs, we use slightly different message numbers.
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
--
2.18.2
^ permalink raw reply related
* [PATCH v2 1/2] sched/topology: Allow archs to override cpu_smt_mask
From: Srikar Dronamraju @ 2020-08-07 7:45 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R Shenoy, Michael Neuling, Vincent Guittot,
Srikar Dronamraju, Peter Zijlstra, Mel Gorman, LKML,
Valentin Schneider, linuxppc-dev, Ingo Molnar, Dietmar Eggemann
cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
most architectures. One of the users of cpu_smt_mask(), would be to
identify idle-cores. On Power9, a pair of SMT4 cores can be presented by
the firmware as a SMT8 core for backward compatibility reasons.
Powerpc allows LPARs to be live migrated from Power8 to Power9. Do note
Power8 had only SMT8 cores. Existing software which has been
developed/configured for Power8 would expect to see SMT8 core.
Maintaining the illusion of SMT8 core is a requirement to make that
work.
In order to maintain above userspace backward compatibility with
previous versions of processor, Power9 onwards there is option to the
firmware to advertise a pair of SMT4 cores as a fused cores aka SMT8
core. On Power9 this pair shares the L2 cache as well. However, from the
scheduler's point of view, a core should be determined by SMT4, since
its a completely independent unit of compute. Hence allow PowerPc
architecture to override the default cpu_smt_mask() to point to the SMT4
cores in a SMT8 mode.
This will ensure the scheduler is always given the right information.
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Gautham R Shenoy <ego@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Valentin Schneider <valentin.schneider@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Vaidyanathan Srinivasan <svaidy@linux.ibm.com>
Acked-by; Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
---
Changelog v1->v2:
Update the commit msg based on the discussion in community esp
with Peter Zijlstra and Michael Ellerman.
include/linux/topology.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 608fa4aadf0e..ad03df1cc266 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -198,7 +198,7 @@ static inline int cpu_to_mem(int cpu)
#define topology_die_cpumask(cpu) cpumask_of(cpu)
#endif
-#ifdef CONFIG_SCHED_SMT
+#if defined(CONFIG_SCHED_SMT) && !defined(cpu_smt_mask)
static inline const struct cpumask *cpu_smt_mask(int cpu)
{
return topology_sibling_cpumask(cpu);
--
2.18.2
^ permalink raw reply related
* Re: [PATCH] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
From: Shengjiu Wang @ 2020-08-07 7:17 UTC (permalink / raw)
To: Mark Brown
Cc: Linux-ALSA, Timur Tabi, Xiubo Li, Fabio Estevam, Shengjiu Wang,
Takashi Iwai, Liam Girdwood, Nicolin Chen, linuxppc-dev,
linux-kernel
In-Reply-To: <20200806123721.GC6442@sirena.org.uk>
On Thu, Aug 6, 2020 at 8:39 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Aug 06, 2020 at 03:39:45PM +0800, Shengjiu Wang wrote:
>
> > } else if (of_node_name_eq(cpu_np, "esai")) {
> > + struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
> > +
> > + if (!IS_ERR(esai_clk)) {
> > + priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
> > + priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);
> > + clk_put(esai_clk);
> > + }
>
> This should handle probe deferral. Also if this clock is in use
> shouldn't we be enabling it? It looks like it's intended to be a
> crystal so it's probably forced on all the time but sometimes there's
> power control for crystals, or perhaps someone might do something
> unusual with the hardware.
Ok, will add handler for probe deferral.
This clock is not a crystal, "extal" clock is for cpu dai, it is from
soc internal PLL. which is enabled by cpu dai, here is just to
get the clock rate.
best regards
wang shengjiu
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/hotplug-cpu: increase wait time for vCPU death
From: Nathan Lynch @ 2020-08-07 7:05 UTC (permalink / raw)
To: Michael Ellerman
Cc: Greg Kurz, linuxppc-dev, Michael Roth, Thiago Jung Bauermann,
Cedric Le Goater
In-Reply-To: <87zh79yen7.fsf@mpe.ellerman.id.au>
Hi everyone,
Michael Ellerman <mpe@ellerman.id.au> writes:
> Greg Kurz <groug@kaod.org> writes:
>> On Tue, 04 Aug 2020 23:35:10 +1000
>> Michael Ellerman <mpe@ellerman.id.au> wrote:
>>> Spinning forever seems like a bad idea, but as has been demonstrated at
>>> least twice now, continuing when we don't know the state of the other
>>> CPU can lead to straight up crashes.
>>>
>>> So I think I'm persuaded that it's preferable to have the kernel stuck
>>> spinning rather than oopsing.
>>>
>>
>> +1
>>
>>> I'm 50/50 on whether we should have a cond_resched() in the loop. My
>>> first instinct is no, if we're stuck here for 20s a stack trace would be
>>> good. But then we will probably hit that on some big and/or heavily
>>> loaded machine.
>>>
>>> So possibly we should call cond_resched() but have some custom logic in
>>> the loop to print a warning if we are stuck for more than some
>>> sufficiently long amount of time.
>>
>> How long should that be ?
>
> Yeah good question.
>
> I guess step one would be seeing how long it can take on the 384 vcpu
> machine. And we can probably test on some other big machines.
>
> Hopefully Nathan can give us some idea of how long he's seen it take on
> large systems? I know he was concerned about the 20s timeout of the
> softlockup detector.
Maybe I'm not quite clear what this is referring to, but I don't think
stop-self/query-stopped-state latency increases with processor count, at
least not on PowerVM. And IIRC I was concerned with the earlier patch's
potential for causing the softlockup watchdog to rightly complain by
polling the stopped state without ever scheduling away.
The fact that smp_query_cpu_stopped() kind of collapses the two distinct
results from the query-cpu-stopped-state RTAS call into one return value
may make it harder than necessary to reason about the questions around
cond_resched() and whether to warn.
Sorry to pull this stunt but I have had some code sitting in a neglected
branch that I think gets the logic around this right.
What we should have is a simple C wrapper for the RTAS call that reflects the
architected inputs and outputs:
================================================================
(-- rtas.c --)
/**
* rtas_query_cpu_stopped_state() - Call RTAS query-cpu-stopped-state.
* @hwcpu: Identifies the processor thread to be queried.
* @status: Pointer to status, valid only on success.
*
* Determine whether the given processor thread is in the stopped
* state. If successful and @status is non-NULL, the thread's status
* is stored to @status.
*
* Return:
* * 0 - Success
* * -1 - Hardware error
* * -2 - Busy, try again later
*/
int rtas_query_cpu_stopped_state(unsigned int hwcpu, unsigned int *status)
{
unsigned int cpu_status;
int token;
int fwrc;
token = rtas_token("query-cpu-stopped-state");
fwrc = rtas_call(token, 1, 2, &cpu_status, hwcpu);
if (fwrc != 0)
goto out;
if (status != NULL)
*status = cpu_status;
out:
return fwrc;
}
================================================================
And then a utility function that waits for the remote thread to enter
stopped state, with higher-level logic for rescheduling and warning. The
fact that smp_query_cpu_stopped() currently does not handle a -2/busy
status is a bug, fixed below by using rtas_busy_delay(). Note the
justification for the explicit cond_resched() in the outer loop:
================================================================
(-- rtas.h --)
/* query-cpu-stopped-state CPU_status */
#define RTAS_QCSS_STATUS_STOPPED 0
#define RTAS_QCSS_STATUS_IN_PROGRESS 1
#define RTAS_QCSS_STATUS_NOT_STOPPED 2
(-- pseries/hotplug-cpu.c --)
/**
* wait_for_cpu_stopped() - Wait for a cpu to enter RTAS stopped state.
*/
static void wait_for_cpu_stopped(unsigned int cpu)
{
unsigned int status;
unsigned int hwcpu;
hwcpu = get_hard_smp_processor_id(cpu);
do {
int fwrc;
/*
* rtas_busy_delay() will yield only if RTAS returns a
* busy status. Since query-cpu-stopped-state can
* yield RTAS_QCSS_STATUS_IN_PROGRESS or
* RTAS_QCSS_STATUS_NOT_STOPPED for an unbounded
* period before the target thread stops, we must take
* care to explicitly reschedule while polling.
*/
cond_resched();
do {
fwrc = rtas_query_cpu_stopped_state(hwcpu, &status);
} while (rtas_busy_delay(fwrc));
if (fwrc == 0)
continue;
pr_err_ratelimited("query-cpu-stopped-state for "
"thread 0x%x returned %d\n",
hwcpu, fwrc);
goto out;
} while (status == RTAS_QCSS_STATUS_NOT_STOPPED ||
status == RTAS_QCSS_STATUS_IN_PROGRESS);
if (status != RTAS_QCSS_STATUS_STOPPED) {
pr_err_ratelimited("query-cpu-stopped-state yielded unknown "
"status %d for thread 0x%x\n",
status, hwcpu);
}
out:
return;
}
[...]
static void pseries_cpu_die(unsigned int cpu)
{
wait_for_cpu_stopped(cpu);
paca_ptrs[cpu]->cpu_start = 0;
}
================================================================
wait_for_cpu_stopped() should be able to accommodate a time-based
warning if necessary, but speaking as a likely recipient of any bug
reports that would arise here, I'm not convinced of the need and I
don't know what a good value would be. It's relatively easy to sample
the stack of a task that's apparently failing to make progress, plus I
probably would use 'perf probe' or similar to report the inputs and
outputs for the RTAS call.
I'm happy to make this a proper submission after I can clean it up and
retest it, or Michael R. is welcome to appropriate it, assuming it's
acceptable.
^ permalink raw reply
* Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
From: David Hildenbrand @ 2020-08-07 6:58 UTC (permalink / raw)
To: Andrew Morton, Srikar Dronamraju
Cc: Gautham R Shenoy, Andi Kleen, linuxppc-dev, linux-kernel,
Michal Hocko, linux-mm, Satheesh Rajendran, Mel Gorman,
Kirill A. Shutemov, Christopher Lameter, Michal Such?nek,
Linus Torvalds, Vlastimil Babka
In-Reply-To: <20200806213211.6a6a56037fe771836e5abbe9@linux-foundation.org>
On 07.08.20 06:32, Andrew Morton wrote:
> On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
>
>>> The memory hotplug changes that somehow because you can hotremove numa
>>> nodes and therefore make the nodemask sparse but that is not a common
>>> case. I am not sure what would happen if a completely new node was added
>>> and its corresponding node was already used by the renumbered one
>>> though. It would likely conflate the two I am afraid. But I am not sure
>>> this is really possible with x86 and a lack of a bug report would
>>> suggest that nobody is doing that at least.
>>>
>>
>> JFYI,
>> Satheesh copied in this mailchain had opened a bug a year on crash with vcpu
>> hotplug on memoryless node.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=202187
>
> So... do we merge this patch or not? Seems that the overall view is
> "risky but nobody is likely to do anything better any time soon"?
I recall the issue Michal saw was "fix powerpc" vs. "break other
architectures". @Michal how should we proceed? At least x86-64 won't be
affected IIUC.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc/pci: unmap all interrupts when a PHB is removed
From: Alexey Kardashevskiy @ 2020-08-07 6:01 UTC (permalink / raw)
To: Cédric Le Goater, Michael Ellerman
Cc: Oliver O'Halloran, linuxppc-dev
In-Reply-To: <20200617162938.743439-3-clg@kaod.org>
On 18/06/2020 02:29, Cédric Le Goater wrote:
> Some PCI adapters, like GPUs, use the "interrupt-map" property to
> describe interrupt mappings other than the legacy INTx interrupts.
> There can be more than 4 mappings.
>
> To clear all interrupts when a PHB is removed, we need to increase the
> 'irq_map' array in which mappings are recorded. Compute the number of
> interrupt mappings from the "interrupt-map" property and allocate a
> bigger 'irq_map' array.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/kernel/pci-common.c | 49 +++++++++++++++++++++++++++++++-
> 1 file changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index 515480a4bac6..deb831f0ae13 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,9 +353,56 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +/*
> + * Assumption is made on the interrupt parent. All interrupt-map
> + * entries are considered to have the same parent.
> + */
> +static int pcibios_irq_map_count(struct pci_controller *phb)
I wonder if
int of_irq_count(struct device_node *dev)
could work here too. If it does not, then never mind.
Other than that, the only other comment is - merge this one into 1/2 as
1/2 alone won't properly fix the problem but it may look like that it does:
for phyp, the test machine just happens to have 4 entries in the map but
this is the phyp implementation detail;
for qemu, there are more but we only unregister 4 but kvm does not care
in general so it is ok which is also implementation detail;
and 2/2 just makes these details not matter. Thanks,
> +{
> + const __be32 *imap;
> + int imaplen;
> + struct device_node *parent;
> + u32 intsize, addrsize, parintsize, paraddrsize;
> +
> + if (of_property_read_u32(phb->dn, "#interrupt-cells", &intsize))
> + return 0;
> + if (of_property_read_u32(phb->dn, "#address-cells", &addrsize))
> + return 0;
> +
> + imap = of_get_property(phb->dn, "interrupt-map", &imaplen);
> + if (!imap) {
> + pr_debug("%pOF : no interrupt-map\n", phb->dn);
> + return 0;
> + }
> + imaplen /= sizeof(u32);
> + pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
> +
> + if (imaplen < (addrsize + intsize + 1))
> + return 0;
> +
> + imap += intsize + addrsize;
> + parent = of_find_node_by_phandle(be32_to_cpup(imap));
> + if (!parent) {
> + pr_debug("%pOF : no imap parent found !\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#interrupt-cells", &parintsize)) {
> + pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#address-cells", ¶ddrsize))
> + paraddrsize = 0;
> +
> + return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
> +}
> +
> static void pcibios_irq_map_init(struct pci_controller *phb)
> {
> - phb->irq_count = PCI_NUM_INTX;
> + phb->irq_count = pcibios_irq_map_count(phb);
> + if (phb->irq_count < PCI_NUM_INTX)
> + phb->irq_count = PCI_NUM_INTX;
>
> pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
>
>
--
Alexey
^ permalink raw reply
* Re: [RFC PATCH 1/2] powerpc/numa: Introduce logical numa id
From: Aneesh Kumar K.V @ 2020-08-07 5:02 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Srikar Dronamraju
In-Reply-To: <87pn83ytet.fsf@linux.ibm.com>
On 8/7/20 9:54 AM, Nathan Lynch wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index e437a9ac4956..6c659aada55b 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -221,25 +221,51 @@ static void initialize_distance_lookup_table(int nid,
>> }
>> }
>>
>> +static u32 nid_map[MAX_NUMNODES] = {[0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE};
>
> It's odd to me to use MAX_NUMNODES for this array when it's going to be
> indexed not by Linux's logical node IDs but by the platform-provided
> domain number, which has no relation to MAX_NUMNODES.
I didn't want to dynamically allocate this. We could fetch
"ibm,max-associativity-domains" to find the size for that. The current
code do assume firmware group id to not exceed MAX_NUMNODES. Hence kept
the array size to be MAX_NUMNODEs. I do agree that it is confusing. May
be we can do #define MAX_AFFINITY_DOMAIN MAX_NUMNODES?
>
>> +
>> +int firmware_group_id_to_nid(int firmware_gid)
>> +{
>> + static int last_nid = 0;
>> +
>> + /*
>> + * For PowerNV we don't change the node id. This helps to avoid
>> + * confusion w.r.t the expected node ids. On pseries, node numbers
>> + * are virtualized. Hence do logical node id for pseries.
>> + */
>> + if (!firmware_has_feature(FW_FEATURE_LPAR))
>> + return firmware_gid;
>> +
>> + if (firmware_gid == -1)
>> + return NUMA_NO_NODE;
>> +
>> + if (nid_map[firmware_gid] == NUMA_NO_NODE)
>> + nid_map[firmware_gid] = last_nid++;
>
> This should at least be bounds-checked in case of domain numbering in
> excess of MAX_NUMNODES. Or a different data structure should be used?
> Not sure.
>
> I'd prefer Linux's logical node type not be easily interchangeable with
> the firmware node/group id type. The firmware type could be something
> like:
>
> struct affinity_domain {
> u32 val;
> };
> typedef struct affinity_domain affinity_domain_t;
>
> with appropriate accessors/APIs.
>
That is a good idea. Will use this.
-aneesh
^ permalink raw reply
* Re: [PATCH v5 3/3] mm/page_alloc: Keep memoryless cpuless node 0 offline
From: Andrew Morton @ 2020-08-07 4:32 UTC (permalink / raw)
To: Srikar Dronamraju
Cc: Gautham R Shenoy, Andi Kleen, David Hildenbrand, linuxppc-dev,
linux-kernel, Michal Hocko, linux-mm, Satheesh Rajendran,
Mel Gorman, Kirill A. Shutemov, Christopher Lameter,
Michal Such?nek, Linus Torvalds, Vlastimil Babka
In-Reply-To: <20200703125823.GA26243@linux.vnet.ibm.com>
On Fri, 3 Jul 2020 18:28:23 +0530 Srikar Dronamraju <srikar@linux.vnet.ibm.com> wrote:
> > The memory hotplug changes that somehow because you can hotremove numa
> > nodes and therefore make the nodemask sparse but that is not a common
> > case. I am not sure what would happen if a completely new node was added
> > and its corresponding node was already used by the renumbered one
> > though. It would likely conflate the two I am afraid. But I am not sure
> > this is really possible with x86 and a lack of a bug report would
> > suggest that nobody is doing that at least.
> >
>
> JFYI,
> Satheesh copied in this mailchain had opened a bug a year on crash with vcpu
> hotplug on memoryless node.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=202187
So... do we merge this patch or not? Seems that the overall view is
"risky but nobody is likely to do anything better any time soon"?
^ permalink raw reply
* Re: [RFC PATCH 1/2] powerpc/numa: Introduce logical numa id
From: Nathan Lynch @ 2020-08-07 4:24 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev, Srikar Dronamraju
In-Reply-To: <20200731111916.243569-1-aneesh.kumar@linux.ibm.com>
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com> writes:
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index e437a9ac4956..6c659aada55b 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -221,25 +221,51 @@ static void initialize_distance_lookup_table(int nid,
> }
> }
>
> +static u32 nid_map[MAX_NUMNODES] = {[0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE};
It's odd to me to use MAX_NUMNODES for this array when it's going to be
indexed not by Linux's logical node IDs but by the platform-provided
domain number, which has no relation to MAX_NUMNODES.
> +
> +int firmware_group_id_to_nid(int firmware_gid)
> +{
> + static int last_nid = 0;
> +
> + /*
> + * For PowerNV we don't change the node id. This helps to avoid
> + * confusion w.r.t the expected node ids. On pseries, node numbers
> + * are virtualized. Hence do logical node id for pseries.
> + */
> + if (!firmware_has_feature(FW_FEATURE_LPAR))
> + return firmware_gid;
> +
> + if (firmware_gid == -1)
> + return NUMA_NO_NODE;
> +
> + if (nid_map[firmware_gid] == NUMA_NO_NODE)
> + nid_map[firmware_gid] = last_nid++;
This should at least be bounds-checked in case of domain numbering in
excess of MAX_NUMNODES. Or a different data structure should be used?
Not sure.
I'd prefer Linux's logical node type not be easily interchangeable with
the firmware node/group id type. The firmware type could be something
like:
struct affinity_domain {
u32 val;
};
typedef struct affinity_domain affinity_domain_t;
with appropriate accessors/APIs.
This can prevent a whole class of errors that is currently possible with
CPUs, since the logical and "hardware" ID types are both simple
integers.
^ permalink raw reply
* Re: [PATCH] powerpc/signal: Move and simplify get_clean_sp()
From: Michael Ellerman @ 2020-08-07 2:48 UTC (permalink / raw)
To: Christoph Hellwig, Christophe Leroy
Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <20200806092547.GA2544@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> On Thu, Aug 06, 2020 at 08:50:20AM +0000, Christophe Leroy wrote:
>> get_clean_sp() is only used in kernel/signal.c . Move it there.
>>
>> And GCC is smart enough to reduce the function when on PPC32, no
>> need of a special PPC32 simple version.
>
> What about just open coding it in the only caller, which would seem even
> cleaner?
+1
cheers
^ permalink raw reply
* Re: [PATCH v8 5/8] powerpc/vdso: Prepare for switching VDSO to generic C implementation.
From: Michael Ellerman @ 2020-08-07 2:44 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Christophe Leroy, nathanl, arnd, linux-kernel,
Tulio Magno Quites Machado Filho, Paul Mackerras, luto,
linux-arch, tglx, vincenzo.frascino, linuxppc-dev
In-Reply-To: <20200806183316.GV6753@gate.crashing.org>
Segher Boessenkool <segher@kernel.crashing.org> writes:
> On Thu, Aug 06, 2020 at 12:03:33PM +1000, Michael Ellerman wrote:
>> Segher Boessenkool <segher@kernel.crashing.org> writes:
>> > On Wed, Aug 05, 2020 at 04:24:16PM +1000, Michael Ellerman wrote:
>> >> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
>> >> > Indeed, 32-bit doesn't have a redzone, so I believe it needs a stack
>> >> > frame whenever it has anything to same.
>
> ^^^
>
>> >> > fbb60: 94 21 ff e0 stwu r1,-32(r1)
>> >
>> > This is the *only* place where you can use a negative offset from r1:
>> > in the stwu to extend the stack (set up a new stack frame, or make the
>> > current one bigger).
>>
>> (You're talking about 32-bit code here right?)
>
> The "SYSV" ELF binding, yeah, which is used for 32-bit on Linux (give or
> take, ho hum).
>
> The ABIs that have a red zone are much nicer here (but less simple) :-)
Yep, just checking I wasn't misunderstanding your comment about negative
offsets.
>> >> At the same time it's much safer for us to just save/restore r2, and
>> >> probably in the noise performance wise.
>> >
>> > If you want a function to be able to work with ABI-compliant code safely
>> > (in all cases), you'll have to make it itself ABI-compliant as well,
>> > yes :-)
>>
>> True. Except this is the VDSO which has previously been a bit wild west
>> as far as ABI goes :)
>
> It could get away with many things because it was guaranteed to be a
> leaf function. Some of those things even violate the ABIs, but you can
> get away with it easily, much reduced scope. Now if this is generated
> code, violating the rules will catch up with you sooner rather than
> later ;-)
Agreed.
cheers
^ permalink raw reply
* Re: [PATCH V5 0/4] powerpc/perf: Add support for perf extended regs in powerpc
From: Athira Rajeev @ 2020-08-07 2:11 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ravi Bangoria, Michael Neuling, maddy, kajoljain, linuxppc-dev,
Jiri Olsa, Jiri Olsa
In-Reply-To: <20200806122052.GC71359@kernel.org>
> On 06-Aug-2020, at 5:50 PM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Fri, Jul 31, 2020 at 11:04:14PM +0530, Athira Rajeev escreveu:
>>
>>
>>> On 31-Jul-2020, at 1:20 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>>>
>>> On Thu, Jul 30, 2020 at 01:24:40PM +0530, Athira Rajeev wrote:
>>>>
>>>>
>>>>> On 27-Jul-2020, at 10:46 PM, Athira Rajeev <atrajeev@linux.vnet.ibm.com> wrote:
>>>>>
>>>>> Patch set to add support for perf extended register capability in
>>>>> powerpc. The capability flag PERF_PMU_CAP_EXTENDED_REGS, is used to
>>>>> indicate the PMU which support extended registers. The generic code
>>>>> define the mask of extended registers as 0 for non supported architectures.
>>>>>
>>>>> Patches 1 and 2 are the kernel side changes needed to include
>>>>> base support for extended regs in powerpc and in power10.
>>>>> Patches 3 and 4 are the perf tools side changes needed to support the
>>>>> extended registers.
>>>>>
>>>>
>>>> Hi Arnaldo, Jiri
>>>>
>>>> please let me know if you have any comments/suggestions on this patch series to add support for perf extended regs.
>>>
>>> hi,
>>> can't really tell for powerpc, but in general
>>> perf tool changes look ok
>>>
>>
>> Hi Jiri,
>> Thanks for checking the patchset.
>
> So I'dd say you submit a v6, split into the kernel part, that probably
> should go via the PPC arch tree, and I can pick the tooling part, ok?
>
> - Arnaldo
Sure Arnaldo, I will send a v6.
Thanks,
Athira
^ 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