[RFC PATCH 09/10] powerpc/64: Add L2 and L3 cache shape info

Retrieved from device-tree when available Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/cache.h | 2 ++ arch/powerpc/kernel/setup_64.c | 27 ++- 2 files changed, 24 insertions(+), 5 deletions(-) diff --git

[RFC PATCH 10/10] powerpc/64: Hard code cache geometry on POWER8

All shipping firmware versions have it wrong in the device-tree Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/setup_64.c | 52 +++--- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git

[RFC PATCH 05/10] powerpc/64: Fix naming of cache block vs. cache line

In a number of places we called "cache line size" what is actually the cache block size, which in the powerpc architecture, means the effective size to use with cache management instructions (it can be different from the actual cache line size). We fix the naming across the board and properly

[RFC PATCH 07/10] powerpc/64: Build L1 cache shape info for userspace

Now that we have all the necessary information available we can build the L1 cache shape info to be passed down to userspace via the ELF AUX vectors. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/setup_64.c | 34 ++ 1

[RFC PATCH 08/10] powerpc/64: Clean up ppc64_caches using a struct per cache

We have two set of identical struct members for the I and D sides and mostly identical bunches of code to parse the device-tree to populate them. Instead make a ppc_cache_info structure with one copy for I and one for D Signed-off-by: Benjamin Herrenschmidt ---

[RFC PATCH 06/10] powerpc/64: Retrieve number of L1 cache sets from device-tree

It will be used to calculate the associativity Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/cache.h | 2 ++ arch/powerpc/kernel/setup_64.c | 27 +-- 2 files changed, 27 insertions(+), 2 deletions(-) diff --git

[RFC PATCH 03/10] powerpc: A new cache shape aux vectors

The definition is loosely based on sh and alpha, modified to accomodate larger associativity and cache size for future-proofing. We currently set all the values to -1 which indicates that the information isn't available. Signed-off-by: Benjamin Herrenschmidt ---

[RFC PATCH 04/10] powerpc: Remove obsolete comment about patching instructions

We don't patch instructions based on the cache lines or block sizes these days. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/setup_64.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/arch/powerpc/kernel/setup_64.c

[RFC PATCH 02/10] powerpc: Move {d, i, u}cache_bsize definitions to a common place

The variables are defined twice in setup_32.c and setup_64.c, do it once in setup-common.c instead Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/kernel/setup-common.c | 9 + arch/powerpc/kernel/setup_32.c | 8

[RFC PATCH 01/10] powerpc: Move ARCH_DLINFO out of uapi

It's an kernel private macro, it doesn't belong there Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/elf.h | 22 ++ arch/powerpc/include/uapi/asm/elf.h | 23 --- 2 files changed, 22 insertions(+), 23

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

Hello Dave, Am Mittwoch, 17 August 2016, 10:52:26 schrieb Dave Young: > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > > This series applies on top of v5 of the "kexec_file_load implementation > > for PowerPC" patch series (which applies on top of v4.8-rc1): > > > >

Re: [PATCH v3 06/21] powerpc: signals: Stop using current in signal code

Hi Cyril, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.8-rc2 next-20160816] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyril-Bur/Consistent-TM-structures/20160817

Re: [PATCH v3 04/21] powerpc: Return the new MSR from msr_check_and_set()

On Wed, 2016-08-17 at 13:43 +1000, Cyril Bur wrote: I obviously didn't proof read that one. This commit message should have read: mfmsr() is a fairly expensive call and callers of msr_check_and_set() may want to make decisions based on the MSR bits that it did not change but may not know the

[PATCH v3 01/21] selftests/powerpc: Compile selftests against headers without AT_HWCAP2

It might be nice to compile selftests against older kernels and headers but which may not have HWCAP2. Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/utils.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/powerpc/utils.h

[PATCH v3 11/21] selftests/powerpc: Add transactional memory defines

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/basic_asm.h | 4 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/powerpc/basic_asm.h b/tools/testing/selftests/powerpc/basic_asm.h index 3349a07..5131059 100644 ---

[PATCH v3 19/21] powerpc: tm: Always use fp_state and vr_state to store live registers

There is currently an inconsistency as to how the entire CPU register state is saved and restored when a thread uses transactional memory (TM). Using transactional memory results in the CPU having duplicated (almost all) of its register state. This duplication results in a set of registers which

[PATCH v3 20/21] powerpc: tm: Rename transct_(*) to ck(\1)_state

Make the structures being used for checkpointed state named consistently with the pt_regs/ckpt_regs. Signed-off-by: Cyril Bur --- arch/powerpc/include/asm/processor.h | 8 ++--- arch/powerpc/kernel/asm-offsets.c| 12 arch/powerpc/kernel/fpu.S| 2 +-

[PATCH v3 07/21] selftests/powerpc: Check for VSX preservation across userspace preemption

Ensure the kernel correctly switches VSX registers correctly. VSX registers are all volatile, and despite the kernel preserving VSX across syscalls, it doesn't have to. Test that during interrupts and timeslices ending the VSX regs remain the same. Signed-off-by: Cyril Bur

