1. 21 4月, 2016 1 次提交
    • M
      s390/fpu: allocate 'struct fpu' with the task_struct · 3f6813b9
      Martin Schwidefsky 提交于
      Analog to git commit 0c8c0f03
      "x86/fpu, sched: Dynamically allocate 'struct fpu'"
      move the struct fpu to the end of the struct thread_struct,
      set CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT and add the
      setup_task_size() function to calculate the correct size
      fo the task struct.
      
      For the performance_defconfig this increases the size of
      struct task_struct from 7424 bytes to 7936 bytes (MACHINE_HAS_VX==1)
      or 7552 bytes (MACHINE_HAS_VX==0). The dynamic allocation of the
      struct fpu is removed. The slab cache uses an 8KB block for the
      task struct in all cases, there is enough room for the struct fpu.
      For MACHINE_HAS_VX==1 each task now needs 512 bytes less memory.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3f6813b9
  2. 23 2月, 2016 2 次提交
    • H
      s390/dumpstack: merge all four stack tracers · 758d39eb
      Heiko Carstens 提交于
      We have four different stack tracers of which three had bugs. So it's
      time to merge them to a single stack tracer which allows to specify a
      call back function which will be called for each step.
      
      This patch changes behavior a bit:
      
      - the "nosched" and "in_sched_functions" check within
        save_stack_trace_tsk did work only for the last stack frame within a
        context. Now it considers the check for each stack frame like it
        should.
      
      - both the oprofile variant and the perf_events variant did save a
        return address twice if a zero back chain was detected, which
        indicates an interrupt frame. The new dump_trace function will call
        the oprofile and perf_events backends with the psw address that is
        contained within the corresponding pt_regs structure instead.
      
      - the original show_trace and save_context_stack functions did already
        use the psw address of the pt_regs structure if a zero back chain
        was detected. However now we ignore the psw address if it is a user
        space address. After all we trace the kernel stack and not the user
        space stack. This way we also get rid of the garbage user space
        address in case of warnings and / or panic call traces.
      
      So this should make life easier since now there is only one stack
      tracer left which we can break.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      758d39eb
    • H
      s390: add current_stack_pointer() helper function · 76737ce1
      Heiko Carstens 提交于
      Implement current_stack_pointer() helper function and use it
      everywhere, instead of having several different inline assembly
      variants.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Tested-by: NPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      76737ce1
  3. 19 1月, 2016 1 次提交
  4. 11 1月, 2016 1 次提交
  5. 27 11月, 2015 1 次提交
  6. 03 11月, 2015 1 次提交
  7. 27 10月, 2015 2 次提交
  8. 16 10月, 2015 1 次提交
  9. 14 10月, 2015 4 次提交
  10. 29 7月, 2015 1 次提交
  11. 22 7月, 2015 3 次提交
    • H
      s390/kernel: lazy restore fpu registers · 9977e886
      Hendrik Brueckner 提交于
      Improve the save and restore behavior of FPU register contents to use the
      vector extension within the kernel.
      
      The kernel does not use floating-point or vector registers and, therefore,
      saving and restoring the FPU register contents are performed for handling
      signals or switching processes only.  To prepare for using vector
      instructions and vector registers within the kernel, enhance the save
      behavior and implement a lazy restore at return to user space from a
      system call or interrupt.
      
      To implement the lazy restore, the save_fpu_regs() sets a CPU information
      flag, CIF_FPU, to indicate that the FPU registers must be restored.
      Saving and setting CIF_FPU is performed in an atomic fashion to be
      interrupt-safe.  When the kernel wants to use the vector extension or
      wants to change the FPU register state for a task during signal handling,
      the save_fpu_regs() must be called first.  The CIF_FPU flag is also set at
      process switch.  At return to user space, the FPU state is restored.  In
      particular, the FPU state includes the floating-point or vector register
      contents, as well as, vector-enablement and floating-point control.  The
      FPU state restore and clearing CIF_FPU is also performed in an atomic
      fashion.
      
      For KVM, the restore of the FPU register state is performed when restoring
      the general-purpose guest registers before the SIE instructions is started.
      Because the path towards the SIE instruction is interruptible, the CIF_FPU
      flag must be checked again right before going into SIE.  If set, the guest
      registers must be reloaded again by re-entering the outer SIE loop.  This
      is the same behavior as if the SIE critical section is interrupted.
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      9977e886
    • H
      s390/kernel: introduce fpu-internal.h with fpu helper functions · 904818e2
      Hendrik Brueckner 提交于
      Introduce a new structure to manage FP and VX registers. Refactor the
      save and restore of floating point and vector registers with a set
      of helper functions in fpu-internal.h.
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      904818e2
    • H
      s390/kernel: move EX_TABLE macros to linkage.h header file · 2e54dc3c
      Hendrik Brueckner 提交于
      Move the EX_TABLE macro definitions from the processor.h to the linkage.h
      header file.  It helps to reduce circular header file dependencies.
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2e54dc3c
  12. 25 3月, 2015 1 次提交
    • H
      s390: remove 31 bit support · 5a79859a
      Heiko Carstens 提交于
      Remove the 31 bit support in order to reduce maintenance cost and
      effectively remove dead code. Since a couple of years there is no
      distribution left that comes with a 31 bit kernel.
      
      The 31 bit kernel also has been broken since more than a year before
      anybody noticed. In addition I added a removal warning to the kernel
      shown at ipl for 5 minutes: a960062e ("s390: add 31 bit warning
      message") which let everybody know about the plan to remove 31 bit
      code. We didn't get any response.
      
      Given that the last 31 bit only machine was introduced in 1999 let's
      remove the code.
      Anybody with 31 bit user space code can still use the compat mode.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a79859a
  13. 29 1月, 2015 1 次提交
  14. 28 11月, 2014 1 次提交
  15. 09 10月, 2014 3 次提交
  16. 17 7月, 2014 1 次提交
    • D
      arch, locking: Ciao arch_mutex_cpu_relax() · 3a6bfbc9
      Davidlohr Bueso 提交于
      The arch_mutex_cpu_relax() function, introduced by 34b133f8, is
      hacky and ugly. It was added a few years ago to address the fact
      that common cpu_relax() calls include yielding on s390, and thus
      impact the optimistic spinning functionality of mutexes. Nowadays
      we use this function well beyond mutexes: rwsem, qrwlock, mcs and
      lockref. Since the macro that defines the call is in the mutex header,
      any users must include mutex.h and the naming is misleading as well.
      
      This patch (i) renames the call to cpu_relax_lowlatency  ("relax, but
      only if you can do it with very low latency") and (ii) defines it in
      each arch's asm/processor.h local header, just like for regular cpu_relax
      functions. On all archs, except s390, cpu_relax_lowlatency is simply cpu_relax,
      and thus we can take it out of mutex.h. While this can seem redundant,
      I believe it is a good choice as it allows us to move out arch specific
      logic from generic locking primitives and enables future(?) archs to
      transparently define it, similarly to System Z.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharat Bhushan <r65777@freescale.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Joseph Myers <joseph@codesourcery.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Qiaowei Ren <qiaowei.ren@intel.com>
      Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Stratos Karafotis <stratosk@semaphore.gr>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Kulikov <segoon@openwall.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: adi-buildroot-devel@lists.sourceforge.net
      Cc: linux390@de.ibm.com
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-cris-kernel@axis.com
      Cc: linux-hexagon@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux@lists.openrisc.net
      Cc: linux-m32r-ja@ml.linux-m32r.org
      Cc: linux-m32r@ml.linux-m32r.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-metag@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: sparclinux@vger.kernel.org
      Link: http://lkml.kernel.org/r/1404079773.2619.4.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3a6bfbc9
  17. 20 5月, 2014 1 次提交
  18. 30 1月, 2014 1 次提交
  19. 04 11月, 2013 1 次提交
    • M
      s390/mm,tlb: correct tlb flush on page table upgrade · 10607864
      Martin Schwidefsky 提交于
      The IDTE instruction used to flush TLB entries for a specific address
      space uses the address-space-control element (ASCE) to identify
      affected TLB entries. The upgrade of a page table adds a new top
      level page table which changes the ASCE. The TLB entries associated
      with the old ASCE need to be flushed and the ASCE for the address space
      needs to be replaced synchronously on all CPUs which currently use it.
      The concept of a lazy ASCE update with an exception handler is broken.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      10607864
  20. 24 10月, 2013 3 次提交
  21. 28 9月, 2013 1 次提交
  22. 29 7月, 2013 1 次提交
  23. 16 7月, 2013 1 次提交
  24. 17 4月, 2013 1 次提交
  25. 01 10月, 2012 2 次提交
  26. 26 9月, 2012 3 次提交
    • H
      s390/exceptions: switch to relative exception table entries · eb608fb3
      Heiko Carstens 提交于
      This is the s390 port of 70627654 "x86, extable: Switch to relative
      exception table entries".
      Reduces the size of our exception tables by 50% on 64 bit builds.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      eb608fb3
    • H
      s390/cache: add cpu cache information to /proc/cpuinfo · 6668022c
      Heiko Carstens 提交于
      Add a line for each cpu cache to /proc/cpuinfo.
      Since we only have information of private cpu caches in sysfs we
      add a line for each cpu cache in /proc/cpuinfo which will also
      contain information about shared caches.
      
      For a z196 machine /proc/cpuinfo now looks like:
      
      vendor_id       : IBM/S390
      bogomips per cpu: 14367.00
      features        : esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs
      cache0          : level=1 type=Data scope=Private size=64K line_size=256 associativity=4
      cache1          : level=1 type=Instruction scope=Private size=128K line_size=256 associativity=8
      cache2          : level=2 type=Unified scope=Private size=1536K line_size=256 associativity=12
      cache3          : level=3 type=Unified scope=Shared size=24576K line_size=256 associativity=12
      cache4          : level=4 type=Unified scope=Shared size=196608K line_size=256 associativity=24
      processor 0: version = FF,  identification = 000123,  machine = 2817
      processor 1: version = FF,  identification = 100123,  machine = 2817
      processor 2: version = FF,  identification = 200123,  machine = 2817
      processor 3: version = FF,  identification = 200123,  machine = 2817
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6668022c
    • M
      s390: add support for transactional memory · d35339a4
      Martin Schwidefsky 提交于
      Allow user-space processes to use transactional execution (TX).
      If the TX facility is available user space programs can use
      transactions for fine-grained serialization based on the data
      objects that are referenced during a transaction. This is
      useful for lockless data structures and speculative compiler
      optimizations.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      d35339a4