[PATCH v3 2/3] powerpc/64s/idle: avoid sync for KVM state when waking from idle

When waking from a CPU idle instruction (e.g., nap or stop), the sync for ordering the KVM secondary thread state can be avoided if there wakeup is coming from a kernel context rather than KVM context. This improves performance for ping-pong benchmark with the stop0 idle state by 0.46% for 2

[PATCH v3 1/3] powerpc/64s/idle: POWER9 implement a separate idle stop function for hotplug

Implement a new function to invoke stop, power9_offline_stop, which is like power9_idle_stop but used by the cpu hotplug code. Move KVM secondary state manipulation code to the offline case. Cc: Vaidyanathan Srinivasan Cc: Gautham R. Shenoy

[PATCH v3 0/3] idle improvements again

Since last time, this has been rebased on top of the KVM / SMT4 forcing changes. It has also been updated so as to not disable EC=ESL=0 idle states for CPU unplug. That case (and powersave=off) continues to be broken for KVM with unplugged dependent secondaries, but that's another issue. This

[PATCH] powerpc/powernv: Fix SMT4 forcing idle code

PSSCR value is not stored to PACA_REQ_PSSCR in case the CPU does not have the XER[SO] bug. Fix this by storing up-front, outside the workaround code. The initial test is not required because it is a slow path. The workaround is made to depend on CONFIG_KVM_BOOK3S_HV_POSSIBLE, to match

[PATCH 09/12] block/swim: Rename macros to avoid inconsistent inverted logic

The Sony drive status bits use active-low logic. The swim_readbit() function converts that to 'C' logic for readability. Hence, the sense of the names of the status bit macros should not be inverted. Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and TWOMEG_MEDIA macros have

Re: [PATCH] Patch to replace DEFINE_SEMAPHORE with DEFINE_BINARY_SEMAPHORE

On Sat, Mar 31, 2018 at 07:16:21PM +0530, Wasim Nazir wrote: > This message contains confidential information and is intended only for the > individual(s) named. If you are not the intended recipient, you are > notified that disclosing, copying, distributing or taking any action in > reliance

Re: powerpc/mpic: Check if cpu_possible() in mpic_physmask()

On Sat, 2018-03-31 at 14:00:24 UTC, Michael Ellerman wrote: > In mpic_physmask() we loop over all CPUs up to 32, then get the hard > SMP processor id of that CPU. > > Currently that's possibly walking off the end of the paca array, but > in a future patch we will change the paca array to be an

Re: powerpc/64e: Fix oops due to deferral of paca allocation

On Sat, 2018-03-31 at 11:51:38 UTC, Michael Ellerman wrote: > On 64-bit Book3E systems, in setup_tlb_core_data() we reference other > CPUs pacas. But in commit 59f577743d71 ("powerpc/64: Defer paca > allocation until memory topology is discovered") the allocation of > non-boot-CPU pacas was

Re: powerpc/kvm: Fix guest boot issue DAWR cpu feature

On Fri, 2018-03-30 at 11:57:24 UTC, "Aneesh Kumar K.V" wrote: > SLOF check the 'sc 1' support by issuing a hcall with H_SET_DABR. With > recent patch to make the hcall return H_UNSUPPORTED, we get guest boot > failures. SLOF can work with the hcall failure H_HARDWARE for the above > hcall. Switch

Re: powerpc: kexec_file: Fix error code when trying to load kdump kernel

On Thu, 2018-03-29 at 19:05:43 UTC, Thiago Jung Bauermann wrote: > kexec_file_load() on powerpc doesn't support kdump kernels yet, so it > returns -ENOTSUPP in that case. > > I've recently learned that this errno is internal to the kernel and isn't > supposed to be exposed to userspace.

Re: powerpc/pseries: Fix to clear security feature flags

On Thu, 2018-03-29 at 18:32:11 UTC, Mauricio Faria de Oliveira wrote: > The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field > of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags. > > Found it by playing around with QEMU's implementation of the hypercall: > >

Re: macintosh/adb: Use C99 initializers for struct adb_driver instances

On Thu, 2018-03-29 at 00:36:04 UTC, Finn Thain wrote: > No change to object files. > > Cc: Benjamin Herrenschmidt > Signed-off-by: Finn Thain Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/3a52f6f980c45b0dfa667f30d3ff03

Re: powerpc/mm: Fix thread_pkey_regs_init()

On Tue, 2018-03-27 at 02:36:54 UTC, Ram Pai wrote: > thread_pkey_regs_init() initializes the pkey related registers > instead of initializing the fields in the task structures. Fortunately > those key related registers are re-set to zero when the task > gets scheduled on the cpu. However its good

Re: [v2, 1/5] powerpc: mm: Simplify page_is_ram by using memblock_is_memory

On Wed, 2018-03-28 at 00:25:40 UTC, =?utf-8?q?Jonathan_Neusch=C3=A4fer?= wrote: > Instead of open-coding the search in page_is_ram, call memblock_is_memory. > > Signed-off-by: Jonathan Neuschäfer Series applied to powerpc next, thanks.

Re: powerpc/powernv/nvram: opal_nvram_write handle unknown OPAL errors

On Mon, 2018-03-26 at 15:02:33 UTC, Nicholas Piggin wrote: > opal_nvram_write currently just assumes success if it encounters an > error other than OPAL_BUSY or OPAL_BUSY_EVENT. Have it return -EIO > on other errors instead. > > Signed-off-by: Nicholas Piggin > Reviewed-by:

Re: [-next] powerpc: Fix error return code in ppc4xx_msi_probe()

On Mon, 2018-03-26 at 14:43:09 UTC, Wei Yongjun wrote: > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied to powerpc next, thanks.