[PATCH v3 00/21] Consistent TM structures

V3: In v2 the MSR_{FP,VEC,VSX} bits were left on (if in use) after a reclaim which meant that signal code did the correct thing. This also meant that the bits would stay on when a (transactional) thread was not running and ptrace flush code would notice that tasks not current have MSR_{FP,VEC,VSX}

[PATCH v3 13/21] selftests/powerpc: Add TM tcheck helpers in C

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/tm/tm.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/tools/testing/selftests/powerpc/tm/tm.h b/tools/testing/selftests/powerpc/tm/tm.h index 60318ba..2c8da74 100644 ---

[PATCH v3 12/21] selftests/powerpc: Allow tests to extend their kill timeout

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/harness.c | 9 +++-- tools/testing/selftests/powerpc/utils.h | 2 +- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/powerpc/harness.c

[PATCH v3 15/21] selftests/powerpc: Add checks for transactional GPRs in signal contexts

If a thread receives a signal while transactional the kernel creates a second context to show the transactional state of the process. This test loads some known values and waits for a signal and confirms that the expected values are in the signal context. Signed-off-by: Cyril Bur

[PATCH v3 05/21] powerpc: Never giveup a reclaimed thread when enabling kernel {fp, altivec, vsx}

After a thread is reclaimed from its active or suspended transactional state the checkpointed state exists on CPU, this state (along with the live/transactional state) has been saved in its entirety by the reclaiming process. There exists a sequence of events that would cause the kernel to call

[PATCH v3 14/21] selftests/powerpc: Check that signals always get delivered

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/Makefile | 1 + tools/testing/selftests/powerpc/signal/Makefile| 12 +++ tools/testing/selftests/powerpc/signal/signal.S| 50 ++ tools/testing/selftests/powerpc/signal/signal.c| 111

[PATCH v3 03/21] powerpc: Add check_if_tm_restore_required() to giveup_all()

giveup_all() causes FPU/VMX/VSX facilitities to be disabled in a threads MSR. If this thread was transactional this should be recorded as reclaiming/recheckpointing code will need to know. Fixes: c208505 ("powerpc: create giveup_all()") Signed-off-by: Cyril Bur ---

[PATCH v3 16/21] selftests/powerpc: Add checks for transactional FPUs in signal contexts

If a thread receives a signal while transactional the kernel creates a second context to show the transactional state of the process. This test loads some known values and waits for a signal and confirms that the expected values are in the signal context. Signed-off-by: Cyril Bur

[PATCH v3 17/21] selftests/powerpc: Add checks for transactional VMXs in signal contexts

If a thread receives a signal while transactional the kernel creates a second context to show the transactional state of the process. This test loads some known values and waits for a signal and confirms that the expected values are in the signal context. Signed-off-by: Cyril Bur

[PATCH v3 09/21] selftests/powerpc: Move VMX stack frame macros to header file

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/math/vmx_asm.S | 85 +- tools/testing/selftests/powerpc/vmx_asm.h | 98 ++ 2 files changed, 99 insertions(+), 84 deletions(-) create mode 100644

[PATCH v3 02/21] powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use

Comment from arch/powerpc/kernel/process.c:967: If userspace is inside a transaction (whether active or suspended) and FP/VMX/VSX instructions have ever been enabled inside that transaction, then we have to keep them enabled and keep the FP/VMX/VSX state loaded while ever the transaction

[PATCH v3 21/21] powerpc: Remove do_load_up_transact_{fpu,altivec}

Previous rework of TM code leaves these functions unused Signed-off-by: Cyril Bur --- arch/powerpc/include/asm/tm.h | 5 - arch/powerpc/kernel/fpu.S | 26 -- arch/powerpc/kernel/vector.S | 25 - 3 files changed, 56

[PATCH v3 06/21] powerpc: signals: Stop using current in signal code

Much of the signal code takes a pt_regs on which it operates. Over time the signal code has needed to know more about the thread than what pt_regs can supply, this information is obtained as needed by using 'current'. This approach is not strictly incorrect however it does mean that there is now

[PATCH v3 10/21] selftests/powerpc: Introduce GPR asm helper header file

Signed-off-by: Cyril Bur --- tools/testing/selftests/powerpc/gpr_asm.h | 96 +++ 1 file changed, 96 insertions(+) create mode 100644 tools/testing/selftests/powerpc/gpr_asm.h diff --git a/tools/testing/selftests/powerpc/gpr_asm.h

[PATCH v3 18/21] selftests/powerpc: Add checks for transactional VSXs in signal contexts

If a thread receives a signal while transactional the kernel creates a second context to show the transactional state of the process. This test loads some known values and waits for a signal and confirms that the expected values are in the signal context. Signed-off-by: Cyril Bur

[PATCH v3 04/21] powerpc: Return the new MSR from msr_check_and_set()

