Re: [PATCH v2] powerpc: A new cache geometry aux vectors

Paul Clarke writes: > P9 (with bad device-tree): > -- > # ./cache_shape > test: cache_shape > tags: git_version:v4.10-0-gc470abd-dirty > L1I cache size: 0 0B 0K > L1I line size:0x80 fully associative > L1D cache size: 0

Re: [PATCH] powerpc/mm: Fix page table dump build on non-Book3S

On 12/01/2016 04:00 AM, Michael Ellerman wrote: In the recent commit 1515ab932156 ("powerpc/mm: Dump hash table") we added code to dump the hage page table. Currently this can be selected to build on any platform. However it breaks the build if we're building for a non-Book3S platform, because

Re: [PATCH kernel v6 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

On 06/03/17 15:30, David Gibson wrote: > On Fri, Mar 03, 2017 at 06:09:25PM +1100, Alexey Kardashevskiy wrote: >> On 03/03/17 16:59, David Gibson wrote: >>> On Thu, Mar 02, 2017 at 07:56:44PM +1100, Alexey Kardashevskiy wrote: This allows the host kernel to handle H_PUT_TCE,

Re: [PATCH v3] powernv/sensor: Handle OPAL_WRONG_STATE error return

Hi Vipin, Minor spell fix in the patch description: Vipin K Parashar writes: > OPAL returns OPAL_WRONG_STATE upon failing to provide > sensor data due to core sleeping/offline. Added check > for OPAL_WRONG_STATE rerurn code with sensor read failure. s/rerurn/return >

Re: [PATCH] crypto: powerpc - Fix initialisation of crc32c context

Daniel Axtens writes: > Turning on crypto self-tests on a POWER8 shows: > > alg: hash: Test 1 failed for crc32c-vpmsum > : ff ff ff ff > > Comparing the code with the Intel CRC32c implementation on which > ours is based shows that we are doing an init with 0, not

Re: [PATCH kernel v6 10/10] KVM: PPC: VFIO: Add in-kernel acceleration for VFIO

On Fri, Mar 03, 2017 at 06:09:25PM +1100, Alexey Kardashevskiy wrote: > On 03/03/17 16:59, David Gibson wrote: > > On Thu, Mar 02, 2017 at 07:56:44PM +1100, Alexey Kardashevskiy wrote: > >> This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT > >> and H_STUFF_TCE requests targeted

Re: [PATCH kernel] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

On 06/03/17 14:36, Benjamin Herrenschmidt wrote: > On Mon, 2017-03-06 at 12:28 +1100, Alexey Kardashevskiy wrote: >> 8192*8192*8192*65536>>40 = 32768TB of addressable memory (but there is no >> good reason not to use huge pages); > > No, 39 bits is half a TB. That's not enough. Ah. My bad. 55

Re: [PATCH V3 08/10] powerpc/mm/hash: Increase VA range to 128TB

"Aneesh Kumar K.V" writes: > Michal Suchánek writes: > >> Hello, >> >> On Sun, 19 Feb 2017 15:37:15 +0530 >> "Aneesh Kumar K.V" wrote: >> >>> We update the hash linux page table layout such that we can support

Re: [PATCH kernel] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

On Mon, 2017-03-06 at 12:28 +1100, Alexey Kardashevskiy wrote: > 8192*8192*8192*65536>>40 = 32768TB of addressable memory (but there is no > good reason not to use huge pages); No, 39 bits is half a TB. That's not enough. > 8192*8192*8192*4096>>40 = 2048TB or addressable memory (even with 2 >

Re: [PATCH] crypto: powerpc - Fix initialisation of crc32c context

Hi Daniel, > Turning on crypto self-tests on a POWER8 shows: > > alg: hash: Test 1 failed for crc32c-vpmsum > : ff ff ff ff > > Comparing the code with the Intel CRC32c implementation on which > ours is based shows that we are doing an init with 0, not ~0 > as CRC32c requires. >

Re: [PATCH V3 08/10] powerpc/mm/hash: Increase VA range to 128TB

Michal Suchánek writes: > Hello, > > On Sun, 19 Feb 2017 15:37:15 +0530 > "Aneesh Kumar K.V" wrote: > >> We update the hash linux page table layout such that we can support >> 512TB. But we limit the TASK_SIZE to 128TB. We can switch to 128TB

Re: [PATCH] MIPS: jump_lable: Give __jump_table elements an entsize.

Hi David, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc1 next-20170303] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/3] futex: remove duplicated code

