LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2] cpuidle/powernv : Add Description for cpuidle state
From: Akshay Adiga @ 2018-06-05  9:08 UTC (permalink / raw)
  To: Abhishek
  Cc: Benjamin Herrenschmidt, stewart, linux-pm, daniel.lezcano, rjw,
	linux-kernel, paulus, linuxppc-dev
In-Reply-To: <17cd53ec-6bc1-5814-8824-3c6a4f0b90cd@linux.vnet.ibm.com>

On Tue, Jun 05, 2018 at 02:24:39PM +0530, Abhishek wrote:
> 
> 
> On 06/04/2018 05:15 PM, Akshay Adiga wrote:
> > On Mon, Jun 04, 2018 at 07:04:14PM +1000, Benjamin Herrenschmidt wrote:
> > > Is this a new property ? I'm not fan of adding yet another of those
> > > silly arrays.
> > > 
> > > I would say this is the right time now to switch over to a node per
> > > state instead, as we discussed with Vaidy.
> 
> It is not a new property. Name was being used for description as description
> was not present in device tree. A skiboot patch adding description to device
> tree have been posted. This patch reads those description instead of copying
> name itself into description. And we fall back to reading name into
> description to not break the comaptibility with older firmware.

>From a cpuidle point of view this is a exisiting property, but for
powernv there was no device-tree property describing this. 

Abhishek has added the following skiboot patch for adding description
for each idle state in device-tree .
https://patchwork.ozlabs.org/patch/924879/

I agree this can go into new device tree format which each idle state
as a node. Probably i will roll this patch into mine in the next
version.


> 
> Thanks
> Abhishek
> 
> > I posted  the node based device tree here :
> > skiboot patch :  https://patchwork.ozlabs.org/patch/923120/
> > kernel patch : https://lkml.org/lkml/2018/5/30/1146
> > 
> > Do you have any inputs for this design ?
> > 
> > > Additionally, while doing that, we can provide the versioning mechanism
> > > I proposed so we can deal with state specific issues and erratas.
> > > 
> > > Cheers,
> > > Ben.
> > > 
> 

^ permalink raw reply

* [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Wei Yongjun @ 2018-06-05  9:16 UTC (permalink / raw)
  To: Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
	Greg Kroah-Hartman, Alastair D'Silva
  Cc: Wei Yongjun, linuxppc-dev, linux-kernel, kernel-janitors

Add the missing unlock before return from function
afu_ioctl_enable_p9_wait() in the error handling case.

Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
 drivers/misc/ocxl/file.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 33ae46c..e6a6074 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
 		// Locks both status & tidr
 		mutex_lock(&ctx->status_mutex);
 		if (!ctx->tidr) {
-			if (set_thread_tidr(current))
+			if (set_thread_tidr(current)) {
+				mutex_unlock(&ctx->status_mutex);
 				return -ENOENT;
+			}
 
 			ctx->tidr = current->thread.tidr;
 		}

^ permalink raw reply related

* RE: [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Alastair D'Silva @ 2018-06-05  9:41 UTC (permalink / raw)
  To: 'Wei Yongjun', 'Frederic Barrat',
	'Andrew Donnellan', 'Arnd Bergmann',
	'Greg Kroah-Hartman'
  Cc: linuxppc-dev, linux-kernel, kernel-janitors
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>

> -----Original Message-----
> From: Wei Yongjun <weiyongjun1@huawei.com>
> Sent: Tuesday, 5 June 2018 7:16 PM
> To: Frederic Barrat <fbarrat@linux.vnet.ibm.com>; Andrew Donnellan
> <andrew.donnellan@au1.ibm.com>; Arnd Bergmann <arnd@arndb.de>;
> Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Alastair D'Silva
> <alastair@d-silva.org>
> Cc: Wei Yongjun <weiyongjun1@huawei.com>; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; kernel-
> janitors@vger.kernel.org
> Subject: [PATCH -next] ocxl: Fix missing unlock on error in
> afu_ioctl_enable_p9_wait()
> 
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
> 
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on
> POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
>  drivers/misc/ocxl/file.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c index
> 33ae46c..e6a6074 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct
> ocxl_context *ctx,
>  		// Locks both status & tidr
>  		mutex_lock(&ctx->status_mutex);
>  		if (!ctx->tidr) {
> -			if (set_thread_tidr(current))
> +			if (set_thread_tidr(current)) {
> +				mutex_unlock(&ctx->status_mutex);
>  				return -ENOENT;
> +			}
> 
>  			ctx->tidr = current->thread.tidr;
>  		}


Thanks for picking that up!

Reviewed-by: Alastair D'Silva <alastair@d-silva.org>

-- 
Alastair D'Silva           mob: 0423 762 819
skype: alastair_dsilva     msn: alastair@d-silva.org
blog: http://alastair.d-silva.org    Twitter: @EvilDeece

^ permalink raw reply

* Re: [PATCH] cpuidle:powernv: Make the snooze timeout dynamic.
From: Michael Ellerman @ 2018-06-05 12:18 UTC (permalink / raw)
  To: Gautham R Shenoy
  Cc: Gautham R. Shenoy, Rafael J. Wysocki, Daniel Lezcano,
	Stewart Smith, Michael Neuling, Vaidyanathan Srinivasan,
	Shilpasri G Bhat, Akshay Adiga, Nicholas Piggin, linuxppc-dev,
	linux-kernel, linux-pm
In-Reply-To: <20180605084529.GA5656@in.ibm.com>

Gautham R Shenoy <ego@linux.vnet.ibm.com> writes:
> Hello Michael,
>
> On Mon, Jun 04, 2018 at 09:27:40PM +1000, Michael Ellerman wrote:
>> "Gautham R. Shenoy" <ego@linux.vnet.ibm.com> writes:
>> 
>> > From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>> >
>> > The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
>> > snooze to deeper idle state") introduced a timeout for the snooze idle
>> > state so that it could be eventually be promoted to a deeper idle
>> > state. The snooze timeout value is static and set to the target
>> > residency of the next idle state, which would train the cpuidle
>> > governor to pick the next idle state eventually.
>> >
>> > The unfortunate side-effect of this is that if the next idle state(s)
>> > is disabled, the CPU will forever remain in snooze, despite the fact
>> > that the system is completely idle, and other deeper idle states are
>> > available.
>> 
>> That sounds like a bug, I'll add?
>
> Yes, this is a bug-fix for a customer scenario which we encountered
> recently.

OK, the change log could have used some more scary words to make that
clearer ;)

I changed the subject to:

  cpuidle: powernv: Fix promotion from snooze if next state disabled

Which hopefully makes sense.

>> Fixes: 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state")
>> Cc: stable@vger.kernel.org # v4.2+
>
> This patch applies cleanly from v4.13 onwards. Prior to that there are
> some (minor) conflicts.
>
> Should I spin a version separately for the prior stable versions ?

Yes please, that would be great.

You might want to avoid "=====" in the change log too, as patchwork and
possibly other tools will think it's part of the diff.

cheers

^ permalink raw reply

* Re: [v3] powerpc: fix build failure by disabling attribute-alias warning
From: Michael Ellerman @ 2018-06-05 12:21 UTC (permalink / raw)
  To: Christophe LEROY, Michael Ellerman, Benjamin Herrenschmidt,
	Paul Mackerras, segher
  Cc: linuxppc-dev, linux-kernel
In-Reply-To: <0332913c-04c0-362f-313f-8d42099f168d@c-s.fr>

Christophe LEROY <christophe.leroy@c-s.fr> writes:
> Le 04/06/2018 =C3=A0 16:11, Michael Ellerman a =C3=A9crit=C2=A0:
>> On Tue, 2018-05-29 at 16:06:41 UTC, Christophe Leroy wrote:
>>> Latest GCC version emit the following warnings
>>>
>>> As arch/powerpc code is built with -Werror, this breaks build with
>>> GCC 8.1
>>>
....
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>=20
>> Applied to powerpc next, thanks.
>>=20
>> https://git.kernel.org/powerpc/c/2479bfc9bc600dcce7f932d52dcfa8
>
> Oops, you didn't take v4 but v3 which was missing the fix into pci_32.c

Yep sorry. I had v3 in my tree since a few days.

If the patch is "Under Review" in patchwork that usually means I have it
applied and am testing it. Although sometimes I forget :)