mfmsr() is a fairly expensive call and callers of msr_check_and_set() may want to make decisions bits in the MSR that it did not change but may not know the value of. This patch would avoid a two calls to mfmsr(). Signed-off-by: Cyril Bur --- arch/powerpc/include/asm/reg.h

[PATCH v3 08/21] selftests/powerpc: Rework FPU stack placement macros and move to header file

The FPU regs are placed at the top of the stack frame. Currently the position expected to be passed to the macro. The macros now should be passed the stack frame size and from there they can calculate where to put the regs, this makes the use simpler. Also move them to a header file to be used in

Re: [PATCH v2 0/6] kexec_file: Add buffer hand-over for the next kernel

On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote: > Hello, > > This patch series implements a mechanism which allows the kernel to pass > on a buffer to the kernel that will be kexec'd. This buffer is passed > as a segment which is added to the kimage when it is being prepared > by

Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

On 17/08/16 04:49, Thiago Jung Bauermann wrote: > Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh: >> On 16/08/16 00:49, Thiago Jung Bauermann wrote: >>> Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann

linux-next: build warnings after merge of the kbuild tree

Hi Michal, After merging the kbuild tree, today's linux-next build (powerpc ppc64_defconfig) produced these warnings: WARNING: 25 bad relocations c0cf2570 R_PPC64_ADDR64__crc___arch_hweight16 c0cf2578 R_PPC64_ADDR64__crc___arch_hweight32 c0cf2580 R_PPC64_ADDR64

Re: debug problems on ppc 83xx target due to changed struct task_struct

On Mon, 2016-08-15 at 09:19 -0700, Dave Hansen wrote: >  > Wow, thanks for all the debugging here! Yup, thanks, that's really odd... I wonder if one of those structures is accessed beyond it's boundary, either the sigset or the thread struct, causing corruption of neighbouring fields in task

Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

Am Dienstag, 16 August 2016, 16:15:55 schrieb Balbir Singh: > On 16/08/16 00:49, Thiago Jung Bauermann wrote: > > Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: > >> On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote: > >>> Adapt all callers to the new function

Re: debug problems on ppc 83xx target due to changed struct task_struct

On 08/16/2016 10:27 AM, christophe leroy wrote: > If I debug a very small app, it gets stuck quickly after the app has > stopped: indeed, the console seems ok but as soon as I try to execute > something simple, like a ps or top, it get stuck. The target still > responds to pings, but nothing else.

Re: debug problems on ppc 83xx target due to changed struct task_struct

Le 15/08/2016 à 18:19, Dave Hansen a écrit : On 08/15/2016 07:35 AM, Holger Brunck wrote: I tried this but unfortunately the error only occurs while remote debugging. Locally with gdb everything works fine. BTW we double-checked with a 85xx ppc target which is also 32-bit and it ends up with

Re: [PATCH v2 4/6] kexec_file: Add mechanism to update kexec segments.

Hello Andrew, Thank you for your review! Am Montag, 15 August 2016, 15:27:56 schrieb Andrew Morton: > On Sat, 13 Aug 2016 00:18:23 -0300 Thiago Jung Bauermann > wrote: > > +/** > > + * kexec_update_segment - update the contents of a kimage segment > > + * @buffer:

[PATCH] powerpc: migrate exception table users off module.h and onto extable.h

These files were only including module.h for exception table related functions. We've now separated that content out into its own file "extable.h" so now move over to that and avoid all the extra header content in module.h that we don't really need to compile these files. Cc: Benjamin

[PATCH] powerpc, hotplug: Avoid to touch non-existent cpumasks.

We observed a kernel oops when running a PPC guest with config NR_CPUS=4 and qemu option "-smp cores=1,threads=8": [ 30.634781] Unable to handle kernel paging request for data at address 0xc0014192eb17 [ 30.636173] Faulting instruction address: 0xc003e5cc [ 30.637069] Oops:

Re: [PATCH v5 04/13] powerpc: Factor out relocation code from module_64.c to elf_util_64.c.

On 16/08/16 09:25, Thiago Jung Bauermann wrote: > Am Montag, 15 August 2016, 17:46:34 schrieb Balbir Singh: >> On Thu, Aug 11, 2016 at 08:08:09PM -0300, Thiago Jung Bauermann wrote: >>> +/** >>> + * elf64_apply_relocate_add - apply 64 bit RELA relocations >>> + * @elf_info: Support

[PATCH v2] soc: fsl/qe: fix Oops on CPM1 (and likely CPM2)

Commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE muram") has changed the way muram is managed. genalloc uses kmalloc(), hence requires the SLAB to be up and running. On powerpc 8xx, cpm_reset() is called early during startup. cpm_reset() then calls cpm_muram_init() before SLAB is

Re: [PATCH v5 02/13] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

On 16/08/16 00:49, Thiago Jung Bauermann wrote: > Am Montag, 15 August 2016, 17:30:49 schrieb Balbir Singh: >> On Thu, Aug 11, 2016 at 08:08:07PM -0300, Thiago Jung Bauermann wrote: >>> Adapt all callers to the new function prototype. >> >> Could you please expand on this? > > Is the following