[PATCH tip/locking/core v5 2/6] atomics: Add test for atomic operations with _relaxed variants

Some atomic operations now have _relaxed/acquire/release variants, this patch then adds some trivial tests for two purpose: 1. test the behavior of these new operations in single-CPU environment. 2. make their code generated before we actually use them somewhere, so

[PATCH tip/locking/core v5 6/6] powerpc: atomic: Implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants

Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on which _release variants can be built. To avoid superfluous barriers in _acquire variants, we implement these operations with assembly code rather use __atomic_op_acquire() to build them automatically. For the same reason,

[PATCH tip/locking/core v5 4/6] powerpc: atomic: Implement atomic{, 64}_*_return_* variants

On powerpc, acquire and release semantics can be achieved with lightweight barriers("lwsync" and "ctrl+isync"), which can be used to implement __atomic_op_{acquire,release}. For release semantics, since we only need to ensure all memory accesses that issue before must take effects before the

[PATCH tip/locking/core v5 0/6] atomics: powerpc: Implement relaxed/acquire/release variants of some atomics

Hi all, This is v5 of the series. Link for v1: https://lkml.org/lkml/2015/8/27/798 Link for v2: https://lkml.org/lkml/2015/9/16/527 Link for v3: https://lkml.org/lkml/2015/10/12/368 Link for v4: https://lkml.org/lkml/2015/10/14/670 Changes since v4: * define PPC_ATOMIC_ENTRY_BARRIER as

[PATCH tip/locking/core v5 3/6] atomics: Allow architectures to define their own __atomic_op_* helpers

Some architectures may have their special barriers for acquire, release and fence semantics, so that general memory barriers(smp_mb__*_atomic()) in the default __atomic_op_*() may be too strong, so allow architectures to define their own helpers which can overwrite the default helpers.

