1. 27 Mar, 2015 14 commits
    • James Hogan's avatar
      MIPS: KVM: Handle MSA Disabled exceptions from guest · 98119ad5
      James Hogan authored
      Guest user mode can generate a guest MSA Disabled exception on an MSA
      capable core by simply trying to execute an MSA instruction. Since this
      exception is unknown to KVM it will be passed on to the guest kernel.
      However guest Linux kernels prior to v3.15 do not set up an exception
      handler for the MSA Disabled exception as they don't support any MSA
      capable cores. This results in a guest OS panic.
      
      Since an older processor ID may be being emulated, and MSA support is
      not advertised to the guest, the correct behaviour is to generate a
      Reserved Instruction exception in the guest kernel so it can send the
      guest process an illegal instruction signal (SIGILL), as would happen
      with a non-MSA-capable core.
      
      Fix this as minimally as reasonably possible by preventing
      kvm_mips_check_privilege() from relaying MSA Disabled exceptions from
      guest user mode to the guest kernel, and handling the MSA Disabled
      exception by emulating a Reserved Instruction exception in the guest,
      via a new handle_msa_disabled() KVM callback.
      Signed-off-by: default avatarJames 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
      Cc: <stable@vger.kernel.org> # v3.15+
      98119ad5
    • James Hogan's avatar
      Merge branch '4.1-fp' of git://git.linux-mips.org/pub/scm/ralf/upstream-sfr into kvm_mips_queue · 8e6c9491
      James Hogan authored
      MIPS FP/MSA fixes from the MIPS tree. Includes a fix to ensure that the
      FPU is properly disabled by lose_fpu() when MSA is in use, and Paul
      Burton's "FP/MSA fixes" patchset which is required for FP/MSA support in
      KVM:
      
      > This series fixes a bunch of bugs, both build & runtime, with FP & MSA
      > support. Most of them only affect systems with the new FP modes & MSA
      > support enabled but patch 6 in particular is more general, fixing
      > problems for mips64 systems.
      8e6c9491
    • James Hogan's avatar
      MIPS: MSA: Fix big-endian FPR_IDX implementation · 1f3a2c6e
      James Hogan authored
      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: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9169/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      1f3a2c6e
    • James Hogan's avatar
      Revert "MIPS: Don't assume 64-bit FP registers for context switch" · 466aec5f
      James Hogan authored
      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: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9168/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      466aec5f
    • Paul Burton's avatar
      MIPS: disable FPU if the mode is unsupported · 84ab45b3
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9167/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      84ab45b3
    • Paul Burton's avatar
      MIPS: prevent FP context set via ptrace being discarded · ac9ad83b
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9166/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      ac9ad83b
    • Paul Burton's avatar
      MIPS: Ensure FCSR cause bits are clear after invoking FPU emulator · ad70c13a
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9165/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      ad70c13a
    • Paul Burton's avatar
      MIPS: clear MSACSR cause bits when handling MSA FP exception · 091be550
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9164/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      091be550
    • Paul Burton's avatar
      MIPS: wrap cfcmsa & ctcmsa accesses for toolchains with MSA support · e1bebbab
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9163/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      e1bebbab
    • Paul Burton's avatar
      MIPS: remove MSA macro recursion · a3a49810
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9162/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      a3a49810
    • Paul Burton's avatar
      MIPS: assume at as source/dest of MSA copy/insert instructions · f23ce388
      Paul Burton authored
      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: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9161/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f23ce388
    • Paul Burton's avatar
      MIPS: Push .set mips64r* into the functions needing it · 631afc65
      Paul Burton authored
      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: default avatarPaul 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: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/9612/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      631afc65
    • James Hogan's avatar
      MIPS: lose_fpu(): Disable FPU when MSA enabled · acaf6a97
      James Hogan authored
      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: default avatarJames 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: default avatarRalf Baechle <ralf@linux-mips.org>
      acaf6a97
    • Jan Kiszka's avatar
      KVM: nVMX: Add support for rdtscp · b3a2a907
      Jan Kiszka authored
      If the guest CPU is supposed to support rdtscp and the host has rdtscp
      enabled in the secondary execution controls, we can also expose this
      feature to L1. Just extend nested_vmx_exit_handled to properly route
      EXIT_REASON_RDTSCP.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      b3a2a907
  2. 24 Mar, 2015 1 commit
  3. 23 Mar, 2015 2 commits
    • Marcelo Tosatti's avatar
      Merge tag 'kvm-s390-next-20150318' of... · bbf4aef8
      Marcelo Tosatti authored
      Merge tag 'kvm-s390-next-20150318' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into queue
      
      KVM: s390: Features and fixes for 4.1 (kvm/next)
      
      1. Fixes
      2. Implement access register mode in KVM
      3. Provide a userspace post handler for the STSI instruction
      4. Provide an interface for compliant memory accesses
      5. Provide an interface for getting/setting the guest storage key
      6. Fixup for the vector facility patches: do not announce the
         vector facility in the guest for old QEMUs.
      
      1-5 were initially shown as RFC in
      
      http://www.spinics.net/lists/kvm/msg114720.html
      
      some small review changes
      - added some ACKs
      - have the AR mode patches first
      - get rid of unnecessary AR_INVAL define
      - typos and language
      
      6. two new patches
      The two new patches fixup the vector support patches that were
      introduced in the last pull request for QEMU versions that dont
      know about vector support and guests that do. (We announce the
      facility bit, but dont enable the facility so vector aware guests
      will crash on vector instructions).
      bbf4aef8
    • Marcelo Tosatti's avatar
      x86: kvm: Revert "remove sched notifier for cross-cpu migrations" · 0a4e6be9
      Marcelo Tosatti authored
      The following point:
      
          2. per-CPU pvclock time info is updated if the
             underlying CPU changes.
      
      Is not true anymore since "KVM: x86: update pvclock area conditionally,
      on cpu migration".
      
      Add task migration notification back.
      
      Problem noticed by Andy Lutomirski.
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      CC: stable@kernel.org # 3.11+
      0a4e6be9
  4. 19 Mar, 2015 2 commits
  5. 18 Mar, 2015 2 commits
  6. 17 Mar, 2015 11 commits
  7. 13 Mar, 2015 5 commits
  8. 10 Mar, 2015 3 commits