1. 13 3月, 2015 1 次提交
  2. 22 1月, 2015 1 次提交
  3. 09 10月, 2014 2 次提交
    • M
      s390/kdump: add support for vector extension · a62bc073
      Michael Holzheu 提交于
      With this patch for kdump the s390 vector registers are stored into the
      prepared save areas in the old kernel and into the REGSET_VX_LOW and
      REGSET_VX_HIGH ELF notes for /proc/vmcore in the new kernel.
      
      The NT_S390_VXRS_LOW note contains the lower halves of the first 16 vector
      registers 0-15. The higher halves are stored in the floating point register
      ELF note.  The NT_S390_VXRS_HIGH contains the full vector registers 16-31.
      
      The kernel provides a save area for storing vector register in case of
      machine checks. A pointer to this save are is stored in the CPU lowcore
      at offset 0x11b0. This save area is also used to save the registers for
      kdump. In case of a dumped crashed kdump those areas are used to extract
      the registers of the production system.
      
      The vector registers for remote CPUs are stored using the "store additional
      status at address" SIGP. For the dump CPU the vector registers are stored
      with the VSTM instruction.
      
      With this patch also zfcpdump stores the vector registers.
      Reviewed-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      a62bc073
    • 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
  4. 26 4月, 2013 1 次提交
    • M
      s390: system call path micro optimization · 61649881
      Martin Schwidefsky 提交于
      Add a pointer to the system call table to the thread_info structure.
      The TIF_31BIT bit is set or cleared by SET_PERSONALITY exactly once
      for the lifetime of a process. With the pointer to the correct system
      call table in thread_info the system call code in entry64.S path can
      drop the check for TIF_31BIT which saves a couple of instructions.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      61649881
  5. 23 4月, 2013 1 次提交
  6. 26 2月, 2013 1 次提交
  7. 26 9月, 2012 2 次提交
  8. 30 8月, 2012 1 次提交
  9. 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
  10. 24 5月, 2012 1 次提交
  11. 29 3月, 2012 1 次提交
  12. 26 9月, 2011 1 次提交
  13. 23 5月, 2011 1 次提交
    • M
      [S390] Remove data execution protection · 043d0708
      Martin Schwidefsky 提交于
      The noexec support on s390 does not rely on a bit in the page table
      entry but utilizes the secondary space mode to distinguish between
      memory accesses for instructions vs. data. The noexec code relies
      on the assumption that the cpu will always use the secondary space
      page table for data accesses while it is running in the secondary
      space mode. Up to the z9-109 class machines this has been the case.
      Unfortunately this is not true anymore with z10 and later machines.
      The load-relative-long instructions lrl, lgrl and lgfrl access the
      memory operand using the same addressing-space mode that has been
      used to fetch the instruction.
      This breaks the noexec mode for all user space binaries compiled
      with march=z10 or later. The only option is to remove the current
      noexec support.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      043d0708
  14. 12 1月, 2011 3 次提交
  15. 16 12月, 2009 1 次提交
  16. 06 10月, 2009 1 次提交
  17. 23 1月, 2009 1 次提交
  18. 25 12月, 2008 1 次提交
  19. 16 10月, 2008 1 次提交
  20. 02 8月, 2008 1 次提交
  21. 14 7月, 2008 1 次提交
  22. 10 2月, 2008 3 次提交
  23. 08 2月, 2008 1 次提交
  24. 05 5月, 2007 1 次提交
  25. 17 9月, 2006 1 次提交
  26. 13 1月, 2006 1 次提交
  27. 07 11月, 2005 1 次提交
  28. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4