[PATCH] powerpc/powernv/opal: Use standard interrupts property when available

2018-04-10 Thread Benjamin Herrenschmidt
For (bad) historical reasons, OPAL used to create a non-standard pair of properties "opal-interrupts" and "opal-interrupts-names" for representing the list of interrupts it wants Linux to request on its behalf. Among other issues, the opal-interrupts doesn't have a way to carry the type of interru

Re: Occasionally losing the tick_sched_timer

2018-04-10 Thread Thomas Gleixner
Nick, On Tue, 10 Apr 2018, Nicholas Piggin wrote: > We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no > more timers scheduled, despite hard and soft lockup watchdogs should have > their heart beat timers and probably many others. > > The reproducer we have is running a KVM w

Re: Occasionally losing the tick_sched_timer

2018-04-10 Thread Nicholas Piggin
On Tue, 10 Apr 2018 09:42:29 +0200 (CEST) Thomas Gleixner wrote: > Nick, > > On Tue, 10 Apr 2018, Nicholas Piggin wrote: > > We are seeing rare hard lockup watchdog timeouts, a CPU seems to have no > > more timers scheduled, despite hard and soft lockup watchdogs should have > > their heart beat

[PATCH] powerpc/8xx: Build fix with Hugetlbfs enabled

2018-04-10 Thread Aneesh Kumar K.V
8xx use slice code when hugetlbfs is enabled. We missed a header include on 8xx which resulted in the below build failure. config: mpc885_ads_defconfig + CONFIG_HUGETLBFS CC arch/powerpc/mm/slice.o arch/powerpc/mm/slice.c: In function 'slice_get_unmapped_area': arch/powerpc/mm/slice.c:655

Re: Occasionally losing the tick_sched_timer

2018-04-10 Thread Thomas Gleixner
On Tue, 10 Apr 2018, Nicholas Piggin wrote: > On Tue, 10 Apr 2018 09:42:29 +0200 (CEST) > Thomas Gleixner wrote: > > > Thomas do you have any ideas on what we might look for, or if we can add > > > some BUG_ON()s to catch this at its source? > > > > Not really. Tracing might be a more efficient

Re: [PATCH 00/32] docs/vm: convert to ReST format

2018-04-10 Thread Mike Rapoport
Jon, Andrew, How do you suggest to continue with this? On Sun, Apr 01, 2018 at 09:38:58AM +0300, Mike Rapoport wrote: > (added akpm) > > On Thu, Mar 29, 2018 at 03:46:07PM -0600, Jonathan Corbet wrote: > > On Wed, 21 Mar 2018 21:22:16 +0200 > > Mike Rapoport wrote: > > > > > These patches conv

[PATCH 1/3] powerpc/powernv: define a standard delay for OPAL_BUSY type retry loops

2018-04-10 Thread Nicholas Piggin
This is the start of an effort to tidy up and standardise all the delays. Existing loops have a range of delay/sleep periods from 1ms to 20ms, and some have no delay. They all loop forever except rtc, which times out after 10 retries, and that uses 10ms delays. So use 10ms as our standard delay. Th

[PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

2018-04-10 Thread Nicholas Piggin
The OPAL RTC driver does not sleep in case it gets OPAL_BUSY or OPAL_BUSY_EVENT from firmware, which causes large scheduling latencies, up to 50 seconds have been observed here when RTC stops responding (BMC reboot can do it). Fix this by converting it to the standard form OPAL_BUSY loop that slee

[PATCH 0/3] Fix RTC and NVRAM OPAL_BUSY loops

2018-04-10 Thread Nicholas Piggin
This is a couple of important fixes broken out of the series "first step of standardising OPAL_BUSY handling", that prevents the kernel from locking up if the NVRAM or RTC hardware does not respond. Another one, the console driver, has a similar problem that has also been hit in testing, but that

[PATCH 3/3] powerpc/powernv: Fix OPAL NVRAM driver OPAL_BUSY loops

2018-04-10 Thread Nicholas Piggin
The OPAL NVRAM driver does not sleep in case it gets OPAL_BUSY or OPAL_BUSY_EVENT from firmware, which causes large scheduling latencies, and various lockup errors to trigger (again, BMC reboot can cause it). Fix this by converting it to the standard form OPAL_BUSY loop that sleeps. Fixes: 628daa

Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

2018-04-10 Thread Alexandre Belloni
Hi Nicholas, I would greatly appreciate a changelog and at least the cover letter because it is difficult to grasp how this relates to the previous patches you sent to the RTC mailing list. On 10/04/2018 21:49:32+1000, Nicholas Piggin wrote: > The OPAL RTC driver does not sleep in case it gets O

[RFC PATCH 0/5] KVM TLB flushing improvements

2018-04-10 Thread Nicholas Piggin
This series adds powerpc:tlbie tracepoints for radix partition scoped invalidations. After I started getting some traces on a 32 vCPU radix guest it showed a problem with partition scoped faults/invalidates, so I had a try at fixing it. This seems to stable be on radix so far (haven't tested hash y

[RFC PATCH 1/5] powerpc/64s/mm: Implement LPID based TLB flushes to be used by KVM

2018-04-10 Thread Nicholas Piggin
Implent local TLB flush for entire LPID, for hash and radix, and a global TLB flush for a partition scoped page in an LPID, for radix. These will be used by KVM in subsequent patches. Signed-off-by: Nicholas Piggin --- .../include/asm/book3s/64/tlbflush-hash.h | 2 + .../include/asm/book3s

[RFC PATCH 2/5] KVM: PPC: Book3S HV: kvmppc_radix_tlbie_page use Linux flush function

2018-04-10 Thread Nicholas Piggin
This has the advantage of consolidating TLB flush code in fewer places, and it also implements powerpc:tlbie trace events. 1GB pages should be handled without further modification. Signed-off-by: Nicholas Piggin --- arch/powerpc/kvm/book3s_64_mmu_radix.c | 26 +++--- 1 file

[RFC PATCH 3/5] KVM: PPC: Book3S HV: kvmhv_p9_set_lpcr use Linux flush function

2018-04-10 Thread Nicholas Piggin
The existing flush uses the radix value for sets, and uses R=0 tlbiel instructions. This can't be quite right, but I'm not entirely sure if this is the right way to fix it. Signed-off-by: Nicholas Piggin --- arch/powerpc/kvm/book3s_hv_builtin.c | 14 +- 1 file changed, 5 insertions(+

[RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

2018-04-10 Thread Nicholas Piggin
Move this flushing out of assembly and have it use Linux TLB flush implementations introduced earlier. This allows powerpc:tlbie trace events to be used. Signed-off-by: Nicholas Piggin --- arch/powerpc/kvm/book3s_hv.c| 21 +++- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 43 +--

[RFC PATCH 5/5] KVM: PPC: Book3S HV: Radix do not clear partition scoped page table when page fault races with other vCPUs.

2018-04-10 Thread Nicholas Piggin
KVM with an SMP radix guest can get into storms of page faults and tlbies due to the partition scopd page tables being invalidated and TLB flushed if they were found to race with another page fault that set them up. This tends to cause vCPUs to pile up if several hit common addresses, then page fa

Re: [PATCH 2/3] powerpc/powernv: Fix OPAL RTC driver OPAL_BUSY loops

2018-04-10 Thread Nicholas Piggin
On Tue, 10 Apr 2018 14:07:28 +0200 Alexandre Belloni wrote: > Hi Nicholas, > > I would greatly appreciate a changelog and at least the cover letter > because it is difficult to grasp how this relates to the previous > patches you sent to the RTC mailing list. Yes good point. Basically this cha

[PATCH v2 1/2] powerpc/fadump: exclude memory holes while reserving memory in second kernel

2018-04-10 Thread Hari Bathini
From: Mahesh Salgaonkar The second kernel, during early boot after the crash, reserves rest of the memory above boot memory size to make sure it does not touch any of the dump memory area. It uses memblock_reserve() that reserves the specified memory region irrespective of memory holes present wi

[PATCH v2 2/2] powerpc/fadump: Do not use hugepages when fadump is active

2018-04-10 Thread Hari Bathini
FADump capture kernel boots in restricted memory environment preserving the context of previous kernel to save vmcore. Supporting hugepages in such environment makes things unnecessarily complicated, as hugepages need memory set aside for them. This means most of the capture kernel's memory is used

Re: [PATCH 2/3] mm: replace __HAVE_ARCH_PTE_SPECIAL

2018-04-10 Thread Laurent Dufour
On 09/04/2018 22:08, David Rientjes wrote: > On Mon, 9 Apr 2018, Christoph Hellwig wrote: > >>> -#ifdef __HAVE_ARCH_PTE_SPECIAL >>> +#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL >>> # define HAVE_PTE_SPECIAL 1 >>> #else >>> # define HAVE_PTE_SPECIAL 0 >> >> I'd say kill this odd indirection and just use

Re: [alsa-devel] [PATCH] ASoC: fsl_esai: Fix divisor calculation failure at lower ratio

2018-04-10 Thread Fabio Estevam
Hi Nicolin, On Sun, Apr 8, 2018 at 8:57 PM, Nicolin Chen wrote: > When the desired ratio is less than 256, the savesub (tolerance) > in the calculation would become 0. This will then fail the loop- > search immediately without reporting any errors. > > But if the ratio is smaller enough, there is

[PATCH v2 0/2] move __HAVE_ARCH_PTE_SPECIAL in Kconfig

2018-04-10 Thread Laurent Dufour
The per architecture __HAVE_ARCH_PTE_SPECIAL is defined statically in the per architecture header files. This doesn't allow to make other configuration dependent on it. The first patch of this series is replacing __HAVE_ARCH_PTE_SPECIAL by CONFIG_ARCH_HAS_PTE_SPECIAL defined into the Kconfig files

[PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

2018-04-10 Thread Laurent Dufour
Remove the additional define HAVE_PTE_SPECIAL and rely directly on CONFIG_ARCH_HAS_PTE_SPECIAL. There is no functional change introduced by this patch Signed-off-by: Laurent Dufour --- mm/memory.c | 23 ++- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/mm/m

[PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread Laurent Dufour
Currently the PTE special supports is turned on in per architecture header files. Most of the time, it is defined in arch/*/include/asm/pgtable.h depending or not on some other per architecture static definition. This patch introduce a new configuration variable to manage this directly in the Kcon

Re: [PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

2018-04-10 Thread Robin Murphy
On 10/04/18 16:25, Laurent Dufour wrote: Remove the additional define HAVE_PTE_SPECIAL and rely directly on CONFIG_ARCH_HAS_PTE_SPECIAL. There is no functional change introduced by this patch Signed-off-by: Laurent Dufour --- mm/memory.c | 23 ++- 1 file changed, 10 inse

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread Matthew Wilcox
On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote: > arch/powerpc/include/asm/pte-common.h | 3 --- > arch/riscv/Kconfig | 1 + > arch/s390/Kconfig | 1 + You forgot to delete __HAVE_ARCH_PTE_SPE

Re: [PATCH v9 17/24] mm: Protect mm_rb tree with a rwlock

2018-04-10 Thread Laurent Dufour
On 03/04/2018 02:11, David Rientjes wrote: > On Tue, 13 Mar 2018, Laurent Dufour wrote: > >> This change is inspired by the Peter's proposal patch [1] which was >> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in >> that particular case, and it is introducing major perfo

Re: [PATCH v9 16/24] mm: Introduce __page_add_new_anon_rmap()

2018-04-10 Thread Laurent Dufour
On 03/04/2018 01:57, David Rientjes wrote: > On Tue, 13 Mar 2018, Laurent Dufour wrote: > >> When dealing with speculative page fault handler, we may race with VMA >> being split or merged. In this case the vma->vm_start and vm->vm_end >> fields may not match the address the page fault is occurrin

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread Laurent Dufour
On 10/04/2018 18:09, Matthew Wilcox wrote: > On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote: >> arch/powerpc/include/asm/pte-common.h | 3 --- >> arch/riscv/Kconfig | 1 + >> arch/s390/Kconfig

Re: [PATCH v2 2/2] mm: remove odd HAVE_PTE_SPECIAL

2018-04-10 Thread Laurent Dufour
On 10/04/2018 17:58, Robin Murphy wrote: > On 10/04/18 16:25, Laurent Dufour wrote: >> Remove the additional define HAVE_PTE_SPECIAL and rely directly on >> CONFIG_ARCH_HAS_PTE_SPECIAL. >> >> There is no functional change introduced by this patch >> >> Signed-off-by: Laurent Dufour >> --- >>   m

Re: [PATCH v3] powerpc/64: Fix section mismatch warnings for early boot symbols

2018-04-10 Thread Mauricio Faria de Oliveira
On 04/09/2018 11:51 PM, Michael Ellerman wrote: Thanks for picking this one up. I hate to be a pain ... but before we merge this and proliferate these names, I'd like to change the names of some of these early asm functions. They're terribly named due to historical reasons. Indeed :) No worrie

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

2018-04-10 Thread Bjorn Helgaas
On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote: > The disabling informational messages on the PCI subsystem should be deleted > since they do not represent any real value for the system logs. > > These messages are either not presented, or presented for all PCI devices

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

2018-04-10 Thread Bjorn Helgaas
On Tue, Apr 10, 2018 at 02:36:31PM -0500, Bjorn Helgaas wrote: > On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote: > > The disabling informational messages on the PCI subsystem should be deleted > > since they do not represent any real value for the system logs. > > > > T

Re: [PATCH 5/5] powerpc:dts:pm: add power management node

2018-04-10 Thread Li Yang
On Wed, Mar 28, 2018 at 8:31 PM, Ran Wang wrote: > Enable Power Management feature on device tree, including MPC8536, > MPC8544, MPC8548, MPC8572, P1010, P1020, P1021, P1022, P2020, P2041, > P3041, T104X, T1024. There are no device tree bindings documented for the properties and compatible string

Re: [PATCH, RESEND, pci, v2] pci: Delete PCI disabling informational messages

2018-04-10 Thread Desnes A. Nunes do Rosario
Bjorn, On 04/10/2018 04:55 PM, Bjorn Helgaas wrote: On Tue, Apr 10, 2018 at 02:36:31PM -0500, Bjorn Helgaas wrote: On Wed, Apr 04, 2018 at 12:10:35PM -0300, Desnes A. Nunes do Rosario wrote: The disabling informational messages on the PCI subsystem should be deleted since they do not represent

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread Palmer Dabbelt
On Tue, 10 Apr 2018 09:09:32 PDT (-0700), wi...@infradead.org wrote: On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote: arch/powerpc/include/asm/pte-common.h | 3 --- arch/riscv/Kconfig | 1 + arch/s390/Kconfig

Re: [PATCH v2 1/2] mm: introduce ARCH_HAS_PTE_SPECIAL

2018-04-10 Thread David Rientjes
On Tue, 10 Apr 2018, Laurent Dufour wrote: > > On Tue, Apr 10, 2018 at 05:25:50PM +0200, Laurent Dufour wrote: > >> arch/powerpc/include/asm/pte-common.h | 3 --- > >> arch/riscv/Kconfig | 1 + > >> arch/s390/Kconfig

[PATCH] ibmvnic: Define vnic_login_client_data name field as unsized array

2018-04-10 Thread Kees Cook
The "name" field of struct vnic_login_client_data is a char array of undefined length. This should be written as "char name[]" so the compiler can make better decisions about the field (for example, not assuming it's a single character). This was noticed while trying to tighten the CONFIG_FORTIFY_S

Re: [RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

2018-04-10 Thread Benjamin Herrenschmidt
On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote: > > + /* > +* Do we need to flush the TLB for the LPAR? (see TLB comment above) > + * On POWER9, individual threads can come in here, but the > + * TLB is shared between the 4 threads in a core, hence > +

Re: [RFC PATCH 4/5] KVM: PPC: Book3S HV: handle need_tlb_flush in C before low-level guest entry

2018-04-10 Thread Nicholas Piggin
On Wed, 11 Apr 2018 11:32:12 +1000 Benjamin Herrenschmidt wrote: > On Tue, 2018-04-10 at 22:48 +1000, Nicholas Piggin wrote: > > > > + /* > > +* Do we need to flush the TLB for the LPAR? (see TLB comment above) > > + * On POWER9, individual threads can come in here, but th

[PATCH] powerpc/eeh: Fix enabling bridge MMIO windows

2018-04-10 Thread Michael Neuling
On boot we save the configuration space of PCIe bridges. We do this so when we get an EEH event and everything gets reset that we can restore them. Unfortunately we save this state before we've enabled the MMIO space on the bridges. Hence if we have to reset the bridge when we come back MMIO is no

Re: [PATCH 1/2] powerpc/mm: Flush cache on memory hot(un)plug

2018-04-10 Thread rashmica
On 06/04/18 15:24, Balbir Singh wrote: > This patch adds support for flushing potentially dirty > cache lines when memory is hot-plugged/hot-un-plugged. > The support is currently limited to 64 bit systems. > > The bug was exposed when mappings for a device were > actually hot-unplugged and plugg

Re: [PATCH 2/2] powerpc/mm/memtrace: Let the arch hotunplug code flush cache

2018-04-10 Thread rashmica
On 06/04/18 15:24, Balbir Singh wrote: > Don't do this via custom code, instead now that we have support > in the arch hotplug/hotunplug code, rely on those routines > to do the right thing. > > Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory > tracing") > because t

[PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

2018-04-10 Thread Benjamin Herrenschmidt
When setting up a CPU, we "push" (activate) a pool VP for it. However it's an error to do so if it already has an active pool VP. This happens when doing soft CPU hotplug on powernv since we don't tear down the CPU on unplug. The HW flags the error which gets captured by the diagnostics. Fix thi

[PATCH 3/3] powerpc/xive: Remove xive_kexec_teardown_cpu()

2018-04-10 Thread Benjamin Herrenschmidt
It's identical to xive_teardown_cpu() so just use the latter Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/include/asm/xive.h| 1 - arch/powerpc/platforms/powernv/setup.c | 2 +- arch/powerpc/platforms/pseries/kexec.c | 2 +- arch/powerpc/sysdev/xive/common.c | 22 --

[PATCH 2/3] powerpc/xive: Remove now useless pr_debug statements

2018-04-10 Thread Benjamin Herrenschmidt
Those overly verbose statement in the setup of the pool VP aren't particularly useful (esp. considering we don't actually use the pool, we configure it bcs HW requires it only). So remove them which improves the code readability. Signed-off-by: Benjamin Herrenschmidt --- arch/powerpc/sysdev/xive

Re: [PATCH 1/3] powerpc/xive: Fix trying to "push" an already active pool VP

2018-04-10 Thread Benjamin Herrenschmidt
On Wed, 2018-04-11 at 15:17 +1000, Benjamin Herrenschmidt wrote: > When setting up a CPU, we "push" (activate) a pool VP for it. > > However it's an error to do so if it already has an active > pool VP. > > This happens when doing soft CPU hotplug on powernv since we > don't tear down the CPU on

[PATCH 1/2] powernv/npu: Add lock to prevent race in concurrent context init/destroy

2018-04-10 Thread Alistair Popple
The pnv_npu2_init_context() and pnv_npu2_destroy_context() functions are used to allocate/free contexts to allow address translation and shootdown by the NPU on a particular GPU. Context initialisation is implicitly safe as it is protected by the requirement mmap_sem be held in write mode, however

[PATCH 2/2] powernv/npu: Prevent overwriting of pnv_npu2_init_contex() callback parameters

2018-04-10 Thread Alistair Popple
There is a single npu context per set of callback parameters. Callers should be prevented from overwriting existing callback values so instead return an error if different parameters are passed. Signed-off-by: Alistair Popple --- arch/powerpc/include/asm/powernv.h | 2 +- arch/powerpc/pla

[PATCH v2 1/6] powerpc/pm: Fix suspend=n in menuconfig for e500mc platforms.

2018-04-10 Thread Ran Wang
Also, unselect FSL_PMC which is for older platfroms instead. Signed-off-by: Ran Wang --- Changes in v2: - no change arch/powerpc/Kconfig |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 73ce5dd..ed60c83 100644 --- a/