1. 27 6月, 2017 1 次提交
  2. 22 3月, 2017 1 次提交
    • M
      s390: add a system call for guarded storage · 916cda1a
      Martin Schwidefsky 提交于
      This adds a new system call to enable the use of guarded storage for
      user space processes. The system call takes two arguments, a command
      and pointer to a guarded storage control block:
      
          s390_guarded_storage(int command, struct gs_cb *gs_cb);
      
      The second argument is relevant only for the GS_SET_BC_CB command.
      
      The commands in detail:
      
      0 - GS_ENABLE
          Enable the guarded storage facility for the current task. The
          initial content of the guarded storage control block will be
          all zeros. After the enablement the user space code can use
          load-guarded-storage-controls instruction (LGSC) to load an
          arbitrary control block. While a task is enabled the kernel
          will save and restore the current content of the guarded
          storage registers on context switch.
      1 - GS_DISABLE
          Disables the use of the guarded storage facility for the current
          task. The kernel will cease to save and restore the content of
          the guarded storage registers, the task specific content of
          these registers is lost.
      2 - GS_SET_BC_CB
          Set a broadcast guarded storage control block. This is called
          per thread and stores a specific guarded storage control block
          in the task struct of the current task. This control block will
          be used for the broadcast event GS_BROADCAST.
      3 - GS_CLEAR_BC_CB
          Clears the broadcast guarded storage control block. The guarded-
          storage control block is removed from the task struct that was
          established by GS_SET_BC_CB.
      4 - GS_BROADCAST
          Sends a broadcast to all thread siblings of the current task.
          Every sibling that has established a broadcast guarded storage
          control block will load this control block and will be enabled
          for guarded storage. The broadcast guarded storage control block
          is used up, a second broadcast without a refresh of the stored
          control block with GS_SET_BC_CB will not have any effect.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      916cda1a
  3. 02 3月, 2017 1 次提交
  4. 23 2月, 2017 2 次提交
  5. 17 2月, 2017 1 次提交
    • P
      s390: kernel: Audit and remove any unnecessary uses of module.h · 3994a52b
      Paul Gortmaker 提交于
      Historically a lot of these existed because we did not have
      a distinction between what was modular code and what was providing
      support to modules via EXPORT_SYMBOL and friends.  That changed
      when we forked out support for the latter into the export.h file.
      
      This means we should be able to reduce the usage of module.h
      in code that is obj-y Makefile or bool Kconfig.  The advantage
      in doing so is that module.h itself sources about 15 other headers;
      adding significantly to what we feed cpp, and it can obscure what
      headers we are effectively using.
      
      Since module.h was the source for init.h (for __init) and for
      export.h (for EXPORT_SYMBOL) we consider each change instance
      for the presence of either and replace as needed.  Build testing
      revealed some implicit header usage that was fixed up accordingly.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      3994a52b
  6. 14 12月, 2016 1 次提交
  7. 29 8月, 2016 1 次提交
    • M
      s390/nmi: improve revalidation of fpu / vector registers · 8f149ea6
      Martin Schwidefsky 提交于
      The machine check handler will do one of two things if the floating-point
      control, a floating point register or a vector register can not be
      revalidated:
      1) if the PSW indicates user mode the process is terminated
      2) if the PSW indicates kernel mode the system is stopped
      
      To unconditionally stop the system for 2) is incorrect.
      
      There are three possible outcomes if the floating-point control, a
      floating point register or a vector registers can not be revalidated:
      1) The kernel is inside a kernel_fpu_begin/kernel_fpu_end block and
         needs the register. The system is stopped.
      2) No active kernel_fpu_begin/kernel_fpu_end block and the CIF_CPU bit
         is not set. The user space process needs the register and is killed.
      3) No active kernel_fpu_begin/kernel_fpu_end block and the CIF_FPU bit
         is set. Neither the kernel nor the user space process needs the
         lost register. Just revalidate it and continue.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      8f149ea6
  8. 13 6月, 2016 1 次提交
  9. 27 10月, 2015 4 次提交
  10. 16 10月, 2015 1 次提交
  11. 14 10月, 2015 1 次提交
  12. 19 8月, 2015 1 次提交
  13. 22 7月, 2015 2 次提交
    • 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
  14. 13 7月, 2015 1 次提交
    • H
      s390/nmi: fix vector register corruption · cad49cfc
      Heiko Carstens 提交于
      If a machine check happens, the machine has the vector facility installed
      and the extended save area exists, the cpu will save vector register
      contents into the extended save area. This is regardless of control
      register 0 contents, which enables and disables the vector facility during
      runtime.
      
      On each machine check we should validate the vector registers. The current
      code however tries to validate the registers only if the running task is
      using vector registers in user space.
      
      However even the current code is broken and causes vector register
      corruption on machine checks, if user space uses them:
      the prefix area contains a pointer (absolute address) to the machine check
      extended save area. In order to save some space the save area was put into
      an unused area of the second prefix page.
      When validating vector register contents the code uses the absolute address
      of the extended save area, which is wrong. Due to prefixing the vector
      instructions will then access contents using absolute addresses instead
      of real addresses, where the machine stored the contents.
      
      If the above would work there is still the problem that register validition
      would only happen if user space uses vector registers. If kernel space uses
      them also, this may also lead to vector register content corruption:
      if the kernel makes use of vector instructions, but the current running
      user space context does not, the machine check handler will validate
      floating point registers instead of vector registers.
      Given the fact that writing to a floating point register may change the
      upper halve of the corresponding vector register, we also experience vector
      register corruption in this case.
      
      Fix all of these issues, and always validate vector registers on each
      machine check, if the machine has the vector facility installed and the
      extended save area is defined.
      
      Cc: <stable@vger.kernel.org> # 4.1+
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      cad49cfc
  15. 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
  16. 01 12月, 2014 1 次提交
  17. 09 10月, 2014 1 次提交
    • M
      s390: add support for vector extension · 80703617
      Martin Schwidefsky 提交于
      The vector extension introduces 32 128-bit vector registers and a set of
      instruction to operate on the vector registers.
      
      The kernel can control the use of vector registers for the problem state
      program with a bit in control register 0. Once enabled for a process the
      kernel needs to retain the content of the vector registers on context
      switch. The signal frame is extended to include the vector registers.
      Two new register sets NT_S390_VXRS_LOW and NT_S390_VXRS_HIGH are added
      to the regset interface for the debugger and core dumps.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      80703617
  18. 27 8月, 2014 1 次提交
    • C
      s390: Replace __get_cpu_var uses · eb7e7d76
      Christoph Lameter 提交于
      __get_cpu_var() is used for multiple purposes in the kernel source. One of
      them is address calculation via the form &__get_cpu_var(x).  This calculates
      the address for the instance of the percpu variable of the current processor
      based on an offset.
      
      Other use cases are for storing and retrieving data from the current
      processors percpu area.  __get_cpu_var() can be used as an lvalue when
      writing data or on the right side of an assignment.
      
      __get_cpu_var() is defined as :
      
      #define __get_cpu_var(var) (*this_cpu_ptr(&(var)))
      
      __get_cpu_var() always only does an address determination. However, store
      and retrieve operations could use a segment prefix (or global register on
      other platforms) to avoid the address calculation.
      
      this_cpu_write() and this_cpu_read() can directly take an offset into a
      percpu area and use optimized assembly code to read and write per cpu
      variables.
      
      This patch converts __get_cpu_var into either an explicit address
      calculation using this_cpu_ptr() or into a use of this_cpu operations that
      use the offset.  Thereby address calculations are avoided and less registers
      are used when code is generated.
      
      At the end of the patch set all uses of __get_cpu_var have been removed so
      the macro is removed too.
      
      The patch set includes passes over all arches as well. Once these operations
      are used throughout then specialized macros can be defined in non -x86
      arches as well in order to optimize per cpu access by f.e.  using a global
      register that may be set to the per cpu base.
      
      Transformations done to __get_cpu_var()
      
      1. Determine the address of the percpu instance of the current processor.
      
      	DEFINE_PER_CPU(int, y);
      	int *x = &__get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(&y);
      
      2. Same as #1 but this time an array structure is involved.
      
      	DEFINE_PER_CPU(int, y[20]);
      	int *x = __get_cpu_var(y);
      
          Converts to
      
      	int *x = this_cpu_ptr(y);
      
      3. Retrieve the content of the current processors instance of a per cpu
      variable.
      
      	DEFINE_PER_CPU(int, y);
      	int x = __get_cpu_var(y)
      
         Converts to
      
      	int x = __this_cpu_read(y);
      
      4. Retrieve the content of a percpu struct
      
      	DEFINE_PER_CPU(struct mystruct, y);
      	struct mystruct x = __get_cpu_var(y);
      
         Converts to
      
      	memcpy(&x, this_cpu_ptr(&y), sizeof(x));
      
      5. Assignment to a per cpu variable
      
      	DEFINE_PER_CPU(int, y)
      	__get_cpu_var(y) = x;
      
         Converts to
      
      	this_cpu_write(y, x);
      
      6. Increment/Decrement etc of a per cpu variable
      
      	DEFINE_PER_CPU(int, y);
      	__get_cpu_var(y)++
      
         Converts to
      
      	this_cpu_inc(y)
      
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      CC: linux390@de.ibm.com
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      eb7e7d76
  19. 20 5月, 2014 1 次提交
  20. 22 8月, 2013 1 次提交
  21. 14 2月, 2013 1 次提交
  22. 08 1月, 2013 1 次提交
    • H
      s390/irq: remove split irq fields from /proc/stat · 420f42ec
      Heiko Carstens 提交于
      Now that irq sum accounting for /proc/stat's "intr" line works again we
      have the oddity that the sum field (first field) contains only the sum
      of the second (external irqs) and third field (I/O interrupts).
      The reason for that is that these two fields are already sums of all other
      fields. So if we would sum up everything we would count every interrupt
      twice.
      This is broken since the split interrupt accounting was merged two years
      ago: 052ff461 "[S390] irq: have detailed
      statistics for interrupt types".
      To fix this remove the split interrupt fields from /proc/stat's "intr"
      line again and only have them in /proc/interrupts.
      
      This restores the old behaviour, seems to be the only sane fix and mimics
      a behaviour from other architectures where /proc/interrupts also contains
      more than /proc/stat's "intr" line does.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      420f42ec
  23. 20 7月, 2012 1 次提交
    • H
      s390/comments: unify copyright messages and remove file names · a53c8fab
      Heiko Carstens 提交于
      Remove the file name from the comment at top of many files. In most
      cases the file name was wrong anyway, so it's rather pointless.
      
      Also unify the IBM copyright statement. We did have a lot of sightly
      different statements and wanted to change them one after another
      whenever a file gets touched. However that never happened. Instead
      people start to take the old/"wrong" statements to use as a template
      for new files.
      So unify all of them in one go.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      a53c8fab
  24. 11 3月, 2012 1 次提交
    • M
      [S390] rework idle code · 4c1051e3
      Martin Schwidefsky 提交于
      Whenever the cpu loads an enabled wait PSW it will appear as idle to the
      underlying host system. The code in default_idle calls vtime_stop_cpu
      which does the necessary voodoo to get the cpu time accounting right.
      The udelay code just loads an enabled wait PSW. To correct this rework
      the vtime_stop_cpu/vtime_start_cpu logic and move the difficult parts
      to entry[64].S, vtime_stop_cpu can now be called from anywhere and
      vtime_start_cpu is gone. The correction of the cpu time during wakeup
      from an enabled wait PSW is done with a critical section in entry[64].S.
      As vtime_start_cpu is gone, s390_idle_check can be removed as well.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      4c1051e3
  25. 13 1月, 2012 1 次提交
  26. 05 1月, 2011 1 次提交
    • H
      [S390] irq: have detailed statistics for interrupt types · 052ff461
      Heiko Carstens 提交于
      Up to now /proc/interrupts only has statistics for external and i/o
      interrupts but doesn't split up them any further.
      This patch adds a line for every single interrupt source so that it
      is possible to easier tell what the machine is/was doing.
      Part of the output now looks like this;
      
                 CPU0       CPU2       CPU4
      EXT:       3898       4232       2305
      I/O:        782        315        245
      CLK:       1029       1964        727   [EXT] Clock Comparator
      IPI:       2868       2267       1577   [EXT] Signal Processor
      TMR:          0          0          0   [EXT] CPU Timer
      TAL:          0          0          0   [EXT] Timing Alert
      PFL:          0          0          0   [EXT] Pseudo Page Fault
      [...]
      NMI:          0          1          1   [NMI] Machine Checks
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      052ff461
  27. 25 11月, 2010 1 次提交
    • H
      [S390] nmi: fix clock comparator revalidation · e8129c64
      Heiko Carstens 提交于
      On each machine check all registers are revalidated. The save area for
      the clock comparator however only contains the upper most seven bytes
      of the former contents, if valid.
      Therefore the machine check handler uses a store clock instruction to
      get the current time and writes that to the clock comparator register
      which in turn will generate an immediate timer interrupt.
      However within the lowcore the expected time of the next timer
      interrupt is stored. If the interrupt happens before that time the
      handler won't be called. In turn the clock comparator won't be
      reprogrammed and therefore the interrupt condition stays pending which
      causes an interrupt loop until the expected time is reached.
      
      On NOHZ machines this can result in unresponsive machines since the
      time of the next expected interrupted can be a couple of days in the
      future.
      
      To fix this just revalidate the clock comparator register with the
      expected value.
      In addition the special handling for udelay must be changed as well.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e8129c64
  28. 17 5月, 2010 1 次提交
    • M
      [S390] idle time accounting vs. machine checks · 6377981f
      Martin Schwidefsky 提交于
      A machine check can interrupt the i/o and external interrupt handler
      anytime. If the machine check occurs while the interrupt handler is
      waking up from idle vtime_start_cpu can get executed a second time
      and the int_clock / async_enter_timer values in the lowcore get
      clobbered. This can confuse the cpu time accounting.
      To fix this problem two changes are needed. First the machine check
      handler has to use its own copies of int_clock and async_enter_timer,
      named mcck_clock and mcck_enter_timer. Second the nested execution
      of vtime_start_cpu has to be prevented. This is done in s390_idle_check
      by checking the wait bit in the program status word.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6377981f
  29. 12 6月, 2009 1 次提交
  30. 14 4月, 2009 1 次提交
  31. 26 3月, 2009 3 次提交
  32. 31 12月, 2008 1 次提交
  33. 14 7月, 2008 1 次提交