> I'll send you a patch to add the fix in pci_32.c

Thanks, applied.

cheers

^ permalink raw reply

* Re: [RFC PATCH for 4.18 09/16] powerpc: Add syscall detection for restartable sequences
From: Mathieu Desnoyers @ 2018-06-05 12:50 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Peter Zijlstra, Paul E. McKenney, Boqun Feng, Andy Lutomirski,
	Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
	Russell King, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer, rostedt,
	Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
	Michael Kerrisk, Joel Fernandes, Benjamin Herrenschmidt,
	Paul Mackerras, linuxppc-dev
In-Reply-To: <871sdlbyg7.fsf@concordia.ellerman.id.au>

----- On Jun 5, 2018, at 1:21 AM, Michael Ellerman mpe@ellerman.id.au wrote:

> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
>> From: Boqun Feng <boqun.feng@gmail.com>
>>
>> Syscalls are not allowed inside restartable sequences, so add a call to
>> rseq_syscall() at the very beginning of system call exiting path for
>> CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect whether there
>> is a syscall issued inside restartable sequences.
>>
>> [ Tested on 64-bit powerpc kernel by Mathieu Desnoyers. Still needs to
>>   be tested on 32-bit powerpc kernel. ]
>>
>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Michael Ellerman <mpe@ellerman.id.au>
>> CC: Peter Zijlstra <peterz@infradead.org>
>> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> CC: linuxppc-dev@lists.ozlabs.org
>> ---
>>  arch/powerpc/kernel/entry_32.S | 7 +++++++
>>  arch/powerpc/kernel/entry_64.S | 8 ++++++++
>>  2 files changed, 15 insertions(+)
> 
> I don't _love_ the #ifdefs in here, but they look correct and there's
> not really a better option until we rewrite the syscall handler in C.
> 
> The rseq selftests passed for me with this applied and enabled. So if
> you like here's some tags:
> 
> Tested-by: Michael Ellerman <mpe@ellerman.id.au>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> 

Adding you ack to the series.

Thanks!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply

* Re: [RFC PATCH for 4.18 10/16] powerpc: Wire up restartable sequences system call
From: Mathieu Desnoyers @ 2018-06-05 12:51 UTC (permalink / raw)
  To: Michael Ellerman
  Cc: Peter Zijlstra, Paul E. McKenney, Boqun Feng, Andy Lutomirski,
	Dave Watson, linux-kernel, linux-api, Paul Turner, Andrew Morton,
	Russell King, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Andrew Hunter, Andi Kleen, Chris Lameter, Ben Maurer, rostedt,
	Josh Triplett, Linus Torvalds, Catalin Marinas, Will Deacon,
	Michael Kerrisk, Joel Fernandes, Benjamin Herrenschmidt,
	Paul Mackerras, linuxppc-dev
In-Reply-To: <874lihbykr.fsf@concordia.ellerman.id.au>

----- On Jun 5, 2018, at 1:18 AM, Michael Ellerman mpe@ellerman.id.au wrote:

> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> writes:
> 
>> From: Boqun Feng <boqun.feng@gmail.com>
>>
>> Wire up the rseq system call on powerpc.
>>
>> This provides an ABI improving the speed of a user-space getcpu
>> operation on powerpc by skipping the getcpu system call on the fast
>> path, as well as improving the speed of user-space operations on per-cpu
>> data compared to using load-reservation/store-conditional atomics.
>>
>> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Michael Ellerman <mpe@ellerman.id.au>
>> CC: Peter Zijlstra <peterz@infradead.org>
>> CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>> CC: linuxppc-dev@lists.ozlabs.org
>> ---
>>  arch/powerpc/include/asm/systbl.h      | 1 +
>>  arch/powerpc/include/asm/unistd.h      | 2 +-
>>  arch/powerpc/include/uapi/asm/unistd.h | 1 +
>>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> Looks fine to me.
> 
> I don't have any other new syscalls in my next, so this should not
> conflict with anything for 4.18.
> 
> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)

