1. 28 3月, 2015 11 次提交
    • J
      MIPS: MSA: Fix big-endian FPR_IDX implementation · 1f3a2c6e
      James Hogan 提交于
      The maximum word size is 64-bits since MSA state is saved using st.d
      which stores two 64-bit words, therefore reimplement FPR_IDX using xor,
      and only within each 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/9169/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1f3a2c6e
    • 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
    • P
      MIPS: disable FPU if the mode is unsupported · 84ab45b3
      Paul Burton 提交于
      The expected semantics of __enable_fpu are for the FPU to be enabled
      in the given mode if possible, otherwise for the FPU to be left
      disabled and SIGFPE returned. The FPU was incorrectly being left
      enabled in cases where the desired value for FR was unavailable.
      Without ensuring the FPU is disabled in this case, it would be
      possible for userland to go on to execute further FP instructions
      natively in the incorrect mode, rather than those instructions being
      trapped & emulated as they need to be.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9167/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      84ab45b3
    • P
      MIPS: prevent FP context set via ptrace being discarded · ac9ad83b
      Paul Burton 提交于
      If a ptracee has not used the FPU and the ptracer sets its FP context
      using PTRACE_POKEUSR, PTRACE_SETFPREGS or PTRACE_SETREGSET then that
      context will be discarded upon either the ptracee using the FPU or a
      further write to the context via ptrace. Prevent this loss by recording
      that the task has "used" math once its FP context has been written to.
      The context initialisation code that was present for the PTRACE_POKEUSR
      case is reused for the other 2 cases to provide consistent behaviour
      for the different ptrace requests.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9166/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ac9ad83b
    • P
      MIPS: Ensure FCSR cause bits are clear after invoking FPU emulator · ad70c13a
      Paul Burton 提交于
      When running the emulator to handle an instruction that raised an FP
      unimplemented operation exception, the FCSR cause bits were being
      cleared. This is done to ensure that the kernel does not take an FP
      exception when later restoring FP context to registers. However, this
      was not being done when the emulator is invoked in response to a
      coprocessor unusable exception. This happens in 2 cases:
      
        - There is no FPU present in the system. In this case things were
          OK, since the FP context is never restored to hardware registers
          and thus no FP exception may be raised when restoring FCSR.
      
        - The FPU could not be configured to the mode required by the task.
          In this case it would be possible for the emulator to set cause
          bits which are later restored to hardware if the task migrates
          to a CPU whose associated FPU does support its mode requirements,
          or if the tasks FP mode requirements change.
      
      Consistently clear the cause bits after invoking the emulator, by moving
      the clearing to process_fpemu_return and ensuring this is always called
      before the tasks FP context is restored. This will make it easier to
      catch further paths invoking the emulator in future, as will be
      introduced in further patches.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9165/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      ad70c13a
    • P
      MIPS: clear MSACSR cause bits when handling MSA FP exception · 091be550
      Paul Burton 提交于
      Much like for traditional scalar FP exceptions, the cause bits in the
      MSACSR register need to be cleared following an MSA FP exception.
      Without doing so the exception will simply be raised again whenever
      the kernel restores MSACSR from a tasks saved context, leading to
      undesirable spurious exceptions. Clear the cause bits from the
      handle_msa_fpe function, mirroring the way handle_fpe clears the
      cause bits in FCSR.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9164/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      091be550
    • P
      MIPS: wrap cfcmsa & ctcmsa accesses for toolchains with MSA support · e1bebbab
      Paul Burton 提交于
      Uses of the cfcmsa & ctcmsa instructions were not being wrapped by a
      macro in the case where the toolchain supports MSA, since the arguments
      exactly match a typical use of the instructions. However using current
      toolchains this leads to errors such as:
      
        arch/mips/kernel/genex.S:437: Error: opcode not supported on this processor: mips32r2 (mips32r2) `cfcmsa $5,1'
      
      Thus uses of the instructions must be in the context of a ".set msa"
      directive, however doing that from the users of the instructions would
      be messy due to the possibility that the toolchain does not support
      MSA. Fix this by renaming the macros (prepending an underscore) in order
      to avoid recursion when attempting to emit the instructions, and provide
      implementations for the TOOLCHAIN_SUPPORTS_MSA case which ".set msa" as
      appropriate.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9163/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e1bebbab
    • P
      MIPS: remove MSA macro recursion · a3a49810
      Paul Burton 提交于
      Recursive macros made the code more concise & worked great for the
      case where the toolchain doesn't support MSA. However, with toolchains
      which do support MSA they lead to build failures such as:
      
        arch/mips/kernel/r4k_switch.S: Assembler messages:
        arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[2],$1'
        arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[3],$1'
        arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[2],$1'
        arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[3],$1'
        ...
      
      Drop the recursion from msa_init_all_upper invoking the msa_init_upper
      macro explicitly for each vector register.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9162/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a3a49810
    • P
      MIPS: assume at as source/dest of MSA copy/insert instructions · f23ce388
      Paul Burton 提交于
      Assuming at ($1) as the source or destination register of copy or
      insert instructions:
      
        - Simplifies the macros providing those instructions for toolchains
          without MSA support.
      
        - Avoids an unnecessary move instruction when at is used as the source
          or destination register anyway.
      
        - Is sufficient for the uses to be introduced in the kernel by a
          subsequent patch.
      
      Note that due to a patch ordering snafu on my part this also fixes the
      currently broken build with MSA support enabled. The build has been
      broken since commit c9017757 "MIPS: init upper 64b of vector
      registers when MSA is first used", which this patch should have
      preceeded.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9161/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f23ce388
    • P
      MIPS: Push .set mips64r* into the functions needing it · 631afc65
      Paul Burton 提交于
      The {save,restore}_fp_context{,32} functions require that the assembler
      allows the use of sdc instructions on any FP register, and this is
      acomplished by setting the arch to mips64r2 or mips64r6
      (using MIPS_ISA_ARCH_LEVEL_RAW).
      
      However this has the effect of enabling the assembler to use mips64
      instructions in the expansion of pseudo-instructions. This was done in
      the (now-reverted) commit eec43a22 "MIPS: Save/restore MSA context
      around signals" which led to my mistakenly believing that there was an
      assembler bug, when in reality the assembler was just emitting mips64
      instructions. Avoid the issue for future commits which will add code to
      r4k_fpu.S by pushing the .set MIPS_ISA_ARCH_LEVEL_RAW directives into
      the functions that require it, and remove the spurious assertion
      declaring the assembler bug.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      [james.hogan@imgtec.com: Rebase on v4.0-rc1 and reword commit message to
       reflect use of MIPS_ISA_ARCH_LEVEL_RAW]
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9612/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      631afc65
    • J
      MIPS: lose_fpu(): Disable FPU when MSA enabled · acaf6a97
      James Hogan 提交于
      The lose_fpu() function only disables the FPU in CP0_Status.CU1 if the
      FPU is in use and MSA isn't enabled.
      
      This isn't necessarily a problem because KSTK_STATUS(current), the
      version of CP0_Status stored on the kernel stack on entry from user
      mode, does always get updated and gets restored when returning to user
      mode, but I don't think it was intended, and it is inconsistent with the
      case of only the FPU being in use. Sometimes leaving the FPU enabled may
      also mask kernel bugs where FPU operations are executed when the FPU
      might not be enabled.
      
      So lets disable the FPU in the MSA case too.
      
      Fixes: 33c771ba ("MIPS: save/disable MSA in lose_fpu")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9323/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      acaf6a97
  2. 03 3月, 2015 2 次提交
  3. 21 2月, 2015 2 次提交
  4. 20 2月, 2015 24 次提交
  5. 19 2月, 2015 1 次提交