Re: [v2] powerpc/eeh: Fix race with driver un/bind

On Mon, 2018-03-26 at 04:17:07 UTC, Michael Neuling wrote: > The current EEH callbacks can race with a driver unbind. This > can result in a backtraces like this: > > [7.573055] EEH: Frozen PHB#0-PE#1fc detected > [7.573063] EEH: PE location: S09, PHB location: N/A > [7.573069]

Re: [V6, 1/4] powerpc/mm/slice: Consolidate return path in slice_get_unmapped_area()

On Mon, 2018-03-26 at 10:04:47 UTC, "Aneesh Kumar K.V" wrote: > In a following patch, on finding a free area we will need to do > allocatinon of extra contexts as needed. Consolidating the return path > for slice_get_unmapped_area() will make that easier. > > Split into a separate patch to make

Re: powerpc: Fix smp_wmb barrier definition use use lwsync consistently

On Thu, 2018-03-22 at 10:41:46 UTC, Nicholas Piggin wrote: > asm/barrier.h is not always included after asm/synch.h, which meant > it was missing __SUBARCH_HAS_LWSYNC, so in some files smp_wmb() would > be eieio when it should be lwsync. kernel/time/hrtimer.c is one case. > > __SUBARCH_HAS_LWSYNC

Re: powerpc: wii.dts: Add drive slot LED

On Sat, 2018-03-17 at 15:06:17 UTC, =?utf-8?q?Jonathan_Neusch=C3=A4fer?= wrote: > The Wii has a blue LED in the disk drive slot, which is controlled via a > GPIO line. Add this LED to wii.dts, and mark it as a panic-indicator. > > Signed-off-by: Jonathan Neuschäfer

Re: drivers: macintosh: rack-meter: really fix bogus memsets

On Fri, 2018-03-16 at 20:17:28 UTC, Aaro Koskinen wrote: > We should zero an array using sizeof instead of number of elements. > > Fixes the following compiler (GCC 7.3.0) warnings: > > drivers/macintosh/rack-meter.c: In function 'rackmeter_do_pause': > drivers/macintosh/rack-meter.c:157:2:

Re: powerpc/xive: Fix wrong xmon output caused by typo

On Wed, 2018-03-14 at 17:01:14 UTC, Frederic Barrat wrote: > Signed-off-by: Frederic Barrat Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/16b19f1a03f6a49618611b76818f04 cheers

Re: [1/2] powerpc/mm/keys: Move pte bits to correct headers

On Wed, 2018-03-07 at 13:36:44 UTC, "Aneesh Kumar K.V" wrote: > Memory keys are supported only with hash translation mode. Instead of #ifdef > in > generic code move the key related pte bits to respective headers > > Signed-off-by: Aneesh Kumar K.V Applied to

Re: [01/14] powerpc/64s: do not allocate lppaca if we are not virtualized

On Tue, 2018-02-13 at 15:08:11 UTC, Nicholas Piggin wrote: > The "lppaca" is a structure registered with the hypervisor. This > is unnecessary when running on non-virtualised platforms. One field > from the lppaca (pmcregs_in_use) is also used by the host, so move > the host part out into the paca

Re: [v3, 1/4] powerpc: wii: Explicitly configure GPIO owner for poweroff pin

On Fri, 2018-02-09 at 12:07:28 UTC, =?utf-8?q?Jonathan_Neusch=C3=A4fer?= wrote: > The Hollywood chipset's GPIO controller has two sets of registers: One > for access by the PowerPC CPU, and one for access by the ARM coprocessor > (but both are accessible from the PPC because the memory firewall >

Re: powerpc: wii: Probe the whole devicetree

On Tue, 2018-02-06 at 12:37:04 UTC, =?utf-8?q?Jonathan_Neusch=C3=A4fer?= wrote: > Previously, wii_device_probe would only initialize devices under the > /hollywood node. After this patch, platform devices placed outside of > /hollywood will also be initialized. > > The intended usecase for this

Re: powerpc/kprobes: Fix call trace due to incorrect preempt count

On Wed, 2018-01-17 at 12:22:24 UTC, "Naveen N. Rao" wrote: > Michael Ellerman reported the following call trace when running > ftracetest: > > BUG: using __this_cpu_write() in preemptible [] code: ftracetest/6178 > caller is opt_pre_handler+0xc4/0x110 > CPU: 1 PID: 6178 Comm: ftracetest

[PATCH] powerpc/mpic: Check if cpu_possible() in mpic_physmask()

In mpic_physmask() we loop over all CPUs up to 32, then get the hard SMP processor id of that CPU. Currently that's possibly walking off the end of the paca array, but in a future patch we will change the paca array to be an array of pointers, and in that case we will get a NULL for missing CPUs

[PATCH] powerpc/64e: Fix oops due to deferral of paca allocation

On 64-bit Book3E systems, in setup_tlb_core_data() we reference other CPUs pacas. But in commit 59f577743d71 ("powerpc/64: Defer paca allocation until memory topology is discovered") the allocation of non-boot-CPU pacas was deferred until later in boot. This leads to an oops: CPU maps

Re: [PATCH 3/3] powerpc/64s/idle: POWER9 ESL=0 stop avoid save/restore overhead

Nicholas Piggin writes: > When stop is executed with EC=ESL=0, it appears to execute like a > normal instruction (resuming from NIP when woken by interrupt). So all > the save/restore handling can be avoided completely. In particular NV > GPRs do not have to be saved, and MSR

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote: > Hi! > > > Current implementation doesn't randomize address returned by mmap. > > All the entropy ends with choosing mmap_base_addr at the process > > creation. After that mmap build very predictable layout of address > > space. It