On Fri, Mar 03, 2017 at 01:27:10PM +0100, Jiri Slaby wrote: > There is code duplicated over all architecture's headers for > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr, > and comparison of the result. > > Remove this duplication and leave up to the arches only the

Re: [PATCH] powerpc/eeh: Avoid use after free in eeh_handle_special_event()

On 06/03/17 10:22, Gavin Shan wrote: > On Fri, Mar 03, 2017 at 04:59:11PM +1100, Alexey Kardashevskiy wrote: >> On 03/03/17 15:47, Russell Currey wrote: >>> eeh_handle_special_event() is called when an EEH event is detected but >>> can't be narrowed down to a specific PE. This function looks

Re: [PATCH kernel] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

On 06/03/17 10:03, Benjamin Herrenschmidt wrote: > On Mon, 2017-02-27 at 22:00 +1100, Michael Ellerman wrote: >>> The alternative would be allocating TCE tables as big as PAGE_SIZE >>> but >>> only using parts of it but this would complicate a bit bits of code >>> responsible for overall amount of

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Sun, 2017-03-05 at 18:10 -0600, Segher Boessenkool wrote: > You cannot really have something at address 0, the way NULL pointers > are represented in GCC.  0 in firmware, so *fun*, especially before > the > CFAR was invented.  "Something jumped to 0, CTR is 0 so it's probably > a BCTR, but

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Mon, Mar 06, 2017 at 10:09:01AM +1100, Benjamin Herrenschmidt wrote: > > The compiler can do whatever it likes with code that has undefined > > behaviour.  With this optimisation it a) can compile the conforming > > code to something better; and b) undefined behaviour will trap instead > > of

Re: [PATCH] powerpc/eeh: Avoid use after free in eeh_handle_special_event()

On Fri, Mar 03, 2017 at 04:59:11PM +1100, Alexey Kardashevskiy wrote: >On 03/03/17 15:47, Russell Currey wrote: >> eeh_handle_special_event() is called when an EEH event is detected but >> can't be narrowed down to a specific PE. This function looks through >> every PE to find one in an erroneous

Re: [PATCH v2] powerpc: A new cache geometry aux vectors

On Fri, 2017-03-03 at 07:51 -0600, Paul Clarke wrote: > > On P9 it all comes from the device tree so if that's wrong the AUX > > vectors will definitely be wrong. > > mambo-p9 is still falling victim to the device-tree, but "working": > -- > getauxval(AT_L1I_CACHEGEOMETRY) = 0x0080 >

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Sun, 2017-03-05 at 11:24 -0600, Segher Boessenkool wrote: > On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote: > > > > Erk sorry. One of the static checkers spotted it, but I hadn't got > > > > around to fixing it because it seemed to not actually blow up, guess > > > > not. > > >

Re: [PATCH v3] powerpc/xics: Work around limitations of OPAL XICS priority handling

On Sat, 2017-03-04 at 23:03 +1100, Michael Ellerman wrote: > + > +   /* Allow "sufficient" time to drop any inflight IRQ's */ > +   mdelay(1); > + According to the HW guys, that should be 5ms in case the powerbus is really really busy. Cheers, Ben.

Re: [PATCH] powerpc/xics: Fix migrate_irqs_away - set CPPR to lowest priority

On Mon, 2017-02-27 at 23:03 +1100, Michael Ellerman wrote: > It took me a while to parse that. > > So because of the way the OPAL XICS emulation is implemented, setting > the CPPR to DEFAULT_PRIORITY has the effect of masking all > interrupts. > > That is because the OPAL code internally maps

Re: [PATCH kernel] powerpc/powernv/ioda2: Gracefully fail if too many TCE levels requested

On Mon, 2017-02-27 at 22:00 +1100, Michael Ellerman wrote: > > The alternative would be allocating TCE tables as big as PAGE_SIZE > > but > > only using parts of it but this would complicate a bit bits of code > > responsible for overall amount of memory used for TCE table. > > > > Or

[PATCH] powerpc: sparsemem should be the default on powernv

This is especially true of POWER9 where memory between chips is discontiguous. Signed-off-by: Benjamin Herrenschmidt --- diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 4940917..c4b4c55 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@

