[PATCH 3/3] powerpc/lib/sstep: Fix fixed-point shift instructions that set CA32

This fixes the emulated behaviour of existing fixed-point shift right algebraic instructions that are supposed to set both the CA and CA32 bits of XER when running on a system that is compliant with POWER ISA v3.0 independent of whether the system is executing in 32-bit mode or 64-bit mode. The

[PATCH 2/3] powerpc/lib/sstep: Fix fixed-point arithmetic instructions that set CA32

There are existing fixed-point arithmetic instructions that always set the CA bit of XER to reflect the carry out of bit 0 in 64-bit mode and out of bit 32 in 32-bit mode. In ISA v3.0, these instructions also always set the CA32 bit of XER to reflect the carry out of bit 32. This fixes the

[PATCH 1/3] powerpc/lib/sstep: Add XER bits introduced in POWER ISA v3.0

This adds definitions for the OV32 and CA32 bits of XER that were introduced in POWER ISA v3.0. There are some existing instructions that currently set the OV and CA bits based on certain conditions. The emulation behaviour of all these instructions needs to be updated to set these new bits

Re: [PATCH] powerpc/powernv: Make opal_event_shutdown() callable from IRQ context

On Fri, 29 Sep 2017 13:58:02 +1000 Michael Ellerman wrote: > In opal_event_shutdown() we free all the IRQs hanging off the > opal_event_irqchip. However it's not safe to do so if we're called > from IRQ context, because free_irq() wants to synchronise versus IRQ > context.

[PATCH v4 5/5] powerpc/mce: hookup memory_failure for UE errors

If we are in user space and hit a UE error, we now have the basic infrastructure to walk the page tables and find out the effective address that was accessed, since the DAR is not valid. We use a work_queue content to hookup the bad pfn, any other context causes problems, since memory_failure

[PATCH v4 4/5] powerpc/mce: Hookup ierror (instruction) UE errors

Hookup instruction errors (UE) for memory offling via memory_failure() in a manner similar to load/store errors (derror). Since we have access to the NIP, the conversion is a one step process in this case. Signed-off-by: Balbir Singh Reviewed-by: Nicholas Piggin

[PATCH v4 3/5] powerpc/mce: Hookup derror (load/store) UE errors

Extract physical_address for UE errors by walking the page tables for the mm and address at the NIP, to extract the instruction. Then use the instruction to find the effective address via analyse_instr(). We might have page table walking races, but we expect them to be rare, the physical address

[PATCH v4 2/5] powerpc/mce: align the print of physical address better

Use the same alignment as Effective address and rename phyiscal address to Page Frame Number Signed-off-by: Balbir Singh Reviewed-by: Nicholas Piggin --- arch/powerpc/kernel/mce.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v4 1/5] powerpc/mce.c: Remove unused function get_mce_fault_addr()

There are no users of get_mce_fault_addr() Fixes: b63a0ff ("powerpc/powernv: Machine check exception handling.") Signed-off-by: Balbir Singh Reviewed-by: Nicholas Piggin --- arch/powerpc/include/asm/mce.h | 2 -- arch/powerpc/kernel/mce.c | 39

[PATCH v4 0/5] Revisit MCE handling for UE Errors

This patch series is designed to hook up memory_failure on UE errors, this is specially helpful for user_mode UE errors. The first two patches cleanup bits, remove dead code. I could not find any users of get_mce_fault_addr(). The second one improves printing of physical address The third patch

[PATCH] powerpc/powernv: Make opal_event_shutdown() callable from IRQ context

In opal_event_shutdown() we free all the IRQs hanging off the opal_event_irqchip. However it's not safe to do so if we're called from IRQ context, because free_irq() wants to synchronise versus IRQ context. This can lead to warnings and a stuck system. For example from sysrq-b: Trying to free

[PATCH] powerpc: Fix workaround for spurious MCE on POWER9

In the recent commit: d8bd9f3f09 powerpc: Handle MCE on POWER9 with only DSISR bit 30 set I screwed up the bit. It should be bit 25 (IBM bit 38). Signed-off-by: Michael Neuling --- arch/powerpc/kernel/mce_power.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v2 6/6] powerpc/powernv: implement NMI IPI with OPAL_SIGNAL_SYSTEM_RESET

This allows MSR[EE]=0 lockups to be detected on an OPAL (bare metal) system similarly to the hcall NMI IPI on pseries guests, when the platform/firmware supports it. This is an example of CPU10 spinning with interrupts hard disabled: Watchdog CPU:32 detected Hard LOCKUP other CPUS:10 Watchdog

[PATCH v2 5/6] powerpc/64s: Implement system reset idle wakeup reason

It is possible to wake from idle due to a system reset exception, in which case the CPU takes a system reset interrupt to wake from idle, with system reset as the wakeup reason. The regular (not idle wakeup) system reset interrupt handler must be invoked in this case, otherwise the system reset

[PATCH v2 4/6] powerpc/xmon: avoid tripping SMP hardlockup watchdog

