Re: [PATCH v2 7/9] powerpc/64s: do not allocate lppaca if we are not virtualized

On Sat, 14 Oct 2017 09:47:59 +1100 Paul Mackerras wrote: > On Sun, Aug 13, 2017 at 11:33:44AM +1000, 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

Re: [PATCH v2] KVM: PPC: Book3S PR: only install valid SLBs during KVM_SET_SREGS

On Mon, Oct 02, 2017 at 10:40:22AM +0200, Greg Kurz wrote: > Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS, > some of which are valid (ie, SLB_ESID_V is set) and the rest are > likely all-zeroes (with QEMU at least). > > Each of them is then passed to

Re: [PATCH kernel] KVM: PPC: Protect kvmppc_gpa_to_ua() with srcu

On Wed, Oct 11, 2017 at 04:00:34PM +1100, Alexey Kardashevskiy wrote: > kvmppc_gpa_to_ua() accesses KVM memory slot array via > srcu_dereference_check() and this produces warnings from RCU like below. > > This extends the existing srcu_read_lock/unlock to cover that > kvmppc_gpa_to_ua() as well.

Re: [PATCH] KVM: PPC: Book3S HV: POWER9 more doorbell fixes

On Tue, Oct 10, 2017 at 08:18:28PM +1000, Nicholas Piggin wrote: > - Add another case where msgsync is required. > - Required barrier sequence for global doorbells is msgsync ; lwsync > - POWER9 DD1 has a different barrier sequence that we don't implement, > so remove > > When msgsnd is used

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

On Thu, Sep 14, 2017 at 11:56:25PM +0200, Greg Kurz wrote: > The following program causes a kernel oops: > > #include > #include > #include > #include > #include > > main() > { > int fd = open("/dev/kvm", O_RDWR); > ioctl(fd, KVM_CHECK_EXTENSION, KVM_CAP_PPC_HTM); > } > > This

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

On Fri, Oct 13, 2017 at 06:14:00PM +0200, Paolo Bonzini wrote: > On 13/10/2017 01:16, Greg Kurz wrote: > > Ping ? > > When is Paul back from vacation? :) Now. :) Paul.

Re: [PATCH v2 7/9] powerpc/64s: do not allocate lppaca if we are not virtualized

On Sun, Aug 13, 2017 at 11:33:44AM +1000, 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

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

Hi James, all, (add linux-...@vger.kernel.org as it is user-visible, Catalin Marinas and Arnd Bergmann ) On Thu, Jun 29, 2017 at 05:26:37PM +0100, James Morse wrote: > compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, > instead using those in ptrace_request(). The

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On 10/13/17 1:05 PM, Alex Williamson wrote: On Fri, 13 Oct 2017 07:01:48 -0500 Steven Royer wrote: On 2017-10-13 06:53, Steven Royer wrote: On 2017-10-12 22:34, Bjorn Helgaas wrote: [+cc Alex, Bodong, Eli, Saeed] On Thu, Oct 12, 2017 at 02:59:23PM -0500,

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On Fri, 13 Oct 2017 07:01:48 -0500 Steven Royer wrote: > On 2017-10-13 06:53, Steven Royer wrote: > > On 2017-10-12 22:34, Bjorn Helgaas wrote: > >> [+cc Alex, Bodong, Eli, Saeed] > >> > >> On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote: > >>> On

[PATCH v12 10/11] sparc64: optimized struct page zeroing

Add an optimized mm_zero_struct_page(), so struct page's are zeroed without calling memset(). We do eight to ten regular stores based on the size of struct page. Compiler optimizes out the conditions of switch() statement. SPARC-M6 with 15T of memory, single thread performance:

[PATCH v12 05/11] mm: defining memblock_virt_alloc_try_nid_raw

* A new variant of memblock_virt_alloc_* allocations: memblock_virt_alloc_try_nid_raw() - Does not zero the allocated memory - Does not panic if request cannot be satisfied * optimize early system hash allocations Clients can call alloc_large_system_hash() with flag: HASH_ZERO to specify

[PATCH v12 00/11] complete deferred page initialization

Changelog: v12 - v11 - Improved comments for mm: zero reserved and unavailable struct pages - Added back patch: mm: deferred_init_memmap improvements - Added patch from Will Deacon: arm64: kasan: Avoid using vmemmap_populate to initialise shadow v11 - v10 - Moved kasan_map_populate()

[PATCH v12 09/11] mm: stop zeroing memory during allocation in vmemmap

vmemmap_alloc_block() will no longer zero the block, so zero memory at its call sites for everything except struct pages. Struct page memory is zero'd by struct page initialization. Replace allocators in sprase-vmemmap to use the non-zeroing version. So, we will get the performance improvement

[PATCH v12 02/11] x86/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled, however, we set fields in

[PATCH v12 08/11] arm64/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v12 11/11] arm64: kasan: Avoid using vmemmap_populate to initialise shadow

From: Will Deacon The kasan shadow is currently mapped using vmemmap_populate since that provides a semi-convenient way to map pages into swapper. However, since that no longer zeroes the mapped pages, it is not suitable for kasan, which requires that the shadow is zeroed in

[PATCH v12 04/11] sparc64: simplify vmemmap_populate

Remove duplicating code by using common functions vmemmap_pud_populate and vmemmap_pgd_populate. Signed-off-by: Pavel Tatashin Reviewed-by: Steven Sistare Reviewed-by: Daniel Jordan Reviewed-by: Bob Picco

[PATCH v12 06/11] mm: zero reserved and unavailable struct pages

Some memory is reserved but unavailable: not present in memblock.memory (because not backed by physical pages), but present in memblock.reserved. Such memory has backing struct pages, but they are not initialized by going through __init_single_page(). In some cases these struct pages are accessed

[PATCH v12 03/11] sparc64/mm: setting fields in deferred pages

Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT), flags and other fields in "struct page"es are never changed prior to first initializing struct pages by going through __init_single_page(). With deferred struct page feature enabled there is a case where we set some fields

[PATCH v12 01/11] mm: deferred_init_memmap improvements

deferred_init_memmap() is called when struct pages are initialized later in boot by slave CPUs. This patch simplifies and optimizes this function, and also fixes a couple issues (described below). The main change is that now we are iterating through free memblock areas instead of all configured

[PATCH v12 07/11] x86/kasan: add and use kasan_map_populate()

During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate()

[PATCH v1] powerpc/pci: convert to use for_each_pci_bridge() helper

...which makes code slightly cleaner. Requires: d43f59ce6c50 ("PCI: Add for_each_pci_bridge() helper") Signed-off-by: Andy Shevchenko --- arch/powerpc/kernel/pci-hotplug.c | 7 ++- arch/powerpc/kernel/pci_of_scan.c | 7 ++- 2 files changed, 4

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

On Fri, Oct 13, 2017 at 12:00:27PM -0400, Pavel Tatashin wrote: > BTW, don't we need the same aligments inside for_each_memblock() loop? Hmm, yes actually, given that we shift them right for the shadow address. > How about change kasan_map_populate() to accept regular VA start, end > address,

Re: [PATCH] KVM: PPC: fix oops when checking KVM_CAP_PPC_HTM

On 13/10/2017 01:16, Greg Kurz wrote: > Ping ? When is Paul back from vacation? :) Paolo > On Thu, 14 Sep 2017 23:56:25 +0200 > Greg Kurz wrote: > >> The following program causes a kernel oops: >> >> #include >> #include >> #include >> #include >> #include >> >> main() >>

[PATCH tip/sched/membarrier 5/5] Fix: membarrier: Handle CLONE_VM + !CLONE_THREAD correctly on powerpc

From: Mathieu Desnoyers Threads targeting the same VM but which belong to different thread groups is a tricky case. It has a few consequences: It turns out that we cannot rely on get_nr_threads(p) to count the number of threads using a VM. We can use

[PATCH tip/sched/membarrier 1/5] membarrier: Provide register expedited private command

From: Mathieu Desnoyers Provide a new command allowing processes to register their intent to use the private expedited command. This allows PowerPC to skip the full memory barrier in switch_mm(), and only issue the barrier when scheduling into a task belonging to

[PATCH tip/sched/membarrier 4/5] membarrier: Remove unused code for architectures without membarrier hooks

From: Mathieu Desnoyers Architectures without membarrier hooks don't need to emit the empty membarrier_arch_switch_mm() static inline when CONFIG_MEMBARRIER=y. Adapt the CONFIG_MEMBARRIER=n counterpart to only emit the empty membarrier_arch_switch_mm() for

Re: [PATCH] powerpc/eeh: make eeh_ops structures _ro_after_init

On Fri, Oct 13, 2017 at 6:08 PM, Julia Lawall wrote: > > > On Fri, 13 Oct 2017, Bhumika Goyal wrote: > >> These structures are passed to the eeh_ops_register function during the >> initialization phase. There they get stored in a structure variable >> which only makes

Re: [PATCH] powerpc/eeh: make eeh_ops structures _ro_after_init

On Fri, 13 Oct 2017, Bhumika Goyal wrote: > These structures are passed to the eeh_ops_register function during the > initialization phase. There they get stored in a structure variable > which only makes function calls through function pointers. There is no > other usage of these eeh_ops

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

BTW, don't we need the same aligments inside for_each_memblock() loop? How about change kasan_map_populate() to accept regular VA start, end address, and convert them internally after aligning to PAGE_SIZE? Thank you, Pavel On Fri, Oct 13, 2017 at 11:54 AM, Pavel Tatashin

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

> Thanks for sharing the .config and tree. It looks like the problem is that > kimg_shadow_start and kimg_shadow_end are not page-aligned. Whilst I fix > them up in kasan_map_populate, they remain unaligned when passed to > kasan_populate_zero_shadow, which confuses the loop termination conditions

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Hi Pavel, On Fri, Oct 13, 2017 at 11:09:41AM -0400, Pavel Tatashin wrote: > > It shouldn't be difficult to use section mappings with my patch, I just > > don't really see the need to try to optimise TLB pressure when you're > > running with KASAN enabled which already has something like a 3x

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Here is simplified qemu command: qemu-system-aarch64 \ -display none \ -kernel ./arch/arm64/boot/Image \ -M virt -cpu cortex-a57 -s -S In a separate terminal start arm64 cross debugger: $ aarch64-unknown-linux-gnu-gdb ./vmlinux ... Reading symbols from ./vmlinux...done. (gdb)

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

> It shouldn't be difficult to use section mappings with my patch, I just > don't really see the need to try to optimise TLB pressure when you're > running with KASAN enabled which already has something like a 3x slowdown > afaik. If it ends up being a big deal, we can always do that later, but >

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

> Do you know what your physical memory layout looks like? [0.00] Memory: 34960K/131072K available (16316K kernel code, 6716K rwdata, 7996K rodata, 1472K init, 8837K bss, 79728K reserved, 16384K cma-reserved) [0.00] Virtual kernel memory layout: [0.00] kasan :

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Hi, On Fri, Oct 13, 2017 at 03:43:19PM +0100, Will Deacon wrote: > On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote: > > I am getting the following panic during boot: > > > > [0.012637] pid_max: default: 32768 minimum: 301 > > [0.016037] Security Framework initialized > > [

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Hi Pavel, On Fri, Oct 13, 2017 at 10:10:09AM -0400, Pavel Tatashin wrote: > I have a couple concerns about your patch: > > One of the reasons (and actually, the main reason) why I preferred to > keep vmemmap_populate() instead of implementing kasan's own variant, > which btw can be done in

Re: [PATCH v11 7/9] arm64/kasan: add and use kasan_map_populate()

Hi Will, I have a couple concerns about your patch: One of the reasons (and actually, the main reason) why I preferred to keep vmemmap_populate() instead of implementing kasan's own variant, which btw can be done in common code similarly to vmemmap_populate_basepages() is that vmemmap_populate()

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On 10/13/2017 05:37 AM, Michael Ellerman wrote: > > I really dislike this. > > You're basically saying the kernel can't work out how to get a device > working, so let's leave it up to the user. Oh, it was never my intention to say such blasphemy :) It meant to be just a debug option to help the

[PATCH] powerpc/eeh: make eeh_ops structures _ro_after_init

These structures are passed to the eeh_ops_register function during the initialization phase. There they get stored in a structure variable which only makes function calls through function pointers. There is no other usage of these eeh_ops structures and their fields are never modified after init

[PATCH 1/1] KVM: PPC: Book3S: Add MMIO emulation for VMX instructions

This patch provides the MMIO load/store vector indexed X-Form emulation. Instructions implemented: lvx, stvx Signed-off-by: Jose Ricardo Ziviani --- arch/powerpc/include/asm/kvm_host.h | 2 + arch/powerpc/include/asm/kvm_ppc.h| 4 +

[PATCH 0/1] powerpc: Implements MMIO emulation for lvx/stvx instructions

Hello! This patch implements MMIO emulation for two instructions: lvx and stvx. Thank you! Jose Ricardo Ziviani (1): KVM: PPC: Book3S: Add MMIO emulation for VMX instructions arch/powerpc/include/asm/kvm_host.h | 2 + arch/powerpc/include/asm/kvm_ppc.h| 4 +

Re: [V2] powerpc/perf: Fix IMC initialization crash

On Fri, 2017-10-13 at 05:59:41 UTC, Anju T Sudhakar wrote: > Call trace observed with latest firmware, and upstream kernel. > > [ 14.499938] NIP [c00f318c] init_imc_pmu+0x8c/0xcf0 > [ 14.499973] LR [c00f33f8] init_imc_pmu+0x2f8/0xcf0 > [ 14.57] Call Trace: > [

Re: powerpc/perf: Add ___GFP_NOWARN flag to alloc_pages_node()

On Wed, 2017-10-11 at 12:57:39 UTC, Anju T Sudhakar wrote: > Stack trace output during a stress test: > [4.310049] Freeing initrd memory: 22592K > [4.310646] rtas_flash: no firmware flash support > [4.313341] cpuhp/64: page allocation failure: order:0, >

Re: powerpc/perf: Fix for core/nest imc call trace on cpuhotplug

On Wed, 2017-10-04 at 06:50:52 UTC, Anju T Sudhakar wrote: > Nest/core pmu units are enabled only when it is used. A reference count is > > maintained for the events which uses the nest/core pmu units. Currently in > > *_imc_counters_release function a WARN() is used for notification

[GIT PULL] Please pull powerpc/linux.git powerpc-4.14-5 tag

Hi Linus, Please pull a few more powerpc fixes for 4.14: The following changes since commit 53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0: powerpc/powernv: Increase memory block size to 1GB on radix (2017-10-06 15:50:45 +1100) are available in the git repository at:

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On 2017-10-13 06:53, Steven Royer wrote: On 2017-10-12 22:34, Bjorn Helgaas wrote: [+cc Alex, Bodong, Eli, Saeed] On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote: On 10/12/17 1:29 PM, Bjorn Helgaas wrote: >On Thu, Oct 12, 2017 at 03:09:53PM +1100, Michael Ellerman wrote: >>Bjorn

Re: [PATCH v3 2/2] pseries/eeh: Add Pseries pcibios_bus_add_device

On 2017-10-12 22:34, Bjorn Helgaas wrote: [+cc Alex, Bodong, Eli, Saeed] On Thu, Oct 12, 2017 at 02:59:23PM -0500, Bryant G. Ly wrote: On 10/12/17 1:29 PM, Bjorn Helgaas wrote: >On Thu, Oct 12, 2017 at 03:09:53PM +1100, Michael Ellerman wrote: >>Bjorn Helgaas writes: >>

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

"Guilherme G. Piccoli" writes: > During a kdump kernel boot in PowerPC, we request a reset of the > PHBs to the FW. It makes sense, since if we are booting a kdump > kernel it means we had some trouble before and we cannot rely in > the adapters' health; they could

Re: KASan for powerpc

Hi Balbir,sorry for not mentioning details. below are the details1. What machine you tried this on?    - I am using PowerPC e500mc processor with and it's customised. Can't share much details 2. What MMU mode?    -Not sure about this. 3. What kernel?    -kernel version is 4.1.35 4. What gcc

Re: [PATCH 1/2] vgaarb: Select a default VGA device even if there's no legacy VGA

On 12/10/17 13:05, Lothar Waßmann wrote: Hi, On Thu, 12 Oct 2017 12:24:10 +0100 Julien Thierry wrote: Hi Bjorn, On 06/10/17 23:24, Bjorn Helgaas wrote: From: Bjorn Helgaas Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is behind a bridge that

Re: [PATCH 1/2] vgaarb: Select a default VGA device even if there's no legacy VGA

Hi Bjorn, On 06/10/17 23:24, Bjorn Helgaas wrote: From: Bjorn Helgaas Daniel Axtens reported that on the HiSilicon D05 board, the VGA device is behind a bridge that doesn't support PCI_BRIDGE_CTL_VGA, so the VGA arbiter never selects it as the default, which means Xorg

Re: [PATCH v2] KVM: PPC: Book3S PR: only install valid SLBs during KVM_SET_SREGS

Ping ? On Mon, 02 Oct 2017 10:40:22 +0200 Greg Kurz wrote: > Userland passes an array of 64 SLB descriptors to KVM_SET_SREGS, > some of which are valid (ie, SLB_ESID_V is set) and the rest are > likely all-zeroes (with QEMU at least). > > Each of them is then passed to

[PATCH V2] powerpc/perf: Fix IMC initialization crash

Call trace observed with latest firmware, and upstream kernel. [ 14.499938] NIP [c00f318c] init_imc_pmu+0x8c/0xcf0 [ 14.499973] LR [c00f33f8] init_imc_pmu+0x2f8/0xcf0 [ 14.57] Call Trace: [ 14.500027] [c03fed18f710] [c00f33c8] init_imc_pmu+0x2c8/0xcf0