Added your ack to the series, thanks!

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

^ permalink raw reply

* Re: [PATCH -next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Frederic Barrat @ 2018-06-05 12:57 UTC (permalink / raw)
  To: Wei Yongjun, Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
	Greg Kroah-Hartman, Alastair D'Silva
  Cc: linuxppc-dev, linux-kernel, kernel-janitors
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>



Le 05/06/2018 à 11:16, Wei Yongjun a écrit :
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
> 
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
>   drivers/misc/ocxl/file.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index 33ae46c..e6a6074 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -139,8 +139,10 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
>   		// Locks both status & tidr
>   		mutex_lock(&ctx->status_mutex);
>   		if (!ctx->tidr) {
> -			if (set_thread_tidr(current))
> +			if (set_thread_tidr(current)) {
> +				mutex_unlock(&ctx->status_mutex);
>   				return -ENOENT;
> +			}

O_o   Thanks for fixing it

Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>


>   			ctx->tidr = current->thread.tidr;
>   		}
> 

^ permalink raw reply

* Re: [PATCH 09/10] dpaa_eth: add support for hardware timestamping
From: Richard Cochran @ 2018-06-05 13:57 UTC (permalink / raw)
  To: Y.b. Lu
  Cc: netdev@vger.kernel.org, Madalin-cristian Bucur, Rob Herring,
	Shawn Guo, David S . Miller, devicetree@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0401MB2536376432EC481473A5B4A3F8660@DB6PR0401MB2536.eurprd04.prod.outlook.com>

On Tue, Jun 05, 2018 at 03:35:28AM +0000, Y.b. Lu wrote:
> [Y.b. Lu] Actually these timestamping codes affected DPAA networking performance in our previous performance test.
> That's why we used ifdef for it.

How much does time stamping hurt performance?

If the time stamping is compiled in but not enabled at run time, does
it still affect performace?

Thanks,
Richard

^ permalink raw reply

* Re: Problems building ppc images in v4.14.y and v4.16.y using gcc 7.3.0 / 8.1.0 from kernel.org
From: Arnd Bergmann @ 2018-06-05 14:31 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: stable, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <e11832b0-f071-b709-be34-417f2d3bc343@roeck-us.net>

On Tue, Jun 5, 2018 at 3:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> Hi Arnd,
>
> when using the ppc64 compiler from kernel.org, I see the following problems
> when trying to compile ppc:allnoconfig in v4.14.y or v4.16.y.
>
> gcc 7.3.0: Compilation of kernel.cpu.o hangs
>
> The problem goes away if I apply the following two patches (tested with
> 4.16.y)
>
> 17a2f1ced028 cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states
> fcb3029a8d89 cpu/hotplug: Fix unused function warning

This is probably the same as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038

I thought I had included the fix in my builds.

> gcc 8.1.0: Compilation of kernel/cpu.o results in the following error
>
> powerpc64-linux-gcc: error: unrecognized command line option '-mno-spe'; did
> you mean '-fno-see'?
> powerpc64-linux-gcc: error: unrecognized command line option '-mspe=no'; did
> you mean '-misel=no'?
>
> This problem is also seen with mainline.

I've seen it, but couldn't figure out what the right fix is. I ended
up commenting
out those two lines in my private builds:

--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -215,8 +215,8 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx)

 # No SPE instruction when building kernel
 # (We use all available options to help semi-broken compilers)
-KBUILD_CFLAGS += $(call cc-option,-mno-spe)
-KBUILD_CFLAGS += $(call cc-option,-mspe=no)
+#KBUILD_CFLAGS += $(call cc-option,-mno-spe)
+#KBUILD_CFLAGS += $(call cc-option,-mspe=no)

 # Enable unit-at-a-time mode when possible. It shrinks the
 # kernel considerably.

I think there were some changes in how cc-option gets evaluated, maybe
those rely on something else to be enabled or disabled first?

        Arnd

^ permalink raw reply

* Re: powerpc: fix spelling mistake: "Usupported" -> "Unsupported"
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Colin King, Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
  Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180330155553.7170-1-colin.king@canonical.com>

On Fri, 2018-03-30 at 15:55:53 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> Trivial fix to spelling mistake in bootx_printf message text
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/e6536a9f94c00a5e1da0a869ccea07

cheers

^ permalink raw reply

* Re: powerpc/pkeys: Detach execute_only key on !PROT_EXEC
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Ram Pai
  Cc: dave.hansen, msuchanek, Ulrich.Weigand, linuxram, mhocko, paulus,
	aneesh.kumar, bauerman, Shakeel Butt, linuxppc-dev
In-Reply-To: <1525464111-1096-1-git-send-email-linuxram@us.ibm.com>

On Fri, 2018-05-04 at 20:01:51 UTC, Ram Pai wrote:
> Disassociate the exec_key from a VMA if the VMA permission is not
> PROT_EXEC anymore.  Otherwise the exec_only key continues to be
> associated with the vma, causing unexpected behavior.
> 
> The problem was reported on x86 by Shakeel Butt,
> which is also applicable on powerpc.
> 
> cc: Shakeel Butt <shakeelb@google.com>
> Reported-by: Shakeel Butt <shakeelb@google.com>
> Fixes 5586cf6 ("powerpc: introduce execute-only pkey")
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/eabdb8ca8690eedd461e61ea778059

cheers

^ permalink raw reply

* Re: powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Colin King, Benjamin Herrenschmidt, Paul Mackerras,
	Markus Elfring, linuxppc-dev
  Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180526151531.10920-1-colin.king@canonical.com>

On Sat, 2018-05-26 at 15:15:31 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> Trivial fix to spelling mistake in hmi_error_types text
> 
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Reviewed-by: Stewart Smith <stewart@linux.ibm.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/b0c4acb1dd7c653f78391661079af5

cheers

^ permalink raw reply

* Re: cpuidle:powernv: Make the snooze timeout dynamic.
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Gautham R. Shenoy, Rafael J. Wysocki, Daniel Lezcano,
	Stewart Smith, Michael Neuling, Vaidyanathan Srinivasan,
	Shilpasri G Bhat, Akshay Adiga, Nicholas Piggin
  Cc: Gautham R. Shenoy, linuxppc-dev, linux-kernel, linux-pm