The SMP hardlockup watchdog cross-checks other CPUs for lockups, which causes xmon headaches because it's assuming interrupts hard disabled means no watchdog troubles. Try to improve that by calling touch_nmi_watchdog() in obvious places where secondaries are spinning. Also annotate these spin

[PATCH v2 3/6] powerpc/watchdog: do not trigger SMP crash from touch_nmi_watchdog

In xmon, touch_nmi_watchdog() is not expected to be checking that other CPUs have not touched the watchdog, so the code will just call touch_nmi_watchdog() once before re-enabling hard interrupts. Just update our CPU's state, and ignore apparently stuck SMP threads. Arguably touch_nmi_watchdog

[PATCH v2 2/6] powerpc/watchdog: do not backtrace locked CPUs twice if allcpus backtrace is enabled

If sysctl_hardlockup_all_cpu_backtrace is enabled, there is no need to IPI stuck CPUs for backtrace before trigger_allbutself_cpu_backtrace(), which does the same thing again. Signed-off-by: Nicholas Piggin --- arch/powerpc/kernel/watchdog.c | 19 +++ 1 file

[PATCH v2 1/6] powerpc/watchdog: do not panic from locked CPU's IPI handler

The SMP watchdog will detect locked CPUs and IPI them to print a backtrace and registers. If panic on hard lockup is enabled, do not panic from this handler, because that can cause recursion into the IPI layer during the panic. The caller already panics in this case. Signed-off-by: Nicholas

[PATCH v2 0/6] More NMI IPI enablement work

Since last post, the first 4 patches are unchanged. Split the last patch into 2, tidied up a few things, and removed the DD1 workarounds because firmware is not going to support DD1. Then re-tested with upstream firmware which has now merged support for OPAL_SIGNAL_SYSTEM_RESET on POWER9 DD2.

Re: [PATCH kernel v3] vfio/spapr: Add cond_resched() for huge updates

On Thu, Sep 28, 2017 at 07:16:12PM +1000, Alexey Kardashevskiy wrote: > Clearing very big IOMMU tables can trigger soft lockups. This adds > cond_resched() to allow the scheduler to do context switching when > it decides to. > > Signed-off-by: Alexey Kardashevskiy Reviewed-by:

[PATCH] powerpc/vio: dispose of virq mapping on vdevice unregister

When a vdevice is DLPAR removed from the system the vio subsystem doesn't bother unmapping the virq from the irq_domain. As a result we have a virq mapped to a hardware irq that is no longer valid for the irq_domain. A side effect is that we are left with /proc/irq/ affinity entries, and

Re: [PATCH v3 00/20] Speculative page faults

On Thu, 28 Sep 2017 14:29:02 +0200 Laurent Dufour wrote: > > Laurent's [0/n] provides some nice-looking performance benefits for > > workloads which are chosen to show performance benefits(!) but, alas, > > no quantitative testing results for workloads which we may

[RFC PATCH for 4.14] membarrier powerpc: Move hook to switch_mm()