Re: [PATCH tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

On Mon, Oct 26, 2015 at 05:50:52PM +0800, Boqun Feng wrote: > This patch fixes two problems to make value-returning atomics and > {cmp}xchg fully ordered on PPC. > > According to memory-barriers.txt: > > > Any atomic operation that modifies some state in memory and returns > > information about

[PATCH RESEND tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

This patch fixes two problems to make value-returning atomics and {cmp}xchg fully ordered on PPC. According to memory-barriers.txt: > Any atomic operation that modifies some state in memory and returns > information about the state (old or new) implies an SMP-conditional > general memory barrier

[PATCH tip/locking/core v5 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

This patch fixes two problems to make value-returning atomics and {cmp}xchg fully ordered on PPC. According to memory-barriers.txt: > Any atomic operation that modifies some state in memory and returns > information about the state (old or new) implies an SMP-conditional > general memory barrier

[PATCH tip/locking/core v5 5/6] powerpc: atomic: Implement xchg_* and atomic{, 64}_xchg_* variants

Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these _relaxed variants, release/acquire variants and fully ordered versions can be built. Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler barriers. Signed-off-by: Boqun Feng ---

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Mon, Oct 26, 2015 at 11:20:01AM +0900, Michael Ellerman wrote: > > Sorry guys, these threads are so long I tend not to read them very actively :} > > Looking at the system call path, the straight line path does not include any > barriers. I can't see any hidden in macros either. > > We also

Re: [PATCH v9 1/4] perf, kvm/{x86, s390}: Remove dependency on uapi/kvm_perf.h

Hi Arnaldo, Could you please take a look at this series and pull it? --- Thanks, Hemant On 10/07/2015 07:55 AM, Hemant Kumar wrote: Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic discovery of kvm events (if its needed). To do this, some extern variables have been

[PATCH v4] Documentation: dt: binding: fsl: add devicetree binding for describing RCPM

From: Wang Dongsheng RCPM is the Run Control and Power Management module performs all device-level tasks associated with device run control and power management. Add this for freescale powerpc platform and layerscape platform. Signed-off-by: Chenhui Zhao

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Mon, Oct 26, 2015 at 02:20:21PM +1100, Paul Mackerras wrote: > On Wed, Oct 21, 2015 at 10:18:33AM +0200, Peter Zijlstra wrote: > > On Tue, Oct 20, 2015 at 02:28:35PM -0700, Paul E. McKenney wrote: > > > I am not seeing a sync there, but I really have to defer to the > > > maintainers on this

[PATCH v18 05/19] perf, tools: Support CPU id matching for x86 v2

From: Andi Kleen Implement the code to match CPU types to mapfile types for x86 based on CPUID. This extends an existing similar function, but changes it to use the x86 mapfile cpu description. This allows to resolve event lists generated by jevents. Signed-off-by: Andi

[PATCH v18 02/19] perf, tools, jevents: Program to convert JSON file to C style file

From: Andi Kleen This is a modified version of an earlier patch by Andi Kleen. We expect architectures to describe the performance monitoring events for each CPU in a corresponding JSON file, which look like: [ { "EventCode": "0x00",

[PATCH v18 11/19] perf, tools: Add alias support for long descriptions

Previously we were dropping the useful longer descriptions that some events have in the event list completely. Now that jevents provides support for longer descriptions (see previous patch), add support for parsing the long descriptions Signed-off-by: Andi Kleen

[PATCH v18 16/19] perf, tools: Add README for info on parsing JSON/map files

Signed-off-by: Sukadev Bhattiprolu Acked-by: Jiri Olsa --- tools/perf/pmu-events/README | 122 +++ 1 file changed, 122 insertions(+) create mode 100644 tools/perf/pmu-events/README diff --git

[PATCH v18 06/19] perf, tools: Support alias descriptions

From: Andi Kleen Add support to print alias descriptions in perf list, which are taken from the generated event files. The sorting code is changed to put the events with descriptions at the end. The descriptions are printed as possibly multiple word wrapped lines. Example

[PATCH v17 00/19] perf, tools: Add support for PMU events in JSON format

CPUs support a large number of performance monitoring events (PMU events) and often these events are very specific to an architecture/model of the CPU. To use most of these PMU events with perf, we currently have to identify them by their raw codes: perf stat -e r100f2 sleep 1 This

[PATCH v18 03/19] perf, tools: Use pmu_events table to create aliases

At run time (when 'perf' is starting up), locate the specific table of PMU events that corresponds to the current CPU. Using that table, create aliases for the each of the PMU events in the CPU. The use these aliases to parse the user specified perf event. In short this would allow the user to

[PATCH v18 15/19] perf, tools: Handle header line in mapfile

From: Andi Kleen To work with existing mapfiles, assume that the first line in 'mapfile.csv' is a header line and skip over it. Signed-off-by: Andi Kleen Signed-off-by: Sukadev Bhattiprolu Acked-by: Jiri Olsa

[PATCH] powerpc/pseries: Correct string length in pseries_of_derive_parent()

Commit a030e1e4bbd085bbcfd0a23f8d355fcd41f39bed made a change to use kstrndup() instead of kmalloc() + strlcpy() in pseries_of_derive_parent() which introduces a subtle change in the parent path name generated. The kstrndup() routine will copy n characters followed by a terminating null, whereas

Re: [PATCH] powerpc/pseries: Verify CPU doesn't exist before adding

On 10/25/2015 11:30 AM, Denis Kirjanov wrote: > On 10/23/15, Nathan Fontenot wrote: >> When DLPAR adding a CPU we should verify that the CPU does not already >> exist. Failure to do so can generate a kernel oops; >> >> [9.465585] kernel BUG at

[PATCH v18 10/19] perf, tools, jevents: Add support for long descriptions

Implement support in jevents to parse long descriptions for events that may have them in the JSON files. A follow on patch will make this long description available to user through the 'perf list' command. Signed-off-by: Andi Kleen Signed-off-by: Sukadev Bhattiprolu

[PATCH v18 12/19] perf, tools: Support long descriptions with perf list

Previously we were dropping the useful longer descriptions that some events have in the event list completely. This patch makes them appear with perf list. Old perf list: baclears: baclears.all [Counts the number of baclears] vs new: perf list -v: ... baclears: baclears.all

[PATCH v18 13/19] perf, tools, jevents: Add support for event topics

Allow assigning categories "Topics" field to the PMU events i.e. process the topic field from the JSON file and add a corresponding topic field to the generated C events tables. Signed-off-by: Andi Kleen Signed-off-by: Sukadev Bhattiprolu

[PATCH v18 08/19] perf, tools: Add a --no-desc flag to perf list

From: Andi Kleen Add a --no-desc flag to perf list to not print the event descriptions that were earlier added for JSON events. This may be useful to get a less crowded listing. It's still default to print descriptions as that is the more useful default for most users.

[PATCH v18 09/19] perf, tools: Add override support for event list CPUID

From: Andi Kleen Add a PERF_CPUID variable to override the CPUID of the current CPU (within the current architecture). This is useful for testing, so that all event lists can be tested on a single system. Signed-off-by: Andi Kleen Signed-off-by:

[PATCH v18 01/19] perf, tools: Add jsmn `jasmine' JSON parser

From: Andi Kleen I need a JSON parser. This adds the simplest JSON parser I could find -- Serge Zaitsev's jsmn `jasmine' -- to the perf library. I merely converted it to (mostly) Linux style and added support for non 0 terminated input. The parser is quite straight forward

[PATCH v18 17/19] perf, tools: Make alias matching case-insensitive

From: Andi Kleen Make alias matching the events parser case-insensitive. This is useful with the JSON events. perf uses lower case events, but the CPU manuals generally use upper case event names. The JSON files use lower case by default too. But if we search case

[PATCH v18 07/19] perf, tools: Query terminal width and use in perf list

From: Andi Kleen Automatically adapt the now wider and word wrapped perf list output to wider terminals. This requires querying the terminal before the auto pager takes over, and exporting this information from the pager subsystem. Signed-off-by: Andi Kleen

[PATCH v18 14/19] perf, tools: Add support for event list topics

From: Andi Kleen Add support to group the output of perf list by the Topic field in the JSON file. Example output: % perf list ... Cache: l1d.replacement [L1D data line replacements] l1d_pend_miss.pending [L1D miss oustandings duration in cycles]

[PATCH v18 18/19] perf, tools, pmu-events: Fix fixed counters on Intel

From: Andi Kleen The JSON event lists use a different encoding for fixed counters than perf for instructions and cycles (ref-cycles is ok) This lead to some common events like inst_retired.any or cpu_clk_unhalted.thread not counting, when specified with their JSON name.

Re: [PATCH 0/5 v3] Fix NVMe driver support on Power with 32-bit DMA

From: Nishanth Aravamudan Date: Fri, 23 Oct 2015 13:54:20 -0700 > 1) add a generic dma_get_page_shift implementation that just returns > PAGE_SHIFT I won't object to this patch series, but if I had implemented this I would have required the architectures to implement

[PATCH v18 04/19] perf, tools: Support CPU ID matching for Powerpc

Implement code that returns the generic CPU ID string for Powerpc. This will be used to identify the specific table of PMU events to parse/compare user specified events against. Signed-off-by: Sukadev Bhattiprolu Acked-by: Jiri Olsa ---

Re: [PATCH] powerpc/eeh: eeh_pci_enable(): fix checking of post-request state

Andrew Donnellan writes: > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c > index 40e4d4a..d757e7c 100644 > --- a/arch/powerpc/kernel/eeh.c > +++ b/arch/powerpc/kernel/eeh.c > @@ -677,7 +677,7 @@ int eeh_pci_enable(struct eeh_pe *pe, int

Re: [PATCH] powerpc/eeh: eeh_pci_enable(): fix checking of post-request state

Andrew Donnellan writes: > diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c > index 40e4d4a..d757e7c 100644 > --- a/arch/powerpc/kernel/eeh.c > +++ b/arch/powerpc/kernel/eeh.c > @@ -677,7 +677,7 @@ int eeh_pci_enable(struct eeh_pe *pe, int

[PATCH] powerpc/dma: Basic DMA operations shouldn't be GPL only

When turning these from inline to exported functions I was a bit over-eager and made them GPL only. This basically prevent use of any non-GPL PCI driver which is a bit over the top. Bring them in line with other architecture. Signed-off-by: Benjamin Herrenschmidt ---

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

On Tue, Oct 27, 2015 at 01:33:47PM +1100, Michael Ellerman wrote: > On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > > This patch fixes two problems to make value-returning atomics and > > {cmp}xchg fully ordered on PPC. > > Hi Boqun, > > Can you please split this into two patches. One

Re: [PATCH V10 03/12] powerpc/pci: Cache VF index in pci_dn

On 26/10/15 14:15, Wei Yang wrote: The patch caches the VF index in pci_dn, which can be used to calculate VF's bus, device and function number. Those information helps to locate the VF's PCI device instance when doing hotplug during EEH recovery if necessary. Signed-off-by: Wei Yang

Re: [PATCH V10 02/12] PCI: Add pcibios_bus_add_device() weak function

On 26/10/15 14:15, Wei Yang wrote: This patch adds a weak function pcibios_bus_add_device() for arch dependent code could do proper setup. For example, powerpc could setup EEH related resources. Signed-off-by: Wei Yang Acked-by: Bjorn Helgaas

Re: [PATCH v4 0/2] powerpc/512x: add LocalPlus Bus FIFO device driver

On Thu, Oct 22, 2015 at 01:15:03AM +0300, Alexander Popov wrote: > On 12.10.2015 00:08, Alexander Popov wrote: > > This driver for Freescale MPC512x LocalPlus Bus FIFO (called SCLPC > > in the Reference Manual) allows Direct Memory Access transfers > > between RAM and peripheral devices on

Re: [RESEND, tip/locking/core, v5, 1/6] powerpc: atomic: Make _return atomics and *{cmp}xchg fully ordered

On Mon, 2015-26-10 at 10:15:36 UTC, Boqun Feng wrote: > This patch fixes two problems to make value-returning atomics and > {cmp}xchg fully ordered on PPC. Hi Boqun, Can you please split this into two patches. One that does the cmpxchg change and one that changes PPC_ATOMIC_ENTRY_BARRIER. Also

Re: [PATCH V10 01/12] PCI/IOV: Rename and export virtfn_add/virtfn_remove

On 26/10/15 14:15, Wei Yang wrote: During EEH recovery, hotplug is applied to the devices which don't have drivers or their drivers don't support EEH. However, the hotplug, which was implemented based on PCI bus, can't be applied to VF directly. The patch renames virtn_{add,remove}() and

Re: [PATCH v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram

On Sun, 2015-10-25 at 22:15 -0500, Zhao Qiang-B45475 wrote: > On Sat, 2015-10-24 at 04:59 AM, Wood Scott-B07421 > wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Saturday, October 24, 2015 4:59 AM > > To: Zhao Qiang-B45475

Re: [PATCH v12 4/6] QE/CPM: move muram management functions to qe_common

On Sun, 2015-10-25 at 21:42 -0500, Zhao Qiang-B45475 wrote: > On Sat, Oct 24, 2015 at 04:56 AM, Wood Scott-B07421 wrote: > > -Original Message- > > From: Wood Scott-B07421 > > Sent: Saturday, October 24, 2015 4:56 AM > > To: Zhao Qiang-B45475 > > Cc:

Re: [PATCH 4/7 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

On 10/24/2015 07:59 AM, Nishanth Aravamudan wrote: When DDW (Dynamic DMA Windows) are present for a device, we have stored the TCE (Translation Control Entry) size in a special device tree property. Check if we have enabled DDW for the device and return the TCE size from that property if

[PATCH V2 2/3] tools/perf:Map the ID values with register names

The id values are mapped with the corresponding register names. This names are displayed while using a perf report/perf script command. Signed-off-by: Anju T --- tools/perf/arch/powerpc/include/perf_regs.h | 118 1 file changed, 118

[PATCH V2 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc

This short patch series add the ability to sample the interrupted machine state for each hardware sample Anju (3): perf/powerpc:add ability to sample intr machine state in power tools/perf:Map the ID values with register names perf/powerpc:add support for sampling intr machine state

[PATCH V2 3/3] perf/powerpc :add support for sampling intr machine state

The registers to sample are passed through the sample_regs_intr bitmask. The name and bit position for each register is defined in asm/perf_regs.h. This feature can be enabled by using -I option with perf record command. To display the sampled register values use perf script -D. The kernel uses

[PATCH V2 1/3] perf/powerpc:add ability to sample intr machine state in power

The enum definition assigns an 'id' to each register in "struct pt_regs" of arch/powerpc.The order of these values in the enum definition are based on the corresponding macros in arch/powerpc/include/uapi/asm/ptrace.h . Signed-off-by: Anju T ---

Re: [PATCH V2 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc

On 10/26/15, Anju T wrote: > This short patch series add the ability to sample the interrupted > machine state for each hardware sample Hi, how can we check your patch series without testing details? > > Anju (3): > perf/powerpc:add ability to sample intr machine

[PATCH v3 1/8] ppc64le FTRACE_WITH_REGS implementation

Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2. Initial work started by Vojtech Pavlik, used with permission. * arch/powerpc/kernel/entry_64.S: - enhance _mcount with a stub to support call sites generated by -mprofile-kernel. This is backward-compatible. - Implement an

[PATCH v3 2/8] ppc use ftrace_modify_all_code default

Convert ppc's arch_ftrace_update_code from its own function copy to use the generic default functionality (without stop_machine -- our instructions are properly aligned and the replacements atomic ;) With this we gain error checking and the much-needed function_trace_op handling. Signed-off-by:

Re: [PATCH v3 0/8] ftrace with regs + live patching for ppc64 LE (ABI v2)

* Makefile: - globally use -mprofile-kernel in case it's configured. * arch/powerpc/Kconfig / kernel/trace/Kconfig: - declare that ppc64 HAVE_MPROFILE_KERNEL and HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it. Signed-off-by: Torsten Duwe --- arch/powerpc/Kconfig | 2

[PATCH v3 5/8] ppc64 ftrace: disable profiling for some functions

At least POWER7/8 have MMUs that don't completely autoload; a normal, recoverable memory fault might pass through these functions. If a dynamic tracer function causes such a fault, any of these functions being traced with -mprofile-kernel may cause an endless recursion. Signed-off-by: Torsten

[PATCH v3 0/8] ftrace with regs + live patching for ppc64 LE (ABI v2)

Hi all, here is the current status of ftrace with regs, trace ops and live patching for ppc64le. It seems I broke the ftrace graph caller and I spent most of last week trying to fix it; Steven, maybe you could have a look? I startet out with -mprofile-kernel and now found that the ordinary -pg is

[PATCH v3 4/8] ppc64 ftrace_with_regs: spare early boot and low level

Using -mprofile-kernel on early boot code not only confuses the checker but is also useless, as the infrastructure is not yet in place. Proceed like with -pg (remove it from CFLAGS), equally with time.o and ftrace itself. * arch/powerpc/kernel/Makefile: - remove -mprofile-kernel from low

[PATCH v3 6/8] ppc64 ftrace: disable profiling for some files

This adds -mprofile-kernel to the cc flags to be stripped from the command line for code-patching.o and feature-fixups.o, in addition to "-pg" Signed-off-by: Torsten Duwe --- arch/powerpc/lib/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v3 7/8] Implement kernel live patching for ppc64le (ABIv2)

* create the appropriate files+functions arch/powerpc/include/asm/livepatch.h klp_check_compiler_support, klp_arch_set_pc arch/powerpc/kernel/livepatch.c with a stub for klp_write_module_reloc This is architecture-independent work in progress. * introduce a

[PATCH v3 3/8] ppc64 ftrace_with_regs configuration variables

* Makefile: - globally use -mprofile-kernel in case it's configured. * arch/powerpc/Kconfig / kernel/trace/Kconfig: - declare that ppc64 HAVE_MPROFILE_KERNEL and HAVE_DYNAMIC_FTRACE_WITH_REGS, and use it. Signed-off-by: Torsten Duwe --- arch/powerpc/Kconfig | 2

[PATCH v3 8/8] Enable LIVEPATCH to be configured on ppc64le and add livepatch.o if it is selected.

Signed-off-by: Torsten Duwe --- arch/powerpc/Kconfig | 5 + arch/powerpc/kernel/Makefile | 1 + 2 files changed, 6 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 0e6011c..341ebe9 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig

[PATCH v3 1/8] ppc64le FTRACE_WITH_REGS implementation

Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2. Initial work started by Vojtech Pavlik, used with permission. * arch/powerpc/kernel/entry_64.S: - enhance _mcount with a stub to support call sites generated by -mprofile-kernel. This is backward-compatible. - Implement an