1. 13 5月, 2016 1 次提交
  2. 03 9月, 2015 2 次提交
  3. 14 7月, 2015 1 次提交
  4. 13 4月, 2015 1 次提交
  5. 28 3月, 2015 3 次提交
    • J
      MIPS: KVM: Add base guest MSA support · 539cb89f
      James Hogan 提交于
      Add base code for supporting the MIPS SIMD Architecture (MSA) in MIPS
      KVM guests. MSA cannot yet be enabled in the guest, we're just laying
      the groundwork.
      
      As with the FPU, whether the guest's MSA context is loaded is stored in
      another bit in the fpu_inuse vcpu member. This allows MSA to be disabled
      when the guest disables it, but keeping the MSA context loaded so it
      doesn't have to be reloaded if the guest re-enables it.
      
      New assembly code is added for saving and restoring the MSA context,
      restoring only the upper half of the MSA context (for if the FPU context
      is already loaded) and for saving/clearing and restoring MSACSR (which
      can itself cause an MSA FP exception depending on the value). The MSACSR
      is restored before returning to the guest if MSA is already enabled, and
      the existing FP exception die notifier is extended to catch the possible
      MSA FP exception and step over the ctcmsa instruction.
      
      The helper function kvm_own_msa() is added to enable MSA and restore
      the MSA context if it isn't already loaded, which will be used in a
      later patch when the guest attempts to use MSA for the first time and
      triggers an MSA disabled exception.
      
      The existing FPU helpers are extended to handle MSA. kvm_lose_fpu()
      saves the full MSA context if it is loaded (which includes the FPU
      context) and both kvm_lose_fpu() and kvm_drop_fpu() disable MSA.
      
      kvm_own_fpu() also needs to lose any MSA context if FR=0, since there
      would be a risk of getting reserved instruction exceptions if CU1 is
      enabled and we later try and save the MSA context. We shouldn't usually
      hit this case since it will be handled when emulating CU1 changes,
      however there's nothing to stop the guest modifying the Status register
      directly via the comm page, which will cause this case to get hit.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      539cb89f
    • J
      MIPS: KVM: Add base guest FPU support · 98e91b84
      James Hogan 提交于
      Add base code for supporting FPU in MIPS KVM guests. The FPU cannot yet
      be enabled in the guest, we're just laying the groundwork.
      
      Whether the guest's FPU context is loaded is stored in a bit in the
      fpu_inuse vcpu member. This allows the FPU to be disabled when the guest
      disables it, but keeping the FPU context loaded so it doesn't have to be
      reloaded if the guest re-enables it.
      
      An fpu_enabled vcpu member stores whether userland has enabled the FPU
      capability (which will be wired up in a later patch).
      
      New assembly code is added for saving and restoring the FPU context, and
      for saving/clearing and restoring FCSR (which can itself cause an FP
      exception depending on the value). The FCSR is restored before returning
      to the guest if the FPU is already enabled, and a die notifier is
      registered to catch the possible FP exception and step over the ctc1
      instruction.
      
      The helper function kvm_lose_fpu() is added to save FPU context and
      disable the FPU, which is used when saving hardware state before a
      context switch or KVM exit (the vcpu_get_regs() callback).
      
      The helper function kvm_own_fpu() is added to enable the FPU and restore
      the FPU context if it isn't already loaded, which will be used in a
      later patch when the guest attempts to use the FPU for the first time
      and triggers a co-processor unusable exception.
      
      The helper function kvm_drop_fpu() is added to discard the FPU context
      and disable the FPU, which will be used in a later patch when the FPU
      state will become architecturally UNPREDICTABLE (change of FR mode) to
      force a reload of [stale] context in the new FR mode.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      98e91b84
    • J
      Revert "MIPS: Don't assume 64-bit FP registers for context switch" · 466aec5f
      James Hogan 提交于
      This reverts commit 02987633.
      
      The basic premise of the patch was incorrect since MSA context
      (including FP state) is saved using st.d which stores two consecutive
      64-bit words in memory rather than a single 128-bit word. This means
      that even with big endian MSA, the FP state is still in the first 64-bit
      word.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9168/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      466aec5f
  6. 20 2月, 2015 1 次提交
  7. 17 2月, 2015 1 次提交
    • M
      MIPS: Make use of the ERETNC instruction on MIPS R6 · 7c151d3d
      Markos Chandras 提交于
      The ERETNC instruction, introduced in MIPS R5, is similar to the ERET
      one, except it does not clear the LLB bit in the LLADDR register.
      This feature is necessary to safely emulate R2 LL/SC instructions.
      However, on context switches, we need to clear the LLAddr/LLB bit
      in order to make sure that an SC instruction from the new thread
      will never succeed if it happens to interrupt an LL operation on the
      same address from the previous thread.
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      7c151d3d
  8. 13 2月, 2015 1 次提交
    • A
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski 提交于
      If an attacker can cause a controlled kernel stack overflow, overwriting
      the restart block is a very juicy exploit target.  This is because the
      restart_block is held in the same memory allocation as the kernel stack.
      
      Moving the restart block to struct task_struct prevents this exploit by
      making the restart_block harder to locate.
      
      Note that there are other fields in thread_info that are also easy
      targets, at least on some architectures.
      
      It's also a decent simplification, since the restart code is more or less
      identical on all architectures.
      
      [james.hogan@imgtec.com: metag: align thread_info::supervisor_stack]
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NRichard Weinberger <richard@nod.at>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
  9. 02 8月, 2014 1 次提交
  10. 26 6月, 2014 1 次提交
    • P
      Revert "MIPS: Save/restore MSA context around signals" · 16f77de8
      Paul Burton 提交于
      This reverts commit eec43a22 "MIPS: Save/restore MSA context around
      signals" and the MSA parts of ca750649 "MIPS: kernel: signal:
      Prevent save/restore FPU context in user memory" (the restore path of
      which appears incorrect anyway...).
      
      The reverted patch took care not to break compatibility with userland
      users of struct sigcontext, but inadvertantly changed the offset of the
      uc_sigmask field of struct ucontext. Thus Linux v3.15 breaks the
      userland ABI. The MSA context will need to be saved via some other
      opt-in mechanism, but for now revert the change to reduce the fallout.
      
      This will have minimal impact upon use of MSA since the only supported
      CPU which includes it (the P5600) is 32-bit and therefore requires that
      the experimental CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option be selected
      before the kernel will set FR=1 for a task, a requirement for MSA use.
      Thus the users of MSA are limited to known small groups of people & this
      patch won't be breaking any previously working MSA-using userland
      outside of experimental settings.
      
      [ralf@linux-mips.org: Fixed rejects.]
      
      Cc: stable@vger.kernel.org
      Reported-by: NJoseph S. Myers <joseph@codesourcery.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: stable@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/7107/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      16f77de8
  11. 28 5月, 2014 1 次提交
    • P
      MIPS: smp-cps: rework core/VPE initialisation · 245a7868
      Paul Burton 提交于
      When hotplug and/or a powered down idle state are supported cases will
      arise where a non-zero VPE must be brought online without VPE 0, and it
      where multiple VPEs must be onlined simultaneously. This patch prepares
      for that by:
      
        - Splitting struct boot_config into core & VPE boot config structures,
          allocated one per core or VPE respectively. This allows for multiple
          VPEs to be onlined simultaneously without clobbering each others
          configuration.
      
        - Indicating which VPEs should be online within a core at any given
          time using a bitmap. This allows multiple VPEs to be brought online
          simultaneously and also indicates to VPE 0 whether it should halt
          after starting any non-zero VPEs that should be online within the
          core. For example if all VPEs within a core are offlined via hotplug
          and the user onlines the second VPE within that core:
      
            1) The core will be powered up.
      
            2) VPE 0 will run from the BEV (ie. mips_cps_core_entry) to
               initialise the core.
      
            3) VPE 0 will start VPE 1 because its bit is set in the cores
               bitmap.
      
            4) VPE 0 will halt itself because its bit is clear in the cores
               bitmap.
      
        - Moving the core & VPE initialisation to assembly code which does not
          make any use of the stack. This is because if a non-zero VPE is to
          be brought online in a powered down core then when VPE 0 of that
          core runs it may not have a valid stack, and even if it did then
          it's messy to run through parts of generic kernel code on VPE 0
          before starting the correct VPE.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      245a7868
  12. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      Ralf Baechle 提交于
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
      Which is a pity - the SMTC technology primarily developed by Kevin D.
      Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
      ASE's power and elegance.
      
      Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
      https://patchwork.linux-mips.org/patch/6719/ which while very similar did
      no longer apply cleanly when I tried to merge it plus some additional
      post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
      merge once upon a time.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  13. 02 5月, 2014 1 次提交
    • J
      MIPS: PM: Implement PM helper macros · 74e91335
      James Hogan 提交于
      Implement assembler helper macros in asm/pm.h for platform code to use
      for saving context across low power states - for example suspend to RAM
      or powered down cpuidle states. Macros are provided for saving and
      restoring the main CPU context used by C code and doing important
      configuration which must be done very early during resume. Notably EVA
      needs segmentation control registers to be restored before the stack or
      dynamically allocated memory is accessed, so that state is saved in
      global data.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      74e91335
  14. 27 3月, 2014 3 次提交
  15. 01 7月, 2013 1 次提交
  16. 08 5月, 2013 1 次提交
  17. 29 12月, 2012 1 次提交
  18. 12 12月, 2012 1 次提交
  19. 11 10月, 2012 1 次提交
  20. 05 8月, 2010 1 次提交
  21. 27 2月, 2010 1 次提交
  22. 18 9月, 2009 1 次提交
  23. 17 6月, 2009 1 次提交
  24. 11 1月, 2009 1 次提交
  25. 29 4月, 2008 1 次提交
  26. 28 4月, 2008 1 次提交
  27. 27 8月, 2007 1 次提交
  28. 01 8月, 2007 1 次提交
  29. 10 5月, 2007 1 次提交
    • R
      rename thread_info to stack · f7e4217b
      Roman Zippel 提交于
      This finally renames the thread_info field in task structure to stack, so that
      the assumptions about this field are gone and archs have more freedom about
      placing the thread_info structure.
      
      Nonbroken archs which have a proper thread pointer can do the access to both
      current thread and task structure via a single pointer.
      
      It'll allow for a few more cleanups of the fork code, from which e.g.  ia64
      could benefit.
      Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
      [akpm@linux-foundation.org: build fix]
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7e4217b
  30. 27 4月, 2007 1 次提交
  31. 22 2月, 2007 1 次提交
    • F
      [MIPS] Add basic SMARTMIPS ASE support · 9693a853
      Franck Bui-Huu 提交于
      This patch adds trivial support for SMARTMIPS extension. This extension
      is currently implemented by 4KS[CD] CPUs.
      
      Basically it saves/restores ACX register, which is part of the SMARTMIPS
      ASE, when needed. This patch does *not* add any support for Smartmips MMU
      features.
      
      Futhermore this patch does not add explicit support for 4KS[CD] CPUs since
      they are respectively mips32 and mips32r2 compliant.  So with the current
      processor configuration, a platform that has such CPUs needs to select
      both configs:
      
      	CPU_HAS_SMARTMIPS
      	SYS_HAS_CPU_MIPS32_R[12]
      
      This is due to the processor configuration which is mixing up all the
      architecture variants and the processor types.
      
      The drawback of this, is that we currently pass '-march=mips32' option to
      gcc when building a kernel instead of '-march=4ksc' for 4KSC case. This
      can lead to a kernel image a little bit bigger than required.
      Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9693a853
  32. 11 2月, 2007 1 次提交
  33. 07 2月, 2007 1 次提交
  34. 02 11月, 2006 1 次提交
  35. 08 10月, 2006 1 次提交