In-Reply-To: <1527768909-32637-1-git-send-email-ego@linux.vnet.ibm.com>

On Thu, 2018-05-31 at 12:15:09 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
> 
> The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of
> snooze to deeper idle state") introduced a timeout for the snooze idle
> state so that it could be eventually be promoted to a deeper idle
> state. The snooze timeout value is static and set to the target
> residency of the next idle state, which would train the cpuidle
> governor to pick the next idle state eventually.
> 
> The unfortunate side-effect of this is that if the next idle state(s)
> is disabled, the CPU will forever remain in snooze, despite the fact
> that the system is completely idle, and other deeper idle states are
> available.
> 
> This patch fixes the issue by dynamically setting the snooze timeout
> to the target residency of the next enabled state on the device.
> 
> Before Patch
> Reviewed-by: Balbir Singh <bsingharora@gmail.com>
> 
> ==================
> POWER8 : Only nap disabled.
>  $cpupower monitor sleep 30
> sleep took 30.01297 seconds and exited with status 0
>               |Idle_Stats
> PKG |CORE|CPU | snoo | Nap  | Fast
>    0|   8|   0| 96.41|  0.00|  0.00
>    0|   8|   1| 96.43|  0.00|  0.00
>    0|   8|   2| 96.47|  0.00|  0.00
>    0|   8|   3| 96.35|  0.00|  0.00
>    0|   8|   4| 96.37|  0.00|  0.00
>    0|   8|   5| 96.37|  0.00|  0.00
>    0|   8|   6| 96.47|  0.00|  0.00
>    0|   8|   7| 96.47|  0.00|  0.00
> 
> POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
> stop2) disabled:
> $cpupower monitor sleep 30
> sleep took 30.05033 seconds and exited with status 0
>               |Idle_Stats
> PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
>    0|  16|   0| 89.79|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
>    0|  16|   1| 90.12|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
>    0|  16|   2| 90.21|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
>    0|  16|   3| 90.29|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00
> 
> After Patch
> ======================
> POWER8 : Only nap disabled.
> $ cpupower monitor sleep 30
> sleep took 30.01200 seconds and exited with status 0
>               |Idle_Stats
> PKG |CORE|CPU | snoo | Nap  | Fast
>    0|   8|   0| 16.58|  0.00| 77.21
>    0|   8|   1| 18.42|  0.00| 75.38
>    0|   8|   2|  4.70|  0.00| 94.09
>    0|   8|   3| 17.06|  0.00| 81.73
>    0|   8|   4|  3.06|  0.00| 95.73
>    0|   8|   5|  7.00|  0.00| 96.80
>    0|   8|   6|  1.00|  0.00| 98.79
>    0|   8|   7|  5.62|  0.00| 94.17
> 
> POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1,
> stop2) disabled:
> 
> $cpupower monitor sleep 30
> sleep took 30.02110 seconds and exited with status 0
>               |Idle_Stats
> PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop
>    0|   0|   0|  0.69|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  9.39| 89.70
>    0|   0|   1|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.05| 93.21
>    0|   0|   2|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00| 89.93
>    0|   0|   3|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00|  0.00| 93.26
> 
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/0a4ec6aa035a52c422eceb2ed51ed8

cheers

^ permalink raw reply

* Re: powerpc/powernv: copy/paste - Mask SO bit in CR
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180604083338.2661-1-mpe@ellerman.id.au>

On Mon, 2018-06-04 at 08:33:38 UTC, Michael Ellerman wrote:
> NX can set the 3rd bit in CR register for XER[SO] (Summary overflow)
> which is not related to paste request. The current paste function
> returns failure for a successful request when this bit is set. So mask
> this bit and check the proper return status.
> 
> Fixes: 2392c8c8c045 ("powerpc/powernv/vas: Define copy/paste interfaces")
> Cc: stable@vger.kernel.org # v4.14+
> Signed-off-by: Haren Myneni <haren@us.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Applied to powerpc next.

https://git.kernel.org/powerpc/c/75743649064ec0cf5ddd69f240ef23

cheers

^ permalink raw reply

* Re: powerpc: fix build failure by disabling attribute-alias warning in pci_32
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
  Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fa51770430e00ac2db1c621365473a0c893d105e.1528179842.git.christophe.leroy@c-s.fr>

