1. 01 12月, 2015 3 次提交
    • A
      powerpc: Don't disable MSR bits in do_load_up_transact_*() functions · af72ab64
      Anton Blanchard 提交于
      Similar to the non TM load_up_*() functions, don't disable the MSR
      bits on the way out.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      af72ab64
    • A
      powerpc: Don't disable kernel FP/VMX/VSX MSR bits on context switch · 07e45c12
      Anton Blanchard 提交于
      Writing the MSR is slow, so we want to avoid it whenever possible.
      
      A subsequent patch will add a debug option that strictly manages the
      FP/VMX/VSX unavailable bits. For now just remove it, matching what
      we do in other areas of the kernel (eg enable_kernel_altivec()).
      
      A context switch microbenchmark using yield():
      
      http://ozlabs.org/~anton/junkcode/context_switch2.c
      
      ./context_switch2 --test=yield --fp 0 0
      
      shows an improvement of almost 3% on POWER8.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      07e45c12
    • P
      powerpc/64: Include KVM guest test in all interrupt vectors · 31a40e2b
      Paul Mackerras 提交于
      Currently, if HV KVM is configured but PR KVM isn't, we don't include
      a test to see whether we were interrupted in KVM guest context for the
      set of interrupts which get delivered directly to the guest by hardware
      if they occur in the guest.  This includes things like program
      interrupts.
      
      However, the recent bug where userspace could set the MSR for a VCPU
      to have an illegal value in the TS field, and thus cause a TM Bad Thing
      type of program interrupt on the hrfid that enters the guest, showed that
      we can never be completely sure that these interrupts can never occur
      in the guest entry/exit code.  If one of these interrupts does happen
      and we have HV KVM configured but not PR KVM, then we end up trying to
      run the handler in the host with the MMU set to the guest MMU context,
      which generally ends badly.
      
      Thus, for robustness it is better to have the test in every interrupt
      vector, so that if some way is found to trigger some interrupt in the
      guest entry/exit path, we can handle it without immediately crashing
      the host.
      
      This means that the distinction between KVMTEST and KVMTEST_PR goes
      away.  Thus we delete KVMTEST_PR and associated macros and use KVMTEST
      everywhere that we previously used either KVMTEST_PR or KVMTEST.  It
      also means that SOFTEN_TEST_HV_201 becomes the same as SOFTEN_TEST_PR,
      so we deleted SOFTEN_TEST_HV_201 and use SOFTEN_TEST_PR instead.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      31a40e2b
  2. 26 11月, 2015 6 次提交
  3. 24 11月, 2015 1 次提交
  4. 16 11月, 2015 1 次提交
  5. 10 11月, 2015 1 次提交
  6. 08 11月, 2015 1 次提交
  7. 06 11月, 2015 5 次提交
    • P
      KVM: PPC: Book3S HV: Don't dynamically split core when already split · f74f2e2e
      Paul Mackerras 提交于
      In static micro-threading modes, the dynamic micro-threading code
      is supposed to be disabled, because subcores can't make independent
      decisions about what micro-threading mode to put the core in - there is
      only one micro-threading mode for the whole core.  The code that
      implements dynamic micro-threading checks for this, except that the
      check was missed in one case.  This means that it is possible for a
      subcore in static 2-way micro-threading mode to try to put the core
      into 4-way micro-threading mode, which usually leads to stuck CPUs,
      spinlock lockups, and other stalls in the host.
      
      The problem was in the can_split_piggybacked_subcores() function, which
      should always return false if the system is in a static micro-threading
      mode.  This fixes the problem by making can_split_piggybacked_subcores()
      use subcore_config_ok() for its checks, as subcore_config_ok() includes
      the necessary check for the static micro-threading modes.
      
      Credit to Gautham Shenoy for working out that the reason for the hangs
      and stalls we were seeing was that we were trying to do dynamic 4-way
      micro-threading while we were in static 2-way mode.
      
      Fixes: b4deba5c
      Cc: vger@stable.kernel.org # v4.3
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f74f2e2e
    • P
      KVM: PPC: Book3S HV: Synthesize segment fault if SLB lookup fails · cf29b215
      Paul Mackerras 提交于
      When handling a hypervisor data or instruction storage interrupt (HDSI
      or HISI), we look up the SLB entry for the address being accessed in
      order to translate the effective address to a virtual address which can
      be looked up in the guest HPT.  This lookup can occasionally fail due
      to the guest replacing an SLB entry without invalidating the evicted
      SLB entry.  In this situation an ERAT (effective to real address
      translation cache) entry can persist and be used by the hardware even
      though there is no longer a corresponding SLB entry.
      
      Previously we would just deliver a data or instruction storage interrupt
      (DSI or ISI) to the guest in this case.  However, this is not correct
      and has been observed to cause guests to crash, typically with a
      data storage protection interrupt on a store to the vmemmap area.
      
      Instead, what we do now is to synthesize a data or instruction segment
      interrupt.  That should cause the guest to reload an appropriate entry
      into the SLB and retry the faulting instruction.  If it still faults,
      we should find an appropriate SLB entry next time and be able to handle
      the fault.
      Tested-by: NThomas Huth <thuth@redhat.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cf29b215
    • E
      mm: mlock: add mlock flags to enable VM_LOCKONFAULT usage · b0f205c2
      Eric B Munson 提交于
      The previous patch introduced a flag that specified pages in a VMA should
      be placed on the unevictable LRU, but they should not be made present when
      the area is created.  This patch adds the ability to set this state via
      the new mlock system calls.
      
      We add MLOCK_ONFAULT for mlock2 and MCL_ONFAULT for mlockall.
      MLOCK_ONFAULT will set the VM_LOCKONFAULT modifier for VM_LOCKED.
      MCL_ONFAULT should be used as a modifier to the two other mlockall flags.
      When used with MCL_CURRENT, all current mappings will be marked with
      VM_LOCKED | VM_LOCKONFAULT.  When used with MCL_FUTURE, the mm->def_flags
      will be marked with VM_LOCKED | VM_LOCKONFAULT.  When used with both
      MCL_CURRENT and MCL_FUTURE, all current mappings and mm->def_flags will be
      marked with VM_LOCKED | VM_LOCKONFAULT.
      
      Prior to this patch, mlockall() will unconditionally clear the
      mm->def_flags any time it is called without MCL_FUTURE.  This behavior is
      maintained after adding MCL_ONFAULT.  If a call to mlockall(MCL_FUTURE) is
      followed by mlockall(MCL_CURRENT), the mm->def_flags will be cleared and
      new VMAs will be unlocked.  This remains true with or without MCL_ONFAULT
      in either mlockall() invocation.
      
      munlock() will unconditionally clear both vma flags.  munlockall()
      unconditionally clears for VMA flags on all VMAs and in the mm->def_flags
      field.
      Signed-off-by: NEric B Munson <emunson@akamai.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Acked-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Shuah Khan <shuahkh@osg.samsung.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b0f205c2
    • R
      arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes · c118baf8
      Raghavendra K T 提交于
      With the setup_nr_nodes(), we have already initialized
      node_possible_map.  So it is safe to use for_each_node here.
      
      There are many places in the kernel that use hardcoded 'for' loop with
      nr_node_ids, because all other architectures have numa nodes populated
      serially.  That should be reason we had maintained the same for
      powerpc.
      
      But, since sparse numa node ids possible on powerpc, we unnecessarily
      allocate memory for non existent numa nodes.
      
      For e.g., on a system with 0,1,16,17 as numa nodes nr_node_ids=18 and
      we allocate memory for nodes 2-14.  This patch we allocate memory for
      only existing numa nodes.
      
      The patch is boot tested on a 4 node tuleta, confirming with printks
      that it works as expected.
      Signed-off-by: NRaghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
      Cc: Vladimir Davydov <vdavydov@parallels.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
      Cc: Greg Kurz <gkurz@linux.vnet.ibm.com>
      Cc: Grant Likely <grant.likely@linaro.org>
      Cc: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c118baf8
    • A
      uaccess: reimplement probe_kernel_address() using probe_kernel_read() · 0ab32b6f
      Andrew Morton 提交于
      probe_kernel_address() is basically the same as the (later added)
      probe_kernel_read().
      
      The return value on EFAULT is a bit different: probe_kernel_address()
      returns number-of-bytes-not-copied whereas probe_kernel_read() returns
      -EFAULT.  All callers have been checked, none cared.
      
      probe_kernel_read() can be overridden by the architecture whereas
      probe_kernel_address() cannot.  parisc, blackfin and um do this, to insert
      additional checking.  Hence this patch possibly fixes obscure bugs,
      although there are only two probe_kernel_address() callsites outside
      arch/.
      
      My first attempt involved removing probe_kernel_address() entirely and
      converting all callsites to use probe_kernel_read() directly, but that got
      tiresome.
      
      This patch shrinks mm/slab_common.o by 218 bytes.  For a single
      probe_kernel_address() callsite.
      
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0ab32b6f
  8. 28 10月, 2015 22 次提交