[PATCH] net: toshiba: ps3_genic_net: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/toshiba/ps3_gelic_net.c | 51

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Sun, Mar 05, 2017 at 05:58:37PM +0100, Gabriel Paubert wrote: > > > Erk sorry. One of the static checkers spotted it, but I hadn't got > > > around to fixing it because it seemed to not actually blow up, guess > > > not. > > > > The PowerPC divw etc. instructions do not trap by themselves, but

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Sun, Mar 05, 2017 at 06:37:37AM -0600, Segher Boessenkool wrote: > On Sun, Mar 05, 2017 at 09:26:47PM +1100, Michael Ellerman wrote: > > > I see a panic in early boot when building with a recent gcc toolchain. > > > The issue is a divide by zero, which is undefined. Older toolchains > > > let

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

On Sun, Mar 05, 2017 at 09:26:47PM +1100, Michael Ellerman wrote: > > I see a panic in early boot when building with a recent gcc toolchain. > > The issue is a divide by zero, which is undefined. Older toolchains > > let us get away with it: > > > > int foo(int a) { return a / 0; } > > > > foo: >

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

Anton Blanchard writes: > diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c > index adf2084..afd1c26 100644 > --- a/arch/powerpc/kernel/setup_64.c > +++ b/arch/powerpc/kernel/setup_64.c > @@ -408,7 +408,8 @@ static void init_cache_info(struct

Re: [PATCH] powerpc: Avoid panic during boot due to divide by zero in init_cache_info()

Anton Blanchard writes: > From: Anton Blanchard > > I see a panic in early boot when building with a recent gcc toolchain. > The issue is a divide by zero, which is undefined. Older toolchains > let us get away with it: > > int foo(int a) { return a / 0; } > >

[PATCH v3] powernv/sensor: Handle OPAL_WRONG_STATE error return

OPAL returns OPAL_WRONG_STATE upon failing to provide sensor data due to core sleeping/offline. Added check for OPAL_WRONG_STATE rerurn code with sensor read failure. Also added a log message indicating sensor data being queried for sleeping/offline core. Signed-off-by: Vipin K Parashar

Re: [PATCH v2] powernv/opal: Handle OPAL_WRONG_STATE error from OPAL fails

On Thursday 02 March 2017 06:00 PM, Vipin K Parashar wrote: Hi Stewart/Michael, Thanks!! for review. Responses as below: On Wednesday 01 March 2017 02:38 AM, Stewart Smith wrote: Vipin K Parashar writes: Added check for OPAL_WRONG_STATE error code returned from

[PATCH 6/6] powerpc/perf: Add Power8 mem_access event to sysfs

Patch add "mem_access" event to sysfs. This as-is not a raw event supported by Power8 pmu. Instead, it is formed based on raw event encoding specificed in isa207-common.h. Primary PMU event used here is PM_MRK_INST_CMPL. This event tracks only the completed marked instructions. Random sampling

[PATCH 5/6] powerpc/perf: Support to export SIERs bit in Power9

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Signed-off-by: Madhavan Srinivasan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Sukadev Bhattiprolu

[PATCH 4/6] powerpc/perf: Support to export SIERs bit in Power8

Patch to export SIER bits to userspace via perf_mem_data_src and perf_sample_data struct. Signed-off-by: Madhavan Srinivasan Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Sukadev Bhattiprolu

[PATCH 1/6] powerpc/perf: Define big-endian version of perf_mem_data_src

perf_mem_data_src is an union that is initialized via the ->val field and accessed via the bitmap fields. For this to work on big endian platforms, we also need a big-endian represenation of perf_mem_data_src. Signed-off-by: Madhavan Srinivasan Cc: Peter Zijlstra

[PATCH 3/6] powerpc/perf: Support to export MMCRA[TEC*] field to userspace

Threshold feature when used with MMCRA [Threshold Event Counter Event], MMCRA[Threshold Start event] and MMCRA[Threshold End event] will update MMCRA[Threashold Event Counter Exponent] and MMCRA[Threshold Event Counter Multiplier] with the corresponding threshold event count values. Patch to

[PATCH 2/6] powerpc/perf: Export memory hierarchy info to user space

The LDST field and DATA_SRC in SIER identifies the memory hierarchy level (eg: L1, L2 etc), from which a data-cache miss for a marked instruction was satisfied. Use the 'perf_mem_data_src' object to export this hierarchy level to user space. Signed-off-by: Madhavan Srinivasan

[PATCH 0/6] powerpc/perf: Export memory hierarchy level

Power8/Power9 Perforence Monitoring Unit (PMU) supports different sampling modes (SM) such as Random Instruction Sampling (RIS), Random Load/Store Facility Sampling (RLS) and Random Branch Sampling (RBS). Sample mode RLS updates Sampled Instruction Event Register [SIER] bits with memory hierarchy