On Tue, 2018-06-05 at 06:57:43 UTC, Christophe Leroy wrote:
> Commit 2479bfc9bc600 ("powerpc: Fix build by disabling attribute-alias
> warning for SYSCALL_DEFINEx") forgot arch/powerpc/kernel/pci_32.c
> 
> Latest GCC version emit the following warnings
> 
> As arch/powerpc code is built with -Werror, this breaks build with
> GCC 8.1
> 
> This patch inhibits this warning
> 
> In file included from arch/powerpc/kernel/pci_32.c:14:
> ./include/linux/syscalls.h:233:18: error: 'sys_pciconfig_iobase' alias between functions of incompatible types 'long int(long int,  long unsigned int,  long unsigned int)' and 'long int(long int,  long int,  long int)' [-Werror=attribute-alias]
>   asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
>                   ^~~
> ./include/linux/syscalls.h:222:2: note: in expansion of macro '__SYSCALL_DEFINEx'
>   __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>   ^~~~~~~~~~~~~~~~~
> 
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/415520373975d2eba565c256d2cad8

cheers

^ permalink raw reply

* Re: [-next] ocxl: Fix missing unlock on error in afu_ioctl_enable_p9_wait()
From: Michael Ellerman @ 2018-06-05 15:19 UTC (permalink / raw)
  To: Wei Yongjun, Frederic Barrat, Andrew Donnellan, Arnd Bergmann,
	Greg Kroah-Hartman, Alastair D'Silva
  Cc: linuxppc-dev, kernel-janitors, Wei Yongjun, linux-kernel
In-Reply-To: <1528190181-15745-1-git-send-email-weiyongjun1@huawei.com>

On Tue, 2018-06-05 at 09:16:21 UTC, Wei Yongjun wrote:
> Add the missing unlock before return from function
> afu_ioctl_enable_p9_wait() in the error handling case.
> 
> Fixes: e948e06fc63a ("ocxl: Expose the thread_id needed for wait on POWER9")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Reviewed-by: Alastair D'Silva <alastair@d-silva.org>

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/2e5c93d6bb2f7bc17eb82748943a1b

cheers

^ permalink raw reply

* Re: Problems building ppc images in v4.14.y and v4.16.y using gcc 7.3.0 / 8.1.0 from kernel.org
From: Guenter Roeck @ 2018-06-05 16:06 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: stable, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <CAK8P3a3CFhkjPCX8bgZbx7aYwrUVsKE5ct4ghnMxJLo5OSYqbA@mail.gmail.com>

On Tue, Jun 05, 2018 at 04:31:00PM +0200, Arnd Bergmann wrote:
> On Tue, Jun 5, 2018 at 3:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > Hi Arnd,
> >
> > when using the ppc64 compiler from kernel.org, I see the following problems
> > when trying to compile ppc:allnoconfig in v4.14.y or v4.16.y.
> >
> > gcc 7.3.0: Compilation of kernel.cpu.o hangs
> >
> > The problem goes away if I apply the following two patches (tested with
> > 4.16.y)
> >
> > 17a2f1ced028 cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states
> > fcb3029a8d89 cpu/hotplug: Fix unused function warning
> 
> This is probably the same as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038
> 
> I thought I had included the fix in my builds.
> 
Guess not.

> > gcc 8.1.0: Compilation of kernel/cpu.o results in the following error
> >
> > powerpc64-linux-gcc: error: unrecognized command line option '-mno-spe'; did
> > you mean '-fno-see'?
> > powerpc64-linux-gcc: error: unrecognized command line option '-mspe=no'; did
> > you mean '-misel=no'?
> >
> > This problem is also seen with mainline.
> 
> I've seen it, but couldn't figure out what the right fix is. I ended
> up commenting
> out those two lines in my private builds:
> 
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -215,8 +215,8 @@ KBUILD_CFLAGS += $(call cc-option,-mno-vsx)
> 
>  # No SPE instruction when building kernel
>  # (We use all available options to help semi-broken compilers)
> -KBUILD_CFLAGS += $(call cc-option,-mno-spe)
> -KBUILD_CFLAGS += $(call cc-option,-mspe=no)
> +#KBUILD_CFLAGS += $(call cc-option,-mno-spe)
> +#KBUILD_CFLAGS += $(call cc-option,-mspe=no)
> 
>  # Enable unit-at-a-time mode when possible. It shrinks the
>  # kernel considerably.
> 
> I think there were some changes in how cc-option gets evaluated, maybe
> those rely on something else to be enabled or disabled first?
> 
I think it may have cached the flags from the other compiler version.
"make mrproper" prior to "make defconfig" took care of the issue.

However, that doesn't really help - I get lots of
	error: 'sys_spu_create' alias between functions of incompatible types
	error: 'strncpy' output truncated before terminating nul
if I try to use gcc 8.1.0.

Oh well. I'll try gcc 6.4.0 next.

Thanks,
Guenter

^ permalink raw reply

* Re: Problems building ppc images in v4.14.y and v4.16.y using gcc 7.3.0 / 8.1.0 from kernel.org
From: Arnd Bergmann @ 2018-06-05 19:47 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: stable, Greg Kroah-Hartman, linuxppc-dev
In-Reply-To: <20180605160624.GA30373@roeck-us.net>

On Tue, Jun 5, 2018 at 6:06 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Tue, Jun 05, 2018 at 04:31:00PM +0200, Arnd Bergmann wrote:
>> On Tue, Jun 5, 2018 at 3:52 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> > Hi Arnd,
>> >
>> > when using the ppc64 compiler from kernel.org, I see the following problems
>> > when trying to compile ppc:allnoconfig in v4.14.y or v4.16.y.
>> >
>> > gcc 7.3.0: Compilation of kernel.cpu.o hangs
>> >
>> > The problem goes away if I apply the following two patches (tested with
>> > 4.16.y)
>> >
>> > 17a2f1ced028 cpu/hotplug: Merge cpuhp_bp_states and cpuhp_ap_states
>> > fcb3029a8d89 cpu/hotplug: Fix unused function warning
>>
>> This is probably the same as
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84038
>>
>> I thought I had included the fix in my builds.
>>
> Guess not.

I probably had it in one build and then forgot about it when I did a
rebuild of 7.3 :(

I'm still planning to do a new set of gcc-7.3 binaries (or maybe 7.4
if that gets
released soon) and should try to remember doing that.

>>
> I think it may have cached the flags from the other compiler version.
> "make mrproper" prior to "make defconfig" took care of the issue.
>
> However, that doesn't really help - I get lots of
>         error: 'sys_spu_create' alias between functions of incompatible types
>         error: 'strncpy' output truncated before terminating nul
> if I try to use gcc 8.1.0.
>
> Oh well. I'll try gcc 6.4.0 next.

On the upside, those two errors are just a result of arch/power/*/*.c getting
built with -Werror, they are warnings that gcc-8 introduced that we should
either shut up or fix.

        Arnd

^ permalink raw reply

* Re: [PATCH QEMU] osdep: powerpc64 align memory to allow 2MB radix THP page tables
From: David Gibson @ 2018-06-06  1:06 UTC (permalink / raw)
  To: Nicholas Piggin; +Cc: qemu-ppc, Alexander Graf, kvm-ppc, linuxppc-dev
In-Reply-To: <20180506072949.12783-1-npiggin@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

On Sun, May 06, 2018 at 05:29:49PM +1000, Nicholas Piggin wrote:
> This allows KVM with the Book3S radix MMU mode to take advantage of
> THP and install larger pages in the partition scope page tables (the
> host translation).
> 
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>

I've applied this to my ppc-for-3.0 tree.  It's not strictly within
the code I maintain, but since it only affects ppc, it seems
reasonable to go through my tree.

> ---
>  include/qemu/osdep.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index 41658060a7..5910682221 100644
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -357,7 +357,8 @@ void qemu_anon_ram_free(void *ptr, size_t size);
>  #endif
>  
>  #if defined(__linux__) && \
> -    (defined(__x86_64__) || defined(__arm__) || defined(__aarch64__))
> +    (defined(__x86_64__) || defined(__arm__) || defined(__aarch64__) \
> +     || defined(__powerpc64__))
>     /* Use 2 MiB alignment so transparent hugepages can be used by KVM.
>        Valgrind does not support alignments larger than 1 MiB,
>        therefore we need special code which handles running on Valgrind. */

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply

* [PATCH] powerpc/64s/radix: Fix missing ptesync in flush_cache_vmap
From: Nicholas Piggin @ 2018-06-06  1:40 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Nicholas Piggin

There is a typo in f1cb8f9beb ("powerpc/64s/radix: avoid ptesync after
set_pte and ptep_set_access_flags") config ifdef, which results in the
necessary ptesync not being issued after vmalloc.

This causes random kernel faults in module load, bpf load, anywhere
that vmalloc mappings are used.

After correcting the code, this survives a guest kernel booting
hundreds of times where previously there would be a crash every few
boots (I haven't noticed the crash on host, perhaps due to different
TLB and page table walking behaviour in hardware).

A memory clobber is also added to the flush, just to be sure it won't
be reordered with the pte set or the subsequent mapping access.

Fixes: f1cb8f9beb ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
This code obviously can't have been tested properly, I'm sorry about
that. I tested with the ptesync and then "tidied up" the patch by
putting it in ifdef, and didn't test the final patch sufficiently :(

 arch/powerpc/include/asm/cacheflush.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
index e9662648e72d..0d72ec75da63 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -23,10 +23,9 @@
 #define flush_cache_range(vma, start, end)	do { } while (0)
 #define flush_cache_page(vma, vmaddr, pfn)	do { } while (0)
 #define flush_icache_page(vma, page)		do { } while (0)
-#define flush_cache_vmap(start, end)		do { } while (0)
 #define flush_cache_vunmap(start, end)		do { } while (0)
 
-#ifdef CONFIG_BOOK3S_64
+#ifdef CONFIG_PPC_BOOK3S_64
 /*
  * Book3s has no ptesync after setting a pte, so without this ptesync it's
  * possible for a kernel virtual mapping access to return a spurious fault
@@ -34,7 +33,7 @@
  * not expect this type of fault. flush_cache_vmap is not exactly the right
  * place to put this, but it seems to work well enough.
  */
-#define flush_cache_vmap(start, end)		do { asm volatile("ptesync"); } while (0)
+#define flush_cache_vmap(start, end)		do { asm volatile("ptesync" ::: "memory"); } while (0)
 #else
 #define flush_cache_vmap(start, end)		do { } while (0)
 #endif
-- 
2.17.0

^ permalink raw reply related

* [PATCH V2] crypto/nx: Initialize 842 high and normal RxFIFO control registers
From: Haren Myneni @ 2018-06-06  4:15 UTC (permalink / raw)
  To: mpe; +Cc: herbert, stewart, linuxppc-dev, linux-crypto


NX increments readOffset by FIFO size in receive FIFO control register
when CRB is read. But the index in RxFIFO has to match with the
corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
may be processing incorrect CRBs and can cause CRB timeout.

VAS FIFO offset is 0 when the receive window is opened during
initialization. When the module is reloaded or in kexec boot, readOffset
in FIFO control register may not match with VAS entry. This patch adds
nx_coproc_init OPAL call to reset readOffset and queued entries in FIFO
control register for both high and normal FIFOs.

Signed-off-by: Haren Myneni <haren@us.ibm.com>
---
Changlog:
V2: Execute nx_coproc_init OPAL call per NX without depending on
    FIFO priority [Stewart Smith]

diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
index d886a5b..ff61e4b 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -206,7 +206,8 @@
 #define OPAL_NPU_TL_SET				161
 #define OPAL_PCI_GET_PBCQ_TUNNEL_BAR		164
 #define OPAL_PCI_SET_PBCQ_TUNNEL_BAR		165
-#define OPAL_LAST				165
+#define	OPAL_NX_COPROC_INIT			167
+#define OPAL_LAST				167
 
 /* Device tree flags */
 
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7159e1a..d79eb82 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -288,6 +288,7 @@ int64_t opal_imc_counters_init(uint32_t type, uint64_t address,
 int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
 int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
 int opal_sensor_group_clear(u32 group_hndl, int token);
+int opal_nx_coproc_init(uint32_t chip_id, uint32_t ct);
 
 s64 opal_signal_system_reset(s32 cpu);
 
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 3da30c2..c7541a9 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -325,3 +325,4 @@ OPAL_CALL(opal_npu_spa_clear_cache,		OPAL_NPU_SPA_CLEAR_CACHE);
 OPAL_CALL(opal_npu_tl_set,			OPAL_NPU_TL_SET);
 OPAL_CALL(opal_pci_get_pbcq_tunnel_bar,		OPAL_PCI_GET_PBCQ_TUNNEL_BAR);
 OPAL_CALL(opal_pci_set_pbcq_tunnel_bar,		OPAL_PCI_SET_PBCQ_TUNNEL_BAR);
+OPAL_CALL(opal_nx_coproc_init,			OPAL_NX_COPROC_INIT);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 48fbb41..5e13908 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -1035,3 +1035,5 @@ void powernv_set_nmmu_ptcr(unsigned long ptcr)
 EXPORT_SYMBOL_GPL(opal_int_set_mfrr);
 EXPORT_SYMBOL_GPL(opal_int_eoi);
 EXPORT_SYMBOL_GPL(opal_error_code);
+/* Export the below symbol for NX compression */
+EXPORT_SYMBOL(opal_nx_coproc_init);
diff --git a/drivers/crypto/nx/nx-842-powernv.c b/drivers/crypto/nx/nx-842-powernv.c
index 1e87637..435396b 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -24,6 +24,8 @@
 #include <asm/icswx.h>
 #include <asm/vas.h>
 #include <asm/reg.h>
+#include <asm/opal-api.h>
+#include <asm/opal.h>
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Dan Streetman <ddstreet@ieee.org>");
@@ -753,7 +755,7 @@ static int nx842_open_percpu_txwins(void)
 }
 
 static int __init vas_cfg_coproc_info(struct device_node *dn, int chip_id,
-					int vasid)
+					int vasid, int *ct)
 {
 	struct vas_window *rxwin = NULL;
 	struct vas_rx_win_attr rxattr;
@@ -837,6 +839,15 @@ static int __init vas_cfg_coproc_info(struct device_node *dn, int chip_id,
 	coproc->vas.id = vasid;
 	nx842_add_coprocs_list(coproc, chip_id);
 
+	/*
+	 * (lpid, pid, tid) combination has to be unique for each
+	 * coprocessor instance in the system. So to make it
+	 * unique, skiboot uses coprocessor type such as 842 or
+	 * GZIP for pid and provides this value to kernel in pid
+	 * device-tree property.
+	 */
+	*ct = pid;
+
 	return 0;
 
 err_out:
@@ -848,7 +859,7 @@ static int __init vas_cfg_coproc_info(struct device_node *dn, int chip_id,
 static int __init nx842_powernv_probe_vas(struct device_node *pn)
 {
 	struct device_node *dn;
-	int chip_id, vasid, ret = 0;
+	int chip_id, vasid, ct, ret = 0;
 	int nx_fifo_found = 0;
 
 	chip_id = of_get_ibm_chip_id(pn);
@@ -865,7 +876,7 @@ static int __init nx842_powernv_probe_vas(struct device_node *pn)
 
 	for_each_child_of_node(pn, dn) {
 		if (of_device_is_compatible(dn, "ibm,p9-nx-842")) {
-			ret = vas_cfg_coproc_info(dn, chip_id, vasid);
+			ret = vas_cfg_coproc_info(dn, chip_id, vasid, &ct);
 			if (ret) {
 				of_node_put(dn);
 				return ret;
@@ -879,6 +890,16 @@ static int __init nx842_powernv_probe_vas(struct device_node *pn)
 		ret = -EINVAL;
 	}
 
+	/*
+	 * Initialize each NX instance for both high and normal
+	 * priority FIFOs.
+	 */
+	ret = opal_nx_coproc_init(chip_id, ct);
+	if (ret) {
+		pr_err("Failed to initialize NX coproc: %d\n", ret);
+		ret = opal_error_code(ret);
+	}
+
 	return ret;
 }
 

^ permalink raw reply related

* [RFC PATCH 0/4] powerpc/pseries: Machien check handler improvements.
From: Mahesh J Salgaonkar @ 2018-06-06  4:36 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Michael Ellerman, Aneesh Kumar K.V, Aneesh Kumar K.V,
	Michael Ellerman, Laurent Dufour

This patch series includes some improvement to Machine check handler
for pseries. Patch 1 fixes an issue where machine check handler crashes
kernel while accessing vmalloc-ed buffer while in nmi context.
Patch 3 dumps the SLB contents on SLB MCE errors to improve the debugability.
Patch 4 display's the MCE error details on console.

---

Mahesh Salgaonkar (4):
      powerpc/pseries: convert rtas_log_buf to linear allocation.
      powerpc/pseries: Define MCE error event section.
      powerpc/pseries: Dump and flush SLB contents on SLB MCE errors.
      powerpc/pseries: Display machine check error details.


 arch/powerpc/include/asm/book3s/64/mmu-hash.h |    1 
 arch/powerpc/include/asm/rtas.h               |  109 +++++++++++++++++++
 arch/powerpc/kernel/rtasd.c                   |    2 
 arch/powerpc/mm/slb.c                         |   35 ++++++
 arch/powerpc/platforms/pseries/ras.c          |  145 +++++++++++++++++++++++++
 5 files changed, 290 insertions(+), 2 deletions(-)

--
Signature

^ permalink raw reply

* [RFC PATCH 1/4] powerpc/pseries: convert rtas_log_buf to linear allocation.
From: Mahesh J Salgaonkar @ 2018-06-06  4:36 UTC (permalink / raw)
  To: linuxppc-dev
  Cc: Aneesh Kumar K.V, Aneesh Kumar K.V, Michael Ellerman,
	Laurent Dufour
In-Reply-To: <152825972491.24560.4626614298142965406.stgit@jupiter.in.ibm.com>

From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>

rtas_log_buf is a buffer to hold RTAS event data that are communicated
to kernel by hypervisor. This buffer is then used to pass RTAS event
data to user through proc fs. This buffer is allocated from vmalloc
(non-linear mapping) area.

On Machine check interrupt, register r3 points to RTAS extended event
log passed by hypervisor that contains the MCE event. The pseries
machine check handler then logs this error into rtas_log_buf. The
rtas_log_buf is a vmalloc-ed (non-linear) buffer we end up taking up a
page fault (vector 0x300) while accessing it. Since machine check
interrupt handler runs in NMI context we can not afford to take any
page fault. Page faults are not honored in NMI context and causes
kernel panic. This patch fixes this issue by allocating rtas_log_buf
using kmalloc.

Suggested-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
 arch/powerpc/kernel/rtasd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtasd.c b/arch/powerpc/kernel/rtasd.c
index f915db93cd42..3957d4ae2ba2 100644
--- a/arch/powerpc/kernel/rtasd.c
+++ b/arch/powerpc/kernel/rtasd.c
@@ -559,7 +559,7 @@ static int __init rtas_event_scan_init(void)
 	rtas_error_log_max = rtas_get_error_log_max();
 	rtas_error_log_buffer_max = rtas_error_log_max + sizeof(int);
 
-	rtas_log_buf = vmalloc(rtas_error_log_buffer_max*LOG_NUMBER);
+	rtas_log_buf = kmalloc(rtas_error_log_buffer_max*LOG_NUMBER, GFP_KERNEL);
 	if (!rtas_log_buf) {
 		printk(KERN_ERR "rtasd: no memory\n");
 		return -ENOMEM;

^ permalink raw reply related

* [RFC PATCH 2/4] powerpc/pseries: Define MCE error event section.
From: Mahesh J Salgaonkar @ 2018-06-06  4:37 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Aneesh Kumar K.V, Michael Ellerman, Laurent Dufour
In-Reply-To: <152825972491.24560.4626614298142965406.stgit@jupiter.in.ibm.com>

From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>

On pseries, the machine check error details are part of RTAS extended
event log passed under Machine check exception section. This patch adds
the definition of rtas MCE event section and related helper
functions.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/rtas.h |  104 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index ec9dd79398ee..3f2fba7ef23b 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -275,6 +275,7 @@ inline uint32_t rtas_ext_event_company_id(struct rtas_ext_event_log_v6 *ext_log)
 #define PSERIES_ELOG_SECT_ID_CALL_HOME		(('C' << 8) | 'H')
 #define PSERIES_ELOG_SECT_ID_USER_DEF		(('U' << 8) | 'D')
 #define PSERIES_ELOG_SECT_ID_HOTPLUG		(('H' << 8) | 'P')
+#define PSERIES_ELOG_SECT_ID_MCE		(('M' << 8) | 'C')
 
 /* Vendor specific Platform Event Log Format, Version 6, section header */
 struct pseries_errorlog {
@@ -326,6 +327,109 @@ struct pseries_hp_errorlog {
 #define PSERIES_HP_ELOG_ID_DRC_COUNT	3
 #define PSERIES_HP_ELOG_ID_DRC_IC	4
 
+/* RTAS pseries MCE errorlog section */
+#pragma pack(push, 1)
+struct pseries_mc_errorlog {
+	__be32	fru_id;
+	__be32	proc_id;
+	uint8_t	error_type;
+	union {
+		struct {
+			uint8_t	ue_err_type;
+			/* XXXXXXXX
+			 * X		1: Permanent or Transient UE.
+			 *  X		1: Effective address provided.
+			 *   X		1: Logical address provided.
+			 *    XX	2: Reserved.
+			 *      XXX	3: Type of UE error.
+			 */
+			uint8_t	reserved_1[6];
+			__be64	effective_address;
+			__be64	logical_address;
+		} ue_error;
+		struct {
+			uint8_t	soft_err_type;
+			/* XXXXXXXX
+			 * X		1: Effective address provided.
+			 *  XXXXX	5: Reserved.
+			 *       XX	2: Type of SLB/ERAT/TLB error.
+			 */
+			uint8_t	reserved_1[6];
+			__be64	effective_address;
+			uint8_t	reserved_2[8];
+		} soft_error;
+	} u;
+};
+#pragma pack(pop)
+
+/* RTAS pseries MCE error types */
+#define PSERIES_MC_ERROR_TYPE_UE		0x00
+#define PSERIES_MC_ERROR_TYPE_SLB		0x01
+#define PSERIES_MC_ERROR_TYPE_ERAT		0x02
+#define PSERIES_MC_ERROR_TYPE_TLB		0x04
+#define PSERIES_MC_ERROR_TYPE_D_CACHE		0x05
+#define PSERIES_MC_ERROR_TYPE_I_CACHE		0x07
+
+/* RTAS pseries MCE error sub types */
+#define PSERIES_MC_ERROR_UE_INDETERMINATE		0
+#define PSERIES_MC_ERROR_UE_IFETCH			1
+#define PSERIES_MC_ERROR_UE_PAGE_TABLE_WALK_IFETCH	2
+#define PSERIES_MC_ERROR_UE_LOAD_STORE			3
+#define PSERIES_MC_ERROR_UE_PAGE_TABLE_WALK_LOAD_STORE	4
+
+#define PSERIES_MC_ERROR_SLB_PARITY		0
+#define PSERIES_MC_ERROR_SLB_MULTIHIT		1
+#define PSERIES_MC_ERROR_SLB_INDETERMINATE	2
+
+#define PSERIES_MC_ERROR_ERAT_PARITY		1
+#define PSERIES_MC_ERROR_ERAT_MULTIHIT		2
+#define PSERIES_MC_ERROR_ERAT_INDETERMINATE	3
+
+#define PSERIES_MC_ERROR_TLB_PARITY		1
+#define PSERIES_MC_ERROR_TLB_MULTIHIT		2
+#define PSERIES_MC_ERROR_TLB_INDETERMINATE	3
+
+static inline uint8_t rtas_mc_error_type(const struct pseries_mc_errorlog *mlog)
+{
+	return mlog->error_type;
+}
+
+static inline uint8_t rtas_mc_error_sub_type(
+					const struct pseries_mc_errorlog *mlog)
+{
+	switch (mlog->error_type) {
+	case	PSERIES_MC_ERROR_TYPE_UE:
+		return (mlog->u.ue_error.ue_err_type & 0x07);
+	case	PSERIES_MC_ERROR_TYPE_SLB:
+	case	PSERIES_MC_ERROR_TYPE_ERAT:
+	case	PSERIES_MC_ERROR_TYPE_TLB:
+		return (mlog->u.soft_error.soft_err_type & 0x03);
+	default:
+		return 0;
+	}
+}
+
+static inline uint64_t rtas_mc_get_effective_addr(
+					const struct pseries_mc_errorlog *mlog)
+{
+	uint64_t addr = 0;
+
+	switch (mlog->error_type) {
+	case	PSERIES_MC_ERROR_TYPE_UE:
+		if (mlog->u.ue_error.ue_err_type & 0x40)
+			addr = mlog->u.ue_error.effective_address;
+		break;
+	case	PSERIES_MC_ERROR_TYPE_SLB:
+	case	PSERIES_MC_ERROR_TYPE_ERAT:
+	case	PSERIES_MC_ERROR_TYPE_TLB:
+		if (mlog->u.soft_error.soft_err_type & 0x80)
+			addr = mlog->u.soft_error.effective_address;
+	default:
+		break;
+	}
+	return be64_to_cpu(addr);
+}
+
 struct pseries_errorlog *get_pseries_errorlog(struct rtas_error_log *log,
 					      uint16_t section_id);
 

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox