* [PATCH v3 2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
In-Reply-To: <1607596739-32439-1-git-send-email-ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
On platforms which have the "ibm,thread-groups" property, the per-cpu
variable cpu_l1_cache_map keeps a track of which group of threads
within the same core share the L1 cache, Instruction and Data flow.
This patch renames the variable to "thread_group_l1_cache_map" to make
it consistent with a subsequent patch which will introduce
thread_group_l2_cache_map.
This patch introduces no functional change.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 88d88ad..f3290d5 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -116,10 +116,10 @@ struct thread_groups_list {
static struct thread_groups_list tgl[NR_CPUS] __initdata;
/*
- * On big-cores system, cpu_l1_cache_map for each CPU corresponds to
+ * On big-cores system, thread_group_l1_cache_map for each CPU corresponds to
* the set its siblings that share the L1-cache.
*/
-DEFINE_PER_CPU(cpumask_var_t, cpu_l1_cache_map);
+DEFINE_PER_CPU(cpumask_var_t, thread_group_l1_cache_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
@@ -866,7 +866,7 @@ static struct thread_groups *__init get_thread_groups(int cpu,
return tg;
}
-static int init_cpu_l1_cache_map(int cpu)
+static int init_thread_group_l1_cache_map(int cpu)
{
int first_thread = cpu_first_thread_sibling(cpu);
@@ -885,7 +885,7 @@ static int init_cpu_l1_cache_map(int cpu)
return -ENODATA;
}
- zalloc_cpumask_var_node(&per_cpu(cpu_l1_cache_map, cpu),
+ zalloc_cpumask_var_node(&per_cpu(thread_group_l1_cache_map, cpu),
GFP_KERNEL, cpu_to_node(cpu));
for (i = first_thread; i < first_thread + threads_per_core; i++) {
@@ -897,7 +897,7 @@ static int init_cpu_l1_cache_map(int cpu)
}
if (i_group_start == cpu_group_start)
- cpumask_set_cpu(i, per_cpu(cpu_l1_cache_map, cpu));
+ cpumask_set_cpu(i, per_cpu(thread_group_l1_cache_map, cpu));
}
return 0;
@@ -976,7 +976,7 @@ static int init_big_cores(void)
int cpu;
for_each_possible_cpu(cpu) {
- int err = init_cpu_l1_cache_map(cpu);
+ int err = init_thread_group_l1_cache_map(cpu);
if (err)
return err;
@@ -1372,7 +1372,7 @@ static inline void add_cpu_to_smallcore_masks(int cpu)
cpumask_set_cpu(cpu, cpu_smallcore_mask(cpu));
- for_each_cpu(i, per_cpu(cpu_l1_cache_map, cpu)) {
+ for_each_cpu(i, per_cpu(thread_group_l1_cache_map, cpu)) {
if (cpu_online(i))
set_cpus_related(i, cpu, cpu_smallcore_mask);
}
--
1.9.4
^ permalink raw reply related
* [PATCH v3 0/5] Extend Parsing "ibm, thread-groups" for Shared-L2 information
From: Gautham R. Shenoy @ 2020-12-10 10:38 UTC (permalink / raw)
To: Srikar Dronamraju, Anton Blanchard, Vaidyanathan Srinivasan,
Michael Ellerman, Michael Neuling, Nicholas Piggin, Nathan Lynch,
Peter Zijlstra, Valentin Schneider
Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Hi,
This is the v2 of the patchset to extend parsing of "ibm,thread-groups" property
to discover the Shared-L2 cache information.
The previous versions can be found here :
v2 : https://lore.kernel.org/linuxppc-dev/1607533700-5546-1-git-send-email-ego@linux.vnet.ibm.com/T/#m043ea15d3832658527fca94765202b9cbefd330d
v1 : https://lore.kernel.org/linuxppc-dev/1607057327-29822-1-git-send-email-ego@linux.vnet.ibm.com/T/#m0fabffa1ea1a2807b362f25c849bb19415216520
Changes form v2-->v3:
* Fixed the build errors reported by the Kernel Test Robot for Patches 4 and 5.
Changes from v1-->v2:
Incorporate the review comments from Srikar and
fix a build error on !PPC64 configs reported by the kernel bot.
* Split Patch 1 into three patches
* First patch ensure that parse_thread_groups() is made generic to
support more than one property.
* Second patch renames cpu_l1_cache_map as
thread_group_l1_cache_map for consistency. No functional impact.
* The third patch makes init_thread_group_l1_cache_map()
generic. No functional impact.
* Patch 2 (Now patch 4): Incorporates the review comments from Srikar simplifying
the changes to update_mask_by_l2()
* Patch 3 (Now patch 5): Fix a build errors for 32-bit configs
reported by the kernel build bot.
Description of the Patchset
===========================
The "ibm,thread-groups" device-tree property is an array that is used
to indicate if groups of threads within a core share certain
properties. It provides details of which property is being shared by
which groups of threads. This array can encode information about
multiple properties being shared by different thread-groups within the
core.
Example: Suppose,
"ibm,thread-groups" = [1,2,4,8,10,12,14,9,11,13,15,2,2,4,8,10,12,14,9,11,13,15]
This can be decomposed up into two consecutive arrays:
a) [1,2,4,8,10,12,14,9,11,13,15]
b) [2,2,4,8,10,12,14,9,11,13,15]
where in,
a) provides information of Property "1" being shared by "2" groups,
each with "4" threads each. The "ibm,ppc-interrupt-server#s" of the
first group is {8,10,12,14} and the "ibm,ppc-interrupt-server#s" of
the second group is {9,11,13,15}. Property "1" is indicative of
the thread in the group sharing L1 cache, translation cache and
Instruction Data flow.
b) provides information of Property "2" being shared by "2" groups,
each group with "4" threads. The "ibm,ppc-interrupt-server#s" of
the first group is {8,10,12,14} and the
"ibm,ppc-interrupt-server#s" of the second group is
{9,11,13,15}. Property "2" indicates that the threads in each group
share the L2-cache.
The existing code assumes that the "ibm,thread-groups" encodes
information about only one property. Hence even on platforms which
encode information about multiple properties being shared by the
corresponding groups of threads, the current code will only pick the
first one. (In the above example, it will only consider
[1,2,4,8,10,12,14,9,11,13,15] but not [2,2,4,8,10,12,14,9,11,13,15]).
Furthermore, currently on platforms where groups of threads share L2
cache, we incorrectly create an extra CACHE level sched-domain that
maps to all the threads of the core.
For example, if "ibm,thread-groups" is
00000001 00000002 00000004 00000000
00000002 00000004 00000006 00000001
00000003 00000005 00000007 00000002
00000002 00000004 00000000 00000002
00000004 00000006 00000001 00000003
00000005 00000007
then, the sub-array
[00000002 00000002 00000004
00000000 00000002 00000004 00000006
00000001 00000003 00000005 00000007]
indicates that L2 (Property "2") is shared only between the threads of a single
group. There are "2" groups of threads where each group contains "4"
threads each. The groups being {0,2,4,6} and {1,3,5,7}.
However, the sched-domain hierarchy for CPUs 0,1 is
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-7 level=CACHE
domain-2: span=0-15,24-39,48-55 level=MC
domain-3: span=0-55 level=DIE
where the CACHE domain reports that L2 is shared across the entire
core which is incorrect on such platforms.
This patchset remedies these issues by extending the parsing support
for "ibm,thread-groups" to discover information about multiple
properties being shared by the corresponding groups of threads. In
particular we cano now detect if the groups of threads within a core
share the L2-cache. On such platforms, we populate the populating the
cpu_l2_cache_mask of every CPU to the core-siblings which share L2
with the CPU as specified in the by the "ibm,thread-groups" property
array.
With the patchset, the sched-domain hierarchy is correctly
reported. For eg for CPUs 0,1, with the patchset
CPU0 attaching sched-domain(s):
domain-0: span=0,2,4,6 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
CPU1 attaching sched-domain(s):
domain-0: span=1,3,5,7 level=SMT
domain-1: span=0-15,24-39,48-55 level=MC
domain-2: span=0-55 level=DIE
The CACHE domain with span=0,2,4,6 for CPU 0 (span=1,3,5,7 for CPU 1
resp.) gets degenerated into the SMT domain. Furthermore, the
last-level-cache domain gets correctly set to the SMT sched-domain.
Testing
==========
With the producer-consumer
testcase(https://github.com/gautshen/misc/tree/master/producer_consumer)
where in the producer thread performs writes to 4096 random locations,
and the consumer thread subsequently reads from those 4096 random
location. We measure the time taken by the consumer to finish the 4096
reads (called an iteration of the consumer). Thus lower the value,
better is the result.
The best case occurs when the producer and consumer are affined to the
same L2 cache domain (Eg: CPU0, CPU2). On the platform with the
thread-groups sharing L2,
|-----------------------------------------------|
| Without Patch |
|-----------|-----------|-----------------------|
| Producer | Consumer | Avg time per Consumer |
| Affinity | Affinity | Iteration |
|-----------|-----------|-----------------------|
| CPU0 | CPU2 | 235us |
|-----------|-----------|-----------------------|
|Not affined|Not affined| 347us |
|-----------------------------------------------|
We see that out-of-box, the average time per consumer iteration is
higher since the tasks can be placed anywhere within the core without
them being in the L2 domain.
|-----------------------------------------------|
| With Patch |
|-----------|-----------|-----------------------|
| Producer | Consumer | Avg time per Consumer |
| Affinity | Affinity | Iteration |
|-----------|-----------|-----------------------|
| CPU0 | CPU2 | 235us |
|-----------|-----------|-----------------------|
|Not affined|Not affined| 236us |
|-----------------------------------------------|
With the patch, since the L2 domain is correctly identified, the
scheduler does the right thing by co-locating the producer and
consumer on the same L2 domain, thereby yielding the out-of-box
performance matching the best case.
Finally, this patchset reports the correct shared_cpu_map/list in the
sysfs for L2 cache on such platforms. With the patchset for CPUs0, 1,
for L2 cache we see the correct shared_cpu_map/list
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_list:0,2,4,6
/sys/devices/system/cpu/cpu0/cache/index2/shared_cpu_map:000000,00000055
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list:1,3,5,7
/sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map:000000,000000aa
The patchset has been tested on older platforms which encode only the
L1 sharing information via "ibm,thread-groups" and there is no
regression found.
Gautham R. Shenoy (5):
powerpc/smp: Parse ibm,thread-groups with multiple properties
powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
powerpc/smp: Rename init_thread_group_l1_cache_map() to make it
generic
powerpc/smp: Add support detecting thread-groups sharing L2 cache
powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
arch/powerpc/include/asm/smp.h | 6 +
arch/powerpc/kernel/cacheinfo.c | 30 +++--
arch/powerpc/kernel/smp.c | 241 ++++++++++++++++++++++++++++------------
3 files changed, 198 insertions(+), 79 deletions(-)
--
1.9.4
^ permalink raw reply
* Re: [PATCH kernel v2] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Leonardo Augusto Guimarães Garcia, kvm-ppc, stable,
David Gibson
In-Reply-To: <20201122073828.15446-1-aik@ozlabs.ru>
On Sun, 22 Nov 2020 18:38:28 +1100, Alexey Kardashevskiy wrote:
> We execute certain NPU2 setup code (such as mapping an LPID to a device
> in NPU2) unconditionally if an Nvlink bridge is detected. However this
> cannot succeed on POWER8NVL machines and errors appear in dmesg. This is
> harmless as skiboot returns an error and the only place we check it is
> vfio-pci but that code does not get called on P8+ either.
>
> This adds a check if pnv_npu2_xxx helpers are called on a machine with
> NPU2 which initializes pnv_phb::npu in pnv_npu2_init();
> pnv_phb::npu==NULL on POWER8/NVL (Naples).
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/powernv/npu: Do not attempt NPU2 setup on POWER8NVL NPU
https://git.kernel.org/powerpc/c/b1198a88230f2ce50c271e22b82a8b8610b2eea9
cheers
^ permalink raw reply
* Re: [PATCH kernel v3] powerpc/pci: Remove LSI mappings on device teardown
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Frederic Barrat, Oliver O'Halloran, Cédric Le Goater
In-Reply-To: <20201202005222.5477-1-aik@ozlabs.ru>
On Wed, 2 Dec 2020 11:52:22 +1100, Alexey Kardashevskiy wrote:
> 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.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/pci: Remove LSI mappings on device teardown
https://git.kernel.org/powerpc/c/450be4960a0fb89b931a6bb3c3f0bb538ac4c03c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/book3s64/kuap: Improve error reporting with KUAP
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20201208031539.84878-1-aneesh.kumar@linux.ibm.com>
On Tue, 8 Dec 2020 08:45:39 +0530, Aneesh Kumar K.V wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b70000) - exploit attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at 0x7e6725b70000
> [ 55.022533] Faulting instruction address: 0xc000000000e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
> ....
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
cheers
^ permalink raw reply
* Re: [PATCH v7 00/22] Kernel userspace access/execution prevention with hash translation
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20201127044424.40686-1-aneesh.kumar@linux.ibm.com>
On Fri, 27 Nov 2020 10:14:02 +0530, Aneesh Kumar K.V wrote:
> This patch series implements KUAP and KUEP with hash translation mode using
> memory keys. The kernel now uses memory protection key 3 to control access
> to the kernel. Kernel page table entries are now configured with key 3.
> Access to locations configured with any other key value is denied when in
> kernel mode (MSR_PR=0). This includes userspace which is by default configured
> with key 0.
>
> [...]
Patches 1-20, 22 applied to powerpc/next.
[01/22] powerpc: Add new macro to handle NESTED_IFCLR
https://git.kernel.org/powerpc/c/c3d35ddd1ec874690a4e8da5a18497256f1ffa9a
[02/22] KVM: PPC: BOOK3S: PR: Ignore UAMOR SPR
https://git.kernel.org/powerpc/c/9f378b9f007cc94beadea40df83cc62a76975c6f
[03/22] powerpc/book3s64/kuap/kuep: Add PPC_PKEY config on book3s64
https://git.kernel.org/powerpc/c/227ae625522c65c4535cabe407f47abc058585ed
[04/22] powerpc/book3s64/kuap/kuep: Move uamor setup to pkey init
https://git.kernel.org/powerpc/c/39df17bc20059c84ddc6f91831fce2e2cc79a6f3
[05/22] powerpc/book3s64/kuap: Move KUAP related function outside radix
https://git.kernel.org/powerpc/c/3b47b7549ead0719e94022c6742199333c7c8d9f
[06/22] powerpc/book3s64/kuep: Move KUEP related function outside radix
https://git.kernel.org/powerpc/c/57b7505aa8ba13eb18ffabeb689ac64343c53aaa
[07/22] powerpc/book3s64/kuap: Rename MMU_FTR_RADIX_KUAP and MMU_FTR_KUEP
https://git.kernel.org/powerpc/c/d5b810b5c938e73fd21b2b05ef6a79837eeaa305
[08/22] powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation
https://git.kernel.org/powerpc/c/d94b827e89dc3f92cd871d10f4992a6bd3c861e5
[09/22] powerpc/exec: Set thread.regs early during exec
https://git.kernel.org/powerpc/c/d7df77e89039623ededf0ece7b4358f7c9ecbaae
[10/22] powerpc/book3s64/pkeys: Store/restore userspace AMR/IAMR correctly on entry and exit from kernel
https://git.kernel.org/powerpc/c/8e560921b58cbc18e192f0ac273d307a37a144f9
[11/22] powerpc/book3s64/pkeys: Inherit correctly on fork.
https://git.kernel.org/powerpc/c/f643fcab74c005ddfdda68c69909f03bde766ff1
[12/22] powerpc/book3s64/pkeys: Reset userspace AMR correctly on exec
https://git.kernel.org/powerpc/c/d5fa30e6993ffcdd1859d8dab1a07a6f6c6e7c3f
[13/22] powerpc/ptrace-view: Use pt_regs values instead of thread_struct based one.
https://git.kernel.org/powerpc/c/edc541ecaae73d498a49b9ca82bc66255d9e0720
[14/22] powerpc/book3s64/pkeys: Don't update SPRN_AMR when in kernel mode.
https://git.kernel.org/powerpc/c/48a8ab4eeb8271f2a0e2ca3cf80844a59acca153
[15/22] powerpc/book3s64/kuap: Restrict access to userspace based on userspace AMR
https://git.kernel.org/powerpc/c/4d6c551e9f548f7675a01eff229d09ab41162a25
[16/22] powerpc/book3s64/kuap: Improve error reporting with KUAP
https://git.kernel.org/powerpc/c/eb232b1624462752dc916d9015b31ecdac0a01f1
[17/22] powerpc/book3s64/kuap: Use Key 3 to implement KUAP with hash translation.
https://git.kernel.org/powerpc/c/fa46c2fa6ffbedab3a3cbcbde1292468979e830b
[18/22] powerpc/book3s64/kuep: Use Key 3 to implement KUEP with hash translation.
https://git.kernel.org/powerpc/c/292f86c4c683a1064aff7210348da088c1573ee0
[19/22] powerpc/book3s64/hash/kuap: Enable kuap on hash
https://git.kernel.org/powerpc/c/b2ff33a10c8b3e9d260c57df38b5cd3765a0b785
[20/22] powerpc/book3s64/hash/kuep: Enable KUEP on hash
https://git.kernel.org/powerpc/c/c91435d95c49f4053b05ba03b41dd7ed0fbd6c71
[22/22] powerpc/book3s64/pkeys: Optimize KUAP and KUEP feature disabled case
https://git.kernel.org/powerpc/c/ec0f9b98f7d01b15c804e77e12a515ffc56d7309
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: bigeasy, maddy, linuxppc-dev
In-Reply-To: <1606814880-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Tue, 1 Dec 2020 04:28:00 -0500, Athira Rajeev wrote:
> The power_pmu_event_init() callback access per-cpu variable
> (cpu_hw_events) to check for event constraints and Branch Stack
> (BHRB). Current usage is to disable preemption when accessing the
> per-cpu variable, but this does not prevent timer callback from
> interrupting event_init. Fix this by using 'local_irq_save/restore'
> to make sure the code path is invoked with disabled interrupts.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Invoke per-CPU variable access with disabled interrupts
https://git.kernel.org/powerpc/c/f66de7ac4849eb42a7b18e26b8ee49e08130fd27
cheers
^ permalink raw reply
* Re: [PATCH V2 0/7] powerpc/perf: Fixes for power10 PMU
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1606409684-1589-1-git-send-email-atrajeev@linux.vnet.ibm.com>
On Thu, 26 Nov 2020 11:54:37 -0500, Athira Rajeev wrote:
> Patchset contains PMU fixes for power10.
>
> This patchset contains 7 patches.
> Patch1 includes fix to update event code with radix_scope_qual
> bit in power10.
> Patch2 and Patch3 updates the event group constraints for L2/L3
> and threshold events in power10.
> Patch4, patch5 and patch6 includes the event code changes for
> l2/l3 events and some of the generic events.
> Patch7 adds fixes for PMCCEXT bit in power10.
>
> [...]
Applied to powerpc/next.
[1/7] powerpc/perf: Fix to update radix_scope_qual in power10
https://git.kernel.org/powerpc/c/d3afd28cd2f35b2a1046b76e0cf010b684da2e84
[2/7] powerpc/perf: Update the PMU group constraints for l2l3 events in power10
https://git.kernel.org/powerpc/c/e924be7b0b0d1f37d0509c854a92c7a71e3cdfe7
[3/7] powerpc/perf: Fix the PMU group constraints for threshold events in power10
https://git.kernel.org/powerpc/c/0263bbb377af0c2d38bc8b2ad2ff147e240094de
[4/7] powerpc/perf: Add generic and cache event list for power10 DD1
https://git.kernel.org/powerpc/c/c0e3985790251b307b7b71b687ed0128741b3f34
[5/7] powerpc/perf: Fix to update generic event codes for power10
https://git.kernel.org/powerpc/c/1f12316394e3b241e70ed620ca846002c8ace3ec
[6/7] powerpc/perf: Fix to update cache events with l2l3 events in power10
https://git.kernel.org/powerpc/c/9a8ee52634235993273c43ef67669d8168497dd7
[7/7] powerpc/perf: MMCR0 control for PMU registers under PMCC=00
https://git.kernel.org/powerpc/c/91668ab7db4bcfae332e561df1de2401f3f18553
cheers
^ permalink raw reply
* Re: [PATCH V2] powerpc/perf: Fix crash with is_sier_available when pmu is not set
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: mpe, Athira Rajeev; +Cc: sachinp, maddy, linuxppc-dev
In-Reply-To: <1606185640-1720-1-git-send-email-atrajeev@linux.vnet.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
On Mon, 23 Nov 2020 21:40:40 -0500, Athira Rajeev wrote:
> On systems without any specific PMU driver support registered, running
> 'perf record' with —intr-regs will crash ( perf record -I <workload> ).
>
> The relevant portion from crash logs and Call Trace:
>
> Unable to handle kernel paging request for data at address 0x00000068
> Faulting instruction address: 0xc00000000013eb18
> Oops: Kernel access of bad area, sig: 11 [#1]
> CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
> NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
> REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
> NIP [c00000000013eb18] is_sier_available+0x18/0x30
> LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
> Call Trace:
> [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
> [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
> [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
> [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
> [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
> [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
> [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
> [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
> [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/perf: Fix crash with is_sier_available when pmu is not set
https://git.kernel.org/powerpc/c/f75e7d73bdf73f07b0701a6d21c111ef5d9021dd
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <39a530ee41d83f49747ab3af8e39c056450b9b4d.1602489653.git.christophe.leroy@csgroup.eu>
On Mon, 12 Oct 2020 08:02:13 +0000 (UTC), Christophe Leroy wrote:
> G2_LE has a 603 core, add CPU_FTR_NOEXECUTE.
Applied to powerpc/next.
[1/1] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
https://git.kernel.org/powerpc/c/197493af414ee22427be3343637ac290a791925a
cheers
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Retire e200 core (mpc555x processor)
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <34ebc3ba2c768d97f363bd5f2deea2356e9ae127.1605589460.git.christophe.leroy@csgroup.eu>
On Tue, 17 Nov 2020 05:07:58 +0000 (UTC), Christophe Leroy wrote:
> There is no defconfig selecting CONFIG_E200, and no platform.
>
> e200 is an earlier version of booke, a predecessor of e500,
> with some particularities like an unified cache instead of both an
> instruction cache and a data cache.
>
> Remove it.
Applied to powerpc/next.
[1/2] powerpc: Retire e200 core (mpc555x processor)
https://git.kernel.org/powerpc/c/39c8bf2b3cc166a2a75111e4941cc5f7efbddc35
[2/2] powerpc: Remove ucache_bsize
https://git.kernel.org/powerpc/c/8817aabb1bdd5811130f94ff6442bb19c9158a3a
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: inline iomap accessors
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <18b357d68c4cde149f75c7a1031c850925cd8128.1605981539.git.christophe.leroy@csgroup.eu>
On Sat, 21 Nov 2020 17:59:19 +0000 (UTC), Christophe Leroy wrote:
> ioreadXX()/ioreadXXbe() accessors are equivalent to ppc
> in_leXX()/in_be16() accessors but they are not inlined.
>
> Since commit 0eb573682872 ("powerpc/kerenl: Enable EEH for IO
> accessors"), the 'le' versions are equivalent to the ones
> defined in asm-generic/io.h, allthough the ones there are inlined.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: inline iomap accessors
https://git.kernel.org/powerpc/c/894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <829ae1aed1d2fc6b5fc5818362e573dee5d6ecde.1602489852.git.christophe.leroy@csgroup.eu>
On Mon, 12 Oct 2020 08:04:24 +0000 (UTC), Christophe Leroy wrote:
> MMU_FTR_PPCAS_ARCH_V2 is defined in cpu_table.h
> as MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE.
>
> MMU_FTR_TLBIEL and MMU_FTR_16M_PAGE are defined in mmu.h
>
> MMU_FTR_PPCAS_ARCH_V2 is used only in mmu.h and it is used only once.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2
https://git.kernel.org/powerpc/c/0e8ff4f8d2faa2e3381e774c9e2fb975e8b4598f
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Alastair D'Silva, Benjamin Herrenschmidt, Michael Ellerman,
Christophe Leroy, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <ceede82fadf37f3b8275e61fcf8cf29a3e2ec7fe.1602351011.git.christophe.leroy@csgroup.eu>
On Sat, 10 Oct 2020 17:30:59 +0000 (UTC), Christophe Leroy wrote:
> MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature()
>
> Use mmu_has_feature() instead
Applied to powerpc/next.
[1/1] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x
https://git.kernel.org/powerpc/c/17179aeb9d34cc81e1a4ae3f85e5b12b13a1f8d0
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d01d7613664fafa43de1f1ae89924075bc24241c.1602489931.git.christophe.leroy@csgroup.eu>
On Mon, 12 Oct 2020 08:05:49 +0000 (UTC), Christophe Leroy wrote:
> Only mpc83xx will set MMU_FTR_NEED_DTLB_SW_LRU and its
> definition is enclosed in #ifdef CONFIG_PPC_83xx.
>
> Make MMU_FTR_NEED_DTLB_SW_LRU possible only when
> CONFIG_PPC_83xx is set.
Applied to powerpc/next.
[1/1] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx
https://git.kernel.org/powerpc/c/b68e3a3dff97bdc1cba79dc5f80cede8a2419cac
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e26ddc1d6f6aca739dd8d2b7c67351ead559b084.1602489664.git.christophe.leroy@csgroup.eu>
On Mon, 12 Oct 2020 08:02:30 +0000 (UTC), Christophe Leroy wrote:
> Since commit 10b35d9978ac ("[PATCH] powerpc: merged asm/cputable.h"),
> CPU_FTR_COHERENT_ICACHE has always been defined.
>
> Remove the #ifndef CPU_FTR_COHERENT_ICACHE block.
Applied to powerpc/next.
[1/1] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
https://git.kernel.org/powerpc/c/1a1be322178ca8097abeee244262ce0da5b519a9
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/time: Remove ifdef in get_vtb()
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a0fc81cd85121407726bcf480fc9a0d8e7617fce.1601549933.git.christophe.leroy@csgroup.eu>
On Thu, 1 Oct 2020 10:59:20 +0000 (UTC), Christophe Leroy wrote:
> SPRN_VTB and CPU_FTR_ARCH_207S are always defined,
> no need of an ifdef.
Applied to powerpc/next.
[1/1] powerpc/time: Remove ifdef in get_vtb()
https://git.kernel.org/powerpc/c/c3cb5dbd85dbd9ae51fadf867782dc34806f04d8
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/xmon: Change printk() to pr_cont()
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <c8a6ec704416ecd5ff2bd26213c9bc026bdd19de.1607077340.git.christophe.leroy@csgroup.eu>
On Fri, 4 Dec 2020 10:35:38 +0000 (UTC), Christophe Leroy wrote:
> Since some time now, printk() adds carriage return, leading to
> unusable xmon output:
>
> [ 54.288722] sysrq: Entering xmon
> [ 54.292209] Vector: 0 at [cace3d2c]
> [ 54.292274] pc:
> [ 54.292331] c0023650
> [ 54.292468] : xmon+0x28/0x58
> [ 54.292519]
> [ 54.292574] lr:
> [ 54.292630] c0023724
> [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc
> [ 54.292801]
> [ 54.292867] sp: cace3de8
> [ 54.292931] msr: 9032
> [ 54.292999] current = 0xc28d0000
> [ 54.293072] pid = 377, comm = sh
> [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty (root@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020
> [ 54.293287] enter ? for help
> [ 54.293470] [cace3de8]
> [ 54.293532] c0023724
> [ 54.293654] sysrq_handle_xmon+0xa4/0xfc
> [ 54.293711] (unreliable)
> [ 54.293859] [cace3e18]
> [ 54.293918] c03885a8
> [ 54.294056] __handle_sysrq+0xe4/0x1d4
> [ 54.294108]
> [ 54.294255] [cace3e48]
> [ 54.294314] c0388704
> [ 54.294441] write_sysrq_trigger+0x34/0x74
> [ 54.294493]
> [ 54.294641] [cace3e68]
> [ 54.294700] c01f65d0
> [ 54.294822] proc_reg_write+0xac/0x11c
> [ 54.294875]
> [ 54.295023] [cace3e88]
> [ 54.295082] c0179910
> [ 54.295198] vfs_write+0x134/0x46c
> [ 54.295250]
> [ 54.295396] [cace3f08]
> [ 54.295455] c0179de8
> [ 54.295567] ksys_write+0x78/0x11c
> [ 54.295619]
> [ 54.295766] [cace3f38]
> [ 54.295825] c00110d0
> [ 54.295951] ret_from_syscall+0x0/0x34
> [ 54.296002]
> [ 54.296159] --- Exception: c01 (System Call) at
> [ 54.296217] 0fd4e784
> [ 54.296303]
> [ 54.296375] SP (7fca6ff0) is in userspace
> [ 54.296431] mon>
> [ 54.296484] <no input ...>
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/xmon: Change printk() to pr_cont()
https://git.kernel.org/powerpc/c/7c6c86b36a36dd4a13d30bba07718e767aa2e7a1
cheers
^ permalink raw reply
* Re: [PATCH v1 00/30] Modernise VDSO setup
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1601197618.git.christophe.leroy@csgroup.eu>
On Sun, 27 Sep 2020 09:16:16 +0000 (UTC), Christophe Leroy wrote:
> This series modernises the setup of VDSO:
> - Switch to using _install_special_mapping() which has replaced install_special_mapping()
> - Move datapage in front of text like most other architectures to simplify its localisation
> - Perform link time symbol resolution instead of runtime
>
> This leads to a huge size reduction of vdso.c
>
> [...]
Applied to powerpc/next.
[01/30] powerpc/vdso: Stripped VDSO is not needed, don't build it
https://git.kernel.org/powerpc/c/7fe2de246e21f01212a8923fbabb4ac84c944d4a
[02/30] powerpc/vdso: Add missing includes and clean vdso_setup_syscall_map()
https://git.kernel.org/powerpc/c/bc9d5bfc4d23fb3580e7da360f2c9bd878dda9b2
[03/30] powerpc/vdso: Rename syscall_map_32/64 to simplify vdso_setup_syscall_map()
https://git.kernel.org/powerpc/c/1bb30b7a45976ae02d54fd43a8665e77314cc05e
[04/30] powerpc/vdso: Remove get_page() in vdso_pagelist initialization
https://git.kernel.org/powerpc/c/abcdbd039e6823305c2841d07a352fbd2343564e
[05/30] powerpc/vdso: Remove NULL termination element in vdso_pagelist
https://git.kernel.org/powerpc/c/35c1c7c0bc354d8c3d55bea3bf3e239797980013
[06/30] powerpc/vdso: Refactor 32 bits and 64 bits pages setup
https://git.kernel.org/powerpc/c/3cf63825413c9eed2dae06070464efb27381bdac
[07/30] powerpc/vdso: Remove unnecessary ifdefs in vdso_pagelist initialization
https://git.kernel.org/powerpc/c/4fe0e3c1724e397845df75f64059bcea4ff590e8
[08/30] powerpc/vdso: Use VDSO size in arch_setup_additional_pages()
https://git.kernel.org/powerpc/c/7461a4f79ba16dc7733c07c00883a10c7e46b602
[09/30] powerpc/vdso: Simplify arch_setup_additional_pages() exit
https://git.kernel.org/powerpc/c/b2df3f60b452ab496adcef1b2f9c2560f6d8e8e0
[10/30] powerpc/vdso: Move to _install_special_mapping() and remove arch_vma_name()
https://git.kernel.org/powerpc/c/c1bab64360e6850ca54305d2f1902dac829c9752
[11/30] powerpc/vdso: Provide vdso_remap()
https://git.kernel.org/powerpc/c/526a9c4a7234cccf6d900c6e82d79356f974cbfd
[12/30] powerpc/vdso: Replace vdso_base by vdso
https://git.kernel.org/powerpc/c/c102f07667486dc4a6ae1e3fe7aa67135cb40e3e
[13/30] powerpc/vdso: Move vdso datapage up front
https://git.kernel.org/powerpc/c/511157ab641eb6bedd00d62673388e78a4f871cf
[14/30] powerpc/vdso: Simplify __get_datapage()
https://git.kernel.org/powerpc/c/591857b635c1f635cae556e1b1f9d81808242493
[15/30] powerpc/vdso: Remove unused \tmp param in __get_datapage()
https://git.kernel.org/powerpc/c/550e6074c106e1a6fb57dfef62f0daede12d832c
[16/30] powerpc/vdso: Retrieve sigtramp offsets at buildtime
https://git.kernel.org/powerpc/c/91bf695596f594e42d69d70deb2ae53cafecf77c
[17/30] powerpc/vdso: Use builtin symbols to locate fixup section
https://git.kernel.org/powerpc/c/ed07f6353ddf19e51c4db6d2be72ca97f7ed8a08
[18/30] powerpc/vdso: Merge __kernel_sync_dicache_p5() into __kernel_sync_dicache()
https://git.kernel.org/powerpc/c/0fc980db9a404a993c4ed542369a745d8a14b0b7
[19/30] powerpc/vdso: Remove vdso32_pages and vdso64_pages
https://git.kernel.org/powerpc/c/b7fe9c15b57d767fda250e8eff79be435996ef33
[20/30] powerpc/vdso: Remove __kernel_datapage_offset
https://git.kernel.org/powerpc/c/49bf59fd0371b1053a17021f27605f43071584ee
[21/30] powerpc/vdso: Remove runtime generated sigtramp offsets
https://git.kernel.org/powerpc/c/899367ea50637f382fdc5c927fe47e6090d4aefe
[22/30] powerpc/vdso: Remove vdso_patches[] and associated functions
https://git.kernel.org/powerpc/c/5cda7c75493fd17a010d7399e39fda6619f69043
[23/30] powerpc/vdso: Remove unused text member in struct lib32/64_elfinfo
https://git.kernel.org/powerpc/c/e113f8ef1c7e5fd79b440e5565c8552b36122bfa
[24/30] powerpc/vdso: Remove symbol section information in struct lib32/64_elfinfo
https://git.kernel.org/powerpc/c/6ed613ad572a84c175629fc8657a197c6415b7d6
[25/30] powerpc/vdso: Remove lib32_elfinfo and lib64_elfinfo
https://git.kernel.org/powerpc/c/67a354051da28d482e53146def212b102664ce0e
[26/30] powerpc/vdso: Remove vdso_setup()
https://git.kernel.org/powerpc/c/a4ccd64acb8c08ce8d36001cdd06477deec6ae89
[27/30] powerpc/vdso: Remove vdso_ready
https://git.kernel.org/powerpc/c/23c4ceaf1a457808d031c666760fa325c7b7f23f
[28/30] powerpc/vdso: Remove DBG()
https://git.kernel.org/powerpc/c/e90903203d94d0a0d0e8ebc979aa0617a7bbe9a3
[29/30] powerpc/vdso: Remove VDSO32_LBASE and VDSO64_LBASE
https://git.kernel.org/powerpc/c/676155ab239dc2035d5306438b45695b6fa165e2
[30/30] powerpc/vdso: Cleanup vdso.h
https://git.kernel.org/powerpc/c/65d2150c89121a49e4bd4abbb99c436c77003eed
cheers
^ permalink raw reply
* Re: [PATCH v1 1/8] powerpc/32s: Always map kernel text and rodata with BATs
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <da51f7ec632825a4ce43290a904aad61648408c0.1606285013.git.christophe.leroy@csgroup.eu>
On Wed, 25 Nov 2020 07:10:46 +0000 (UTC), Christophe Leroy wrote:
> Since commit 2b279c0348af ("powerpc/32s: Allow mapping with BATs with
> DEBUG_PAGEALLOC"), there is no real situation where mapping without
> BATs is required.
>
> In order to simplify memory handling, always map kernel text
> and rodata with BATs even when "nobats" kernel parameter is set.
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/32s: Always map kernel text and rodata with BATs
https://git.kernel.org/powerpc/c/035b19a15a98907916a42a6b1d025877c42f10ad
[2/8] powerpc/32s: Don't hash_preload() kernel text
https://git.kernel.org/powerpc/c/79d1befe054ad4adb277fbd2d2756b1394eaf24e
[3/8] powerpc/32s: Fix an FTR_SECTION_ELSE
https://git.kernel.org/powerpc/c/7b107a71e732c298d684ee1bafd82f1a2be58d5e
[4/8] powerpc/32s: Don't use SPRN_SPRG_PGDIR in hash_page
https://git.kernel.org/powerpc/c/03d701c2d9b0091cf8e96cb49ab7d2a6a9f19937
[5/8] powerpc/603: Use SPRN_SDR1 to store the pgdir phys address
https://git.kernel.org/powerpc/c/c4a22611bf6ced73d86bdfc0604d7db8982a24a4
[6/8] powerpc/32: Simplify EXCEPTION_PROLOG_1 macro
https://git.kernel.org/powerpc/c/6285f9cff570bfd07b542840912c1d01bd5428e0
[7/8] powerpc/32s: Use SPRN_SPRG_SCRATCH2 in DSI prolog
https://git.kernel.org/powerpc/c/de1cd0790697e67b728de43e8657bb52f528bfb9
[8/8] powerpc/32: Use SPRN_SPRG_SCRATCH2 in exception prologs
https://git.kernel.org/powerpc/c/d2e006036082e2dc394c5ec86c5bb88cc27c0749
cheers
^ permalink raw reply
* Re: [PATCH v2 00/25] powerpc: Switch signal 32 to using unsafe_put_user() and friends
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1597770847.git.christophe.leroy@csgroup.eu>
On Tue, 18 Aug 2020 17:19:11 +0000 (UTC), Christophe Leroy wrote:
> This series leads to a reduction from 2.55s to 1.73s of
> the system CPU time with the following microbench app
> on an mpc832x with KUAP (approx 32%)
>
> This series replaces copies to users by unsafe_put_user() and friends
> with user_write_access_begin() dance in signal32.
>
> [...]
Applied to powerpc/next.
[01/25] powerpc/signal: Move inline functions in signal.h
https://git.kernel.org/powerpc/c/95593e930d7d067ca9bbee996c845248930a01f9
[02/25] powerpc/ptrace: Move declaration of ptrace_get_reg() and ptrace_set_reg()
https://git.kernel.org/powerpc/c/67e364b3295f9dbf3b820d0edde86fb7c95efc98
[03/25] powerpc/ptrace: Consolidate reg index calculation
https://git.kernel.org/powerpc/c/e009fa433542cd09d6279e361b767a1f44ffd29a
[04/25] powerpc/ptrace: Create ptrace_get_fpr() and ptrace_put_fpr()
https://git.kernel.org/powerpc/c/4d90eb97e292c7b14de8ba59fded35b340c73101
[05/25] powerpc/signal: Don't manage floating point regs when no FPU
https://git.kernel.org/powerpc/c/b6254ced4da6cf28d49fbffe24ee4b3286dcb3f4
[06/25] powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x
https://git.kernel.org/powerpc/c/7d68c89169508064c460a1208f38ed0589d226fa
[07/25] powerpc/signal: Remove BUG_ON() in handler_signal functions
https://git.kernel.org/powerpc/c/3fcfb5d1bf731bdbd847c29df57a5372d8ea58d3
[08/25] powerpc/signal: Move access_ok() out of get_sigframe()
https://git.kernel.org/powerpc/c/454b1abb588b3942655638a8bcf1ea4501260579
[09/25] powerpc/signal: Remove get_clean_sp()
https://git.kernel.org/powerpc/c/0ecbc6ad18e324012234183e21805423f5e0cc79
[10/25] powerpc/signal: Call get_tm_stackpointer() from get_sigframe()
https://git.kernel.org/powerpc/c/c180cb305c9bba094657259487d563c8fbfb648b
[11/25] powerpc/signal: Refactor bad frame logging
https://git.kernel.org/powerpc/c/7fe8f773ee248c726cec2addcdb94056049d6e34
[12/25] powerpc/signal32: Simplify logging in handle_rt_signal32()
https://git.kernel.org/powerpc/c/debf122c777f361137a3114db7be8aecc65f6af2
[13/25] powerpc/signal32: Move handle_signal32() close to handle_rt_signal32()
https://git.kernel.org/powerpc/c/3eea688be0ccba2221e047b7df6f9ae87361cdd6
[14/25] powerpc/signal32: Rename local pointers in handle_rt_signal32()
https://git.kernel.org/powerpc/c/8e91cf8501f14d8b6727c71c98fd743e95e9b402
[15/25] powerpc/signal32: Misc changes to make handle_[rt_]_signal32() more similar
https://git.kernel.org/powerpc/c/91b8ecd419cb46058e99b3a574184883c02b7729
[16/25] powerpc/signal32: Move signal trampoline setup to handle_[rt_]signal32
https://git.kernel.org/powerpc/c/8d33001dd650b88e915a1a13e2ca807350e374df
[17/25] powerpc/signal32: Switch handle_signal32() to user_access_begin() logic
https://git.kernel.org/powerpc/c/ad65f4909fd3736d84533784cd9ab76905536b34
[18/25] powerpc/signal32: Switch handle_rt_signal32() to user_access_begin() logic
https://git.kernel.org/powerpc/c/9504db3e90b22dca19d8152ed5a82c68512dac0e
[19/25] powerpc/signal32: Remove ifdefery in middle of if/else
https://git.kernel.org/powerpc/c/f1cf4f93de2ff66313a091320d7683735816a0bc
[20/25] signal: Add unsafe_put_compat_sigset()
https://git.kernel.org/powerpc/c/14026b94ccfe626e512bc9fa01e0e72ee75c7a98
[21/25] powerpc/signal32: Add and use unsafe_put_sigset_t()
https://git.kernel.org/powerpc/c/de781ebdf6b8a256742da4fd6b0e39bb22ed9fe3
[22/25] powerpc/signal32: Switch swap_context() to user_access_begin() logic
https://git.kernel.org/powerpc/c/31147d7d6133ea17504b118114a191a8af85f3de
[23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user()
https://git.kernel.org/powerpc/c/b3484a1d4d1fb54ad7b615a13003d8bc11919c96
[24/25] powerpc/signal32: Isolate non-copy actions in save_user_regs() and save_tm_user_regs()
https://git.kernel.org/powerpc/c/968c4fccd1bb8b440326dac5078ad87d17af4a47
[25/25] powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version
https://git.kernel.org/powerpc/c/ef75e73182949a94bde169a774de1b62ae21fbbc
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Christophe Leroy, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <822833ce3dc10634339818f7d1ab616edf63b0c6.1603041883.git.christophe.leroy@csgroup.eu>
On Sun, 18 Oct 2020 17:25:17 +0000 (UTC), Christophe Leroy wrote:
> As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not
> compatible with 440 and 460 variants.
>
> This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different
> for 47x, meaning a kernel built for 47x will not run correctly
> on a 440.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
https://git.kernel.org/powerpc/c/8b8319b181fd9d6821703fef1228b4dcde613a16
[2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time
https://git.kernel.org/powerpc/c/1f69aa0b89240653fdf708aada6a3d968447cce7
cheers
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Christophe Leroy, Paul Mackerras, Benjamin Herrenschmidt,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4fc9e30b2b09933c8dfd7a50924dfbdf9ea6a80f.1602587470.git.christophe.leroy@csgroup.eu>
On Tue, 13 Oct 2020 11:11:20 +0000 (UTC), Christophe Leroy wrote:
> On 8xx, we get the following features:
>
> [ 0.000000] cpu_features = 0x0000000000000100
> [ 0.000000] possible = 0x0000000000000120
> [ 0.000000] always = 0x0000000000000000
>
> This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all
> other configurations, the three lines should be equal.
>
> [...]
Patch 2 applied to powerpc/next.
[2/2] powerpc/feature: Remove CPU_FTR_NODSISRALIGN
https://git.kernel.org/powerpc/c/7d47034551687eb6c15e8431d897a3758fc5f83e
cheers
^ permalink raw reply
* Re: [PATCH v3 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
From: Michael Ellerman @ 2020-12-10 11:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Ellerman, mathieu.desnoyers,
Christophe Leroy, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <25e6fca46fda3e2a4298448edbf654f64756eee7.1603358942.git.christophe.leroy@csgroup.eu>
On Thu, 22 Oct 2020 09:29:19 +0000 (UTC), Christophe Leroy wrote:
> GCC 4.9 sometimes fails to build with "m<>" constraint in
> inline assembly.
>
> CC lib/iov_iter.o
> In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
> from ./arch/powerpc/include/asm/atomic.h:11,
> from ./include/linux/atomic.h:7,
> from ./include/linux/crypto.h:15,
> from ./include/crypto/hash.h:11,
> from lib/iov_iter.c:2:
> lib/iov_iter.c: In function 'iovec_from_user.part.30':
> ./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has impossible constraints
> __asm__ __volatile__( \
> ^
> ./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
> # define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro 'unsafe_op_wrap'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> ./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro '__get_user_asm'
> case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
> ^
> ./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro '__get_user_size_allowed'
> __get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
> ^
> ./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro '__get_user_nocheck'
> __get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro '__get_user_allowed'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
> unsafe_get_user(len, &uiov[i].iov_len, uaccess_end);
> ^
> make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
>
> [...]
Patches 2-3 applied to powerpc/next.
[2/3] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
https://git.kernel.org/powerpc/c/d85be8a49e733dcd23674aa6202870d54bf5600d
[3/3] powerpc: Fix update form addressing in inline assembly
https://git.kernel.org/powerpc/c/ff57698a9610fcf7d9c4469bf68c881eff22e2f8
cheers
^ permalink raw reply
* Re: [PATCH V4 0/5] ocxl: Mmio invalidation support
From: Michael Ellerman @ 2020-12-10 11:30 UTC (permalink / raw)
To: fbarrat, ajd, Christophe Lombard, linuxppc-dev
In-Reply-To: <20201125155013.39955-1-clombard@linux.vnet.ibm.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On Wed, 25 Nov 2020 16:50:08 +0100, Christophe Lombard wrote:
> OpenCAPI 4.0/5.0 with TLBI/SLBI Snooping, is not used due to performance
> problems caused by the PAU having to process all incoming TLBI/SLBI
> commands which will cause them to back up on the PowerBus.
>
> When the Address Translation Mode requires TLB operations to be initiated
> using MMIO registers, a set of registers like the following is used:
> • XTS MMIO ATSD0 LPARID register
> • XTS MMIO ATSD0 AVA register
> • XTS MMIO ATSD0 launch register, write access initiates a shoot down
> • XTS MMIO ATSD0 status register
>
> [...]
Applied to powerpc/next.
[1/5] ocxl: Assign a register set to a Logical Partition
https://git.kernel.org/powerpc/c/fc1347b5feb685073ce2108c68cd8147340be016
[2/5] ocxl: Initiate a TLB invalidate command
https://git.kernel.org/powerpc/c/19b311ca51e108b6d8d679496af8635fdc1984a8
[3/5] ocxl: Update the Process Element Entry
https://git.kernel.org/powerpc/c/d731feea00c7c1734c9697558f2a1962c12d2710
[4/5] ocxl: Add mmu notifier
https://git.kernel.org/powerpc/c/5f686eea4b3cb1d311f02b81ce4264e66a21d979
[5/5] ocxl: Add new kernel traces
https://git.kernel.org/powerpc/c/98f5559a439a68e0773f42352f7c0806cac9e76e
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox