1. 10 3月, 2017 2 次提交
  2. 06 3月, 2017 6 次提交
    • M
      powerpc: Sort the selects under CONFIG_PPC · a7d2475a
      Michael Ellerman 提交于
      We have a big list of selects under CONFIG_PPC, and currently they're
      completely unsorted. This means people tend to add new selects at the
      bottom of the list, and so two commits which both add a new select will
      often conflict.
      
      Instead sort it alphabetically. This is nicer in and of itself, but also
      means two commits that add a new select will have a greater chance of
      not conflicting.
      
      Add a note at the top and bottom asking people to keep it sorted.
      
      And while we're here pad out the 'if' expressions to make them stand
      out.
      Suggested-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a7d2475a
    • M
      powerpc/64: Fix L1D cache shape vector reporting L1I values · 9c7a0086
      Michael Ellerman 提交于
      It seems we didn't pay quite enough attention when testing the new cache
      shape vectors, which means we didn't notice the bug where the vector for
      the L1D was using the L1I values. Fix it, resulting in eg:
      
        L1I  cache size:     0x8000      32768B         32K
        L1I  line size:        0x80       8-way associative
        L1D  cache size:    0x10000      65536B         64K
        L1D  line size:        0x80       8-way associative
      
      Fixes: 98a5f361 ("powerpc: Add new cache geometry aux vectors")
      Cut-and-paste-bug-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Badly-reviewed-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      9c7a0086
    • A
      powerpc/64: Avoid panic during boot due to divide by zero in init_cache_info() · 6ba422c7
      Anton Blanchard 提交于
      I see a panic in early boot when building with a recent gcc toolchain.
      The issue is a divide by zero, which is undefined. Older toolchains
      let us get away with it:
      
      int foo(int a) { return a / 0; }
      
      foo:
      	li 9,0
      	divw 3,3,9
      	extsw 3,3
      	blr
      
      But newer ones catch it:
      
      foo:
      	trap
      
      Add a check to avoid the divide by zero.
      
      Fixes: e2827fe5 ("powerpc/64: Clean up ppc64_caches using a struct per cache")
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      6ba422c7
    • S
      powerpc: Update to new option-vector-5 format for CAS · 014d02cb
      Suraj Jitindar Singh 提交于
      On POWER9 the ibm,client-architecture-support (CAS) negotiation process
      has been updated to change how the host to guest negotiation is done for
      the new hash/radix mmu as well as the nest mmu, process tables and guest
      translation shootdown (GTSE).
      
      This is documented in the unreleased PAPR ACR "CAS option vector
      additions for P9".
      
      The host tells the guest which options it supports in
      ibm,arch-vec-5-platform-support. The guest then chooses a subset of these
      to request in the CAS call and these are agreed to in the
      ibm,architecture-vec-5 property of the chosen node.
      
      Thus we read ibm,arch-vec-5-platform-support and make our selection before
      calling CAS. We then parse the ibm,architecture-vec-5 property of the
      chosen node to check whether we should run as hash or radix.
      
      ibm,arch-vec-5-platform-support format:
      
      index value pairs: <index, val> ... <index, val>
      
      index: Option vector 5 byte number
      val:   Some representation of supported values
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Acked-by: NPaul Mackerras <paulus@ozlabs.org>
      [mpe: Don't print about unknown options, be consistent with OV5_FEAT]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      014d02cb
    • S
      powerpc: Parse the command line before calling CAS · 12cc9fd6
      Suraj Jitindar Singh 提交于
      On POWER9 the hypervisor requires the guest to decide whether it would
      like to use a hash or radix mmu model at the time it calls
      ibm,client-architecture-support (CAS) based on what the hypervisor has
      said it's allowed to do. It is possible to disable radix by passing
      "disable_radix" on the command line. The next patch will add support for
      the new CAS format, thus we need to parse the command line before calling
      CAS so we can correctly select which mmu we would like to use.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Reviewed-by: NPaul Mackerras <paulus@ozlabs.org>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      12cc9fd6
    • B
      powerpc/xics: Work around limitations of OPAL XICS priority handling · a69e2fb7
      Balbir Singh 提交于
      The CPPR (Current Processor Priority Register) of a XICS interrupt
      presentation controller contains a value N, such that only interrupts
      with a priority "more favoured" than N will be received by the CPU,
      where "more favoured" means "less than". So if the CPPR has the value 5
      then only interrupts with a priority of 0-4 inclusive will be received.
      
      In theory the CPPR can support a value of 0 to 255 inclusive.
      In practice Linux only uses values of 0, 4, 5 and 0xff. Setting the CPPR
      to 0 rejects all interrupts, setting it to 0xff allows all interrupts.
      The values 4 and 5 are used to differentiate IPIs from external
      interrupts. Setting the CPPR to 5 allows IPIs to be received but not
      external interrupts.
      
      The CPPR emulation in the OPAL XICS implementation only directly
      supports priorities 0 and 0xff. All other priorities are considered
      equivalent, and mapped to a single priority value internally. This means
      when using icp-opal we can not allow IPIs but not externals.
      
      This breaks Linux's use of priority values when a CPU is hot unplugged.
      After migrating IRQs away from the CPU that is being offlined, we set
      the priority to 5, meaning we still want the offline CPU to receive
      IPIs. But the effect of the OPAL XICS emulation's use of a single
      priority value is that all interrupts are rejected by the CPU. With the
      CPU offline, and not receiving IPIs, we may not be able to wake it up to
      bring it back online.
      
      The first part of the fix is in icp_opal_set_cpu_priority(). CPPR values
      of 0 to 4 inclusive will correctly cause all interrupts to be rejected,
      so we pass those CPPR values through to OPAL. However if we are called
      with a CPPR of 5 or greater, the caller is expecting to be able to allow
      IPIs but not external interrupts. We know this doesn't work, so instead
      of rejecting all interrupts we choose the opposite which is to allow all
      interrupts. This is still not correct behaviour, but we know for the
      only existing caller (xics_migrate_irqs_away()), that it is the better
      option.
      
      The other part of the fix is in xics_migrate_irqs_away(). Instead of
      setting priority (CPPR) to 0, and then back to 5 before migrating IRQs,
      we migrate the IRQs before setting the priority back to 5. This should
      have no effect on an ICP backend with a working set_priority(), and on
      icp-opal it means we will keep all interrupts blocked until after we've
      finished doing the IRQ migration. Additionally we wait for 5ms after
      doing the migration to make sure there are no IRQs in flight.
      
      Fixes: d7436188 ("powerpc/xics: Add ICP OPAL backend")
      Cc: stable@vger.kernel.org # v4.8+
      Suggested-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reported-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Tested-by: NVaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NBalbir Singh <bsingharora@gmail.com>
      [mpe: Rewrote comments and change log, change delay to 5ms]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      a69e2fb7
  3. 04 3月, 2017 2 次提交
  4. 03 3月, 2017 7 次提交
    • I
      sched/headers: Move task->mm handling methods to <linux/sched/mm.h> · 68e21be2
      Ingo Molnar 提交于
      Move the following task->mm helper APIs into a new header file,
      <linux/sched/mm.h>, to further reduce the size and complexity
      of <linux/sched.h>.
      
      Here are how the APIs are used in various kernel files:
      
        # mm_alloc():
        arch/arm/mach-rpc/ecard.c
        fs/exec.c
        include/linux/sched/mm.h
        kernel/fork.c
      
        # __mmdrop():
        arch/arc/include/asm/mmu_context.h
        include/linux/sched/mm.h
        kernel/fork.c
      
        # mmdrop():
        arch/arm/mach-rpc/ecard.c
        arch/m68k/sun3/mmu_emu.c
        arch/x86/mm/tlb.c
        drivers/gpu/drm/amd/amdkfd/kfd_process.c
        drivers/gpu/drm/i915/i915_gem_userptr.c
        drivers/infiniband/hw/hfi1/file_ops.c
        drivers/vfio/vfio_iommu_spapr_tce.c
        fs/exec.c
        fs/proc/base.c
        fs/proc/task_mmu.c
        fs/proc/task_nommu.c
        fs/userfaultfd.c
        include/linux/mmu_notifier.h
        include/linux/sched/mm.h
        kernel/fork.c
        kernel/futex.c
        kernel/sched/core.c
        mm/khugepaged.c
        mm/ksm.c
        mm/mmu_context.c
        mm/mmu_notifier.c
        mm/oom_kill.c
        virt/kvm/kvm_main.c
      
        # mmdrop_async_fn():
        include/linux/sched/mm.h
      
        # mmdrop_async():
        include/linux/sched/mm.h
        kernel/fork.c
      
        # mmget_not_zero():
        fs/userfaultfd.c
        include/linux/sched/mm.h
        mm/oom_kill.c
      
        # mmput():
        arch/arc/include/asm/mmu_context.h
        arch/arc/kernel/troubleshoot.c
        arch/frv/mm/mmu-context.c
        arch/powerpc/platforms/cell/spufs/context.c
        arch/sparc/include/asm/mmu_context_32.h
        drivers/android/binder.c
        drivers/gpu/drm/etnaviv/etnaviv_gem.c
        drivers/gpu/drm/i915/i915_gem_userptr.c
        drivers/infiniband/core/umem.c
        drivers/infiniband/core/umem_odp.c
        drivers/infiniband/core/uverbs_main.c
        drivers/infiniband/hw/mlx4/main.c
        drivers/infiniband/hw/mlx5/main.c
        drivers/infiniband/hw/usnic/usnic_uiom.c
        drivers/iommu/amd_iommu_v2.c
        drivers/iommu/intel-svm.c
        drivers/lguest/lguest_user.c
        drivers/misc/cxl/fault.c
        drivers/misc/mic/scif/scif_rma.c
        drivers/oprofile/buffer_sync.c
        drivers/vfio/vfio_iommu_type1.c
        drivers/vhost/vhost.c
        drivers/xen/gntdev.c
        fs/exec.c
        fs/proc/array.c
        fs/proc/base.c
        fs/proc/task_mmu.c
        fs/proc/task_nommu.c
        fs/userfaultfd.c
        include/linux/sched/mm.h
        kernel/cpuset.c
        kernel/events/core.c
        kernel/events/uprobes.c
        kernel/exit.c
        kernel/fork.c
        kernel/ptrace.c
        kernel/sys.c
        kernel/trace/trace_output.c
        kernel/tsacct.c
        mm/memcontrol.c
        mm/memory.c
        mm/mempolicy.c
        mm/migrate.c
        mm/mmu_notifier.c
        mm/nommu.c
        mm/oom_kill.c
        mm/process_vm_access.c
        mm/rmap.c
        mm/swapfile.c
        mm/util.c
        virt/kvm/async_pf.c
      
        # mmput_async():
        include/linux/sched/mm.h
        kernel/fork.c
        mm/oom_kill.c
      
        # get_task_mm():
        arch/arc/kernel/troubleshoot.c
        arch/powerpc/platforms/cell/spufs/context.c
        drivers/android/binder.c
        drivers/gpu/drm/etnaviv/etnaviv_gem.c
        drivers/infiniband/core/umem.c
        drivers/infiniband/core/umem_odp.c
        drivers/infiniband/hw/mlx4/main.c
        drivers/infiniband/hw/mlx5/main.c
        drivers/infiniband/hw/usnic/usnic_uiom.c
        drivers/iommu/amd_iommu_v2.c
        drivers/iommu/intel-svm.c
        drivers/lguest/lguest_user.c
        drivers/misc/cxl/fault.c
        drivers/misc/mic/scif/scif_rma.c
        drivers/oprofile/buffer_sync.c
        drivers/vfio/vfio_iommu_type1.c
        drivers/vhost/vhost.c
        drivers/xen/gntdev.c
        fs/proc/array.c
        fs/proc/base.c
        fs/proc/task_mmu.c
        include/linux/sched/mm.h
        kernel/cpuset.c
        kernel/events/core.c
        kernel/exit.c
        kernel/fork.c
        kernel/ptrace.c
        kernel/sys.c
        kernel/trace/trace_output.c
        kernel/tsacct.c
        mm/memcontrol.c
        mm/memory.c
        mm/mempolicy.c
        mm/migrate.c
        mm/mmu_notifier.c
        mm/nommu.c
        mm/util.c
      
        # mm_access():
        fs/proc/base.c
        include/linux/sched/mm.h
        kernel/fork.c
        mm/process_vm_access.c
      
        # mm_release():
        arch/arc/include/asm/mmu_context.h
        fs/exec.c
        include/linux/sched/mm.h
        include/uapi/linux/sched.h
        kernel/exit.c
        kernel/fork.c
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      68e21be2
    • L
      powerpc/booke: Fix boot crash due to null hugepd · 3fb66a70
      Laurentiu Tudor 提交于
      On 32-bit book-e machines, hugepd_ok() no longer takes into account null
      hugepd values, causing this crash at boot:
      
        Unable to handle kernel paging request for data at address 0x80000000
        ...
        NIP [c0018378] follow_huge_addr+0x38/0xf0
        LR [c001836c] follow_huge_addr+0x2c/0xf0
        Call Trace:
         follow_huge_addr+0x2c/0xf0 (unreliable)
         follow_page_mask+0x40/0x3e0
         __get_user_pages+0xc8/0x450
         get_user_pages_remote+0x8c/0x250
         copy_strings+0x110/0x390
         copy_strings_kernel+0x2c/0x50
         do_execveat_common+0x478/0x630
         do_execve+0x2c/0x40
         try_to_run_init_process+0x18/0x60
         kernel_init+0xbc/0x110
         ret_from_kernel_thread+0x5c/0x64
      
      This impacts all nxp (ex-freescale) 32-bit booke platforms.
      
      This was caused by the change of hugepd_t.pd from signed to unsigned,
      and the update to the nohash version of hugepd_ok(). Previously
      hugepd_ok() could exclude all non-huge and NULL pgds using > 0, whereas
      now we need to explicitly check that the value is not zero and also that
      PD_HUGE is *clear*.
      
      This isn't protected by the pgd_none() check in __find_linux_pte_or_hugepte()
      because on 32-bit we use pgtable-nopud.h, which causes the pgd_none()
      check to be always false.
      
      Fixes: 20717e1f ("powerpc/mm: Fix little-endian 4K hugetlb")
      Cc: stable@vger.kernel.org # v4.7+
      Reported-by: NMadalin-Cristian Bucur <madalin.bucur@nxp.com>
      Signed-off-by: NLaurentiu Tudor <laurentiu.tudor@nxp.com>
      [mpe: Flesh out change log details.]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      3fb66a70
    • N
      powerpc: Fix compiling a BE kernel with a powerpc64le toolchain · 4dc831aa
      Nicholas Piggin 提交于
      GCC can compile with either endian, but the default ABI version is set
      based on the default endianness of the toolchain. Alan Modra says:
      
        you need both -mbig and -mabi=elfv1 to make a powerpc64le gcc
        generate powerpc64 code
      
      The opposite is true for powerpc64 when generating -mlittle it
      requires -mabi=elfv2 to generate v2 ABI, which we were already doing.
      
      This change adds ABI annotations together with endianness for all cases,
      LE and BE. This fixes the case of building a BE kernel with a toolchain
      that is LE by default.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Tested-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4dc831aa
    • G
      powerpc/powernv: Fix bug due to labeling ambiguity in power_enter_stop · 424f8acd
      Gautham R. Shenoy 提交于
      Commit 09206b60 ("powernv: Pass PSSCR value and mask to
      power9_idle_stop") added additional code in power_enter_stop() to
      distinguish between stop requests whose PSSCR had ESL=EC=1 from those
      which did not. When ESL=EC=1, we do a forward-jump to a location
      labelled by "1", which had the code to handle the ESL=EC=1 case.
      
      Unfortunately just a couple of instructions before this label, is the
      macro IDLE_STATE_ENTER_SEQ() which also has a label "1" in its
      expansion.
      
      As a result, the current code can result in directly executing stop
      instruction for deep stop requests with PSSCR ESL=EC=1, without saving
      the hypervisor state.
      
      Fix this BUG by labeling the location that handles ESL=EC=1 case with
      a more descriptive label ".Lhandle_esl_ec_set" (local label suggestion
      a la .Lxx from Anton Blanchard).
      
      While at it, rename the label "2" labelling the location of the code
      handling entry into deep stop states with ".Lhandle_deep_stop".
      
      For a good measure, change the label in IDLE_STATE_ENTER_SEQ() macro
      to an not-so commonly used value in order to avoid similar mishaps in
      the future.
      
      Fixes: 09206b60 ("powernv: Pass PSSCR value and mask to power9_idle_stop")
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      424f8acd
    • P
      powerpc/64: Invalidate process table caching after setting process table · 7a70d728
      Paul Mackerras 提交于
      The POWER9 MMU reads and caches entries from the process table.
      When we kexec from one kernel to another, the second kernel sets
      its process table pointer but doesn't currently do anything to
      make the CPU invalidate any cached entries from the old process table.
      This adds a tlbie (TLB invalidate entry) instruction with parameters
      to invalidate caching of the process table after the new process
      table is installed.
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7a70d728
    • R
      powerpc: emulate_step() tests for load/store instructions · 4ceae137
      Ravi Bangoria 提交于
      Add new selftest that test emulate_step for Normal, Floating Point,
      Vector and Vector Scalar - load/store instructions. Test should run
      at boot time if CONFIG_KPROBES_SANITY_TEST and CONFIG_PPC64 is set.
      
      Sample log:
      
        emulate_step_test: ld             : PASS
        emulate_step_test: lwz            : PASS
        emulate_step_test: lwzx           : PASS
        emulate_step_test: std            : PASS
        emulate_step_test: ldarx / stdcx. : PASS
        emulate_step_test: lfsx           : PASS
        emulate_step_test: stfsx          : PASS
        emulate_step_test: lfdx           : PASS
        emulate_step_test: stfdx          : PASS
        emulate_step_test: lvx            : PASS
        emulate_step_test: stvx           : PASS
        emulate_step_test: lxvd2x         : PASS
        emulate_step_test: stxvd2x        : PASS
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      [mpe: Drop start/complete lines, make it all __init]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      4ceae137
    • R
      powerpc: Emulation support for load/store instructions on LE · e148bd17
      Ravi Bangoria 提交于
      emulate_step() uses a number of underlying kernel functions that were
      initially not enabled for LE. This has been rectified since. So, fix
      emulate_step() for LE for the corresponding instructions.
      
      Cc: stable@vger.kernel.org # v3.18+
      Reported-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      e148bd17
  5. 02 3月, 2017 18 次提交
  6. 01 3月, 2017 3 次提交
    • A
      perf/core: Rename CONFIG_[UK]PROBE_EVENT to CONFIG_[UK]PROBE_EVENTS · 6b0b7551
      Anton Blanchard 提交于
      We have uses of CONFIG_UPROBE_EVENT and CONFIG_KPROBE_EVENT as
      well as CONFIG_UPROBE_EVENTS and CONFIG_KPROBE_EVENTS.
      
      Consistently use the plurals.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@kernel.org
      Cc: alexander.shishkin@linux.intel.com
      Cc: davem@davemloft.net
      Cc: sparclinux@vger.kernel.org
      Link: http://lkml.kernel.org/r/20170216060050.20866-1-anton@ozlabs.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6b0b7551
    • P
      KVM: PPC: Book3S HV: Don't use ASDR for real-mode HPT faults on POWER9 · 4e5acdc2
      Paul Mackerras 提交于
      In HPT mode on POWER9, the ASDR register is supposed to record
      segment information for hypervisor page faults.  It turns out that
      POWER9 DD1 does not record the page size information in the ASDR
      for faults in guest real mode.  We have the necessary information
      in memory already, so by moving the checks for real mode that already
      existed, we can use the in-memory copy.  Since a load is likely to
      be faster than reading an SPR, we do this unconditionally (not just
      for POWER9 DD1).
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      4e5acdc2
    • P
      KVM: PPC: Book3S HV: Fix software walk of guest process page tables · 70cd4c10
      Paul Mackerras 提交于
      This fixes some bugs in the code that walks the guest's page tables.
      These bugs cause MMIO emulation to fail whenever the guest is in
      virtial mode (MMU on), leading to the guest hanging if it tried to
      access a virtio device.
      
      The first bug was that when reading the guest's process table, we were
      using the whole of arch->process_table, not just the field that contains
      the process table base address.  The second bug was that the mask used
      when reading the process table entry to get the radix tree base address,
      RPDB_MASK, had the wrong value.
      
      Fixes: 9e04ba69 ("KVM: PPC: Book3S HV: Add basic infrastructure for radix guests")
      Fixes: e9983344 ("powerpc/mm/radix: Add partition table format & callback")
      Signed-off-by: NPaul Mackerras <paulus@ozlabs.org>
      70cd4c10
  7. 28 2月, 2017 2 次提交