Nick has a valid point that the sched_in() hook is a fast-path compared to switch_mm(). Adding an extra TIF test in a fast-path to save a barrier in a comparatively slow-path is therefore not such a good idea overall. Therefore, move the architecture hook to switch_mm() instead. [ This patch is

[PATCH v2] powerpc: fix compile error on 64K pages on 40x, 44x

The mmu context on the 40x, 44x does not define pte_frag entry. This causes gcc abort the compilation due to: setup-common.c: In function ‘setup_arch’: setup-common.c:908: error: ‘mm_context_t’ has no ‘pte_frag’ This patch fixes the issue by adding additional guard conditions, that limit the

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

- On Sep 28, 2017, at 12:16 PM, Nicholas Piggin npig...@gmail.com wrote: > On Thu, 28 Sep 2017 15:29:50 + (UTC) > Mathieu Desnoyers wrote: > >> - On Sep 28, 2017, at 11:01 AM, Nicholas Piggin npig...@gmail.com wrote: >> >> > On Thu, 28 Sep 2017

Re: [EXTERNAL]Re: FSL serial 166550 errata broken?

On Thu, 2017-09-28 at 17:54 +0200, Joakim Tjernlund wrote: > On Wed, 2017-09-27 at 15:32 +, York Sun wrote: > > On 09/27/2017 04:03 AM, Joakim Tjernlund wrote: > > > On Mon, 2017-09-25 at 17:26 +, York Sun wrote: > > > > On 09/25/2017 09:55 AM, Joakim Tjernlund wrote: > > > > > We got some

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Thu, 28 Sep 2017 17:51:15 +0200 Peter Zijlstra wrote: > On Fri, Sep 29, 2017 at 01:01:12AM +1000, Nicholas Piggin wrote: > > That's fine. If a user is not bound to a subset of CPUs, they could > > also cause disturbances with other syscalls and faults, taking locks, > >

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Thu, 28 Sep 2017 15:29:50 + (UTC) Mathieu Desnoyers wrote: > - On Sep 28, 2017, at 11:01 AM, Nicholas Piggin npig...@gmail.com wrote: > > > On Thu, 28 Sep 2017 13:31:36 + (UTC) > > Mathieu Desnoyers wrote: > > >

Re: [EXTERNAL]Re: FSL serial 166550 errata broken?

On Wed, 2017-09-27 at 15:32 +, York Sun wrote: > On 09/27/2017 04:03 AM, Joakim Tjernlund wrote: > > On Mon, 2017-09-25 at 17:26 +, York Sun wrote: > > > On 09/25/2017 09:55 AM, Joakim Tjernlund wrote: > > > > We got some "broken" boards(mpx8321) where UART RX is held low(BREAK) > > > >

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Fri, Sep 29, 2017 at 01:01:12AM +1000, Nicholas Piggin wrote: > That's fine. If a user is not bound to a subset of CPUs, they could > also cause disturbances with other syscalls and faults, taking locks, > causing tlb flushes and IPIs and things. So on the big SGI class machines we've had

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

- On Sep 28, 2017, at 11:01 AM, Nicholas Piggin npig...@gmail.com wrote: > On Thu, 28 Sep 2017 13:31:36 + (UTC) > Mathieu Desnoyers wrote: > >> - On Sep 27, 2017, at 9:04 AM, Nicholas Piggin npig...@gmail.com wrote: >> >> > On Tue, 26 Sep 2017

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

On Thu, 28 Sep 2017 13:31:36 + (UTC) Mathieu Desnoyers wrote: > - On Sep 27, 2017, at 9:04 AM, Nicholas Piggin npig...@gmail.com wrote: > > > On Tue, 26 Sep 2017 20:43:28 + (UTC) > > Mathieu Desnoyers wrote: > > >

[PATCH] selftests/powerpc: Use snprintf to construct DSCR sysfs interface paths

Currently sprintf is used, and while paths should never exceed the size of the buffer it is theoretically possible since dirent.d_name is 256 bytes. As a result this trips -Wformat-overflow, and since the test is built with -Wall -Werror the causes the build to fail. Switch to using snprintf and

[PATCH] powerpc: Always initialize input array when calling epapr_hypercall()

Several callers to epapr_hypercall() pass an uninitialized stack allocated array for the input arguments, presumably because they have no input arguments. However this can produce errors like this one arch/powerpc/include/asm/epapr_hcalls.h:470:42: error: 'in' may be used uninitialized in this

Re: [PATCH v4 for 4.14 1/3] membarrier: Provide register expedited private command

- On Sep 27, 2017, at 9:04 AM, Nicholas Piggin npig...@gmail.com wrote: > On Tue, 26 Sep 2017 20:43:28 + (UTC) > Mathieu Desnoyers wrote: > >> - On Sep 26, 2017, at 1:51 PM, Mathieu Desnoyers >> mathieu.desnoy...@efficios.com wrote: >> >> > Provide a

Re: [PATCH] powerpc/powernv: Use early_radix_enabled in POWER9 tlb flush

Nick,   I applied your patch into linux kernel 4.13, rebuild it, installed it, then had a test, still can not boot OS. System hung here, the same as before. Would you please have a look? The system is going down NOW!Sent SIGTERM to all processesSent SIGKILL to all processes[  104.755810]

Re: [PATCH v3 00/20] Speculative page faults

Hi Andrew, On 26/09/2017 01:34, Andrew Morton wrote: On Mon, 25 Sep 2017 09:27:43 -0700 Alexei Starovoitov wrote: On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour wrote: Despite the unprovable lockdep warning raised by Sergey, I

Re: [PATCH v3 00/20] Speculative page faults

Hi, On 26/09/2017 01:34, Andrew Morton wrote: On Mon, 25 Sep 2017 09:27:43 -0700 Alexei Starovoitov wrote: On Mon, Sep 18, 2017 at 12:15 AM, Laurent Dufour wrote: Despite the unprovable lockdep warning raised by Sergey, I didn't

RE: [PATCH v2 2/3] powerpc/64: enhance memcmp() with VMX instruction for long bytes comparision

From: Simon Guo > Sent: 27 September 2017 19:34 ... > > On X86 all the AVX registers are caller saved, the system call > > entry could issue the instruction that invalidates them all. > > Kernel code running in the context of a user process could then > > use the registers without saving them. > >

[PATCH kernel v3] vfio/spapr: Add cond_resched() for huge updates

Clearing very big IOMMU tables can trigger soft lockups. This adds cond_resched() to allow the scheduler to do context switching when it decides to. Signed-off-by: Alexey Kardashevskiy --- The testcase is POWER9 box with 264GB guest, 4 VFIO devices from independent IOMMU groups,

Re: [PATCH 1/1] KVM: PPC: Book3S: Fix server always zero from kvmppc_xive_get_xive()

On Thu, 2017-09-28 at 11:45 +1000, David Gibson wrote: > On Tue, Sep 26, 2017 at 04:47:04PM +1000, Sam Bobroff wrote: > > In KVM's XICS-on-XIVE emulation, kvmppc_xive_get_xive() returns the > > value of state->guest_server as "server". However, this value is not > > set by it's counterpart