1. 07 12月, 2017 1 次提交
  2. 01 12月, 2017 1 次提交
    • D
      arm64: fpsimd: Fix failure to restore FPSIMD state after signals · 9de52a75
      Dave Martin 提交于
      The fpsimd_update_current_state() function is responsible for
      loading the FPSIMD state from the user signal frame into the
      current task during sigreturn.  When implementing support for SVE,
      conditional code was added to this function in order to handle the
      case where SVE state need to be loaded for the task and merged with
      the FPSIMD data from the signal frame; however, the FPSIMD-only
      case was unintentionally dropped.
      
      As a result of this, sigreturn does not currently restore the
      FPSIMD state of the task, except in the case where the system
      supports SVE and the signal frame contains SVE state in addition to
      FPSIMD state.
      
      This patch fixes this bug by making the copy-in of the FPSIMD data
      from the signal frame to thread_struct unconditional.
      
      This remains a performance regression from v4.14, since the FPSIMD
      state is now copied into thread_struct and then loaded back,
      instead of _only_ being loaded into the CPU FPSIMD registers.
      However, it is essential to call task_fpsimd_load() here anyway in
      order to ensure that the SVE enable bit in CPACR_EL1 is set
      correctly before returning to userspace.  This could use some
      refactoring, but since sigreturn is not a fast path I have kept
      this patch as a pure fix and left the refactoring for later.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Fixes: 8cd969d2 ("arm64/sve: Signal handling support")
      Reported-by: NAlex Bennée <alex.bennee@linaro.org>
      Tested-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      9de52a75
  3. 03 11月, 2017 13 次提交
    • D
      arm64/sve: KVM: Prevent guests from using SVE · 17eed27b
      Dave Martin 提交于
      Until KVM has full SVE support, guests must not be allowed to
      execute SVE instructions.
      
      This patch enables the necessary traps, and also ensures that the
      traps are disabled again on exit from the guest so that the host
      can still use SVE if it wants to.
      
      On guest exit, high bits of the SVE Zn registers may have been
      clobbered as a side-effect the execution of FPSIMD instructions in
      the guest.  The existing KVM host FPSIMD restore code is not
      sufficient to restore these bits, so this patch explicitly marks
      the CPU as not containing cached vector state for any task, thus
      forcing a reload on the next return to userspace.  This is an
      interim measure, in advance of adding full SVE awareness to KVM.
      
      This marking of cached vector state in the CPU as invalid is done
      using __this_cpu_write(fpsimd_last_state, NULL) in fpsimd.c.  Due
      to the repeated use of this rather obscure operation, it makes
      sense to factor it out as a separate helper with a clearer name.
      This patch factors it out as fpsimd_flush_cpu_state(), and ports
      all callers to use it.
      
      As a side effect of this refactoring, a this_cpu_write() in
      fpsimd_cpu_pm_notifier() is changed to __this_cpu_write().  This
      should be fine, since cpu_pm_enter() is supposed to be called only
      with interrupts disabled.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NChristoffer Dall <christoffer.dall@linaro.org>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      17eed27b
    • D
      arm64/sve: Add sysctl to set the default vector length for new processes · 4ffa09a9
      Dave Martin 提交于
      Because of the effect of SVE on the size of the signal frame, the
      default vector length used for new processes involves a tradeoff
      between performance of SVE-enabled software on the one hand, and
      reliability of non-SVE-aware software on the other hand.
      
      For this reason, the best choice depends on the repertoire of
      userspace software in use and is thus best left up to distro
      maintainers, sysadmins and developers.
      
      If CONFIG_SYSCTL and CONFIG_PROC_SYSCTL are enabled, this patch
      exposes the default vector length in
      /proc/sys/abi/sve_default_vector_length, where boot scripts or the
      adventurous can poke it.
      
      In common with other arm64 ABI sysctls, this control is currently
      global: setting it requires CAP_SYS_ADMIN in the root user
      namespace, but the value set is effective for subsequent execs in
      all namespaces.  The control only affects _new_ processes, however:
      changing it does not affect the vector length of any existing
      process.
      
      The intended usage model is that if userspace is known to be fully
      SVE-tolerant (or a developer is curious to find out) then this
      parameter can be cranked up during system startup.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4ffa09a9
    • D
      arm64/sve: Add prctl controls for userspace vector length management · 2d2123bc
      Dave Martin 提交于
      This patch adds two arm64-specific prctls, to permit userspace to
      control its vector length:
      
       * PR_SVE_SET_VL: set the thread's SVE vector length and vector
         length inheritance mode.
      
       * PR_SVE_GET_VL: get the same information.
      
      Although these prctls resemble instruction set features in the SVE
      architecture, they provide additional control: the vector length
      inheritance mode is Linux-specific and nothing to do with the
      architecture, and the architecture does not permit EL0 to set its
      own vector length directly.  Both can be used in portable tools
      without requiring the use of SVE instructions.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      [will: Fixed up prctl constants to avoid clash with PDEATHSIG]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      2d2123bc
    • D
      arm64/sve: ptrace and ELF coredump support · 43d4da2c
      Dave Martin 提交于
      This patch defines and implements a new regset NT_ARM_SVE, which
      describes a thread's SVE register state.  This allows a debugger to
      manipulate the SVE state, as well as being included in ELF
      coredumps for post-mortem debugging.
      
      Because the regset size and layout are dependent on the thread's
      current vector length, it is not possible to define a C struct to
      describe the regset contents as is done for existing regsets.
      Instead, and for the same reasons, NT_ARM_SVE is based on the
      freeform variable-layout approach used for the SVE signal frame.
      
      Additionally, to reduce debug overhead when debugging threads that
      might or might not have live SVE register state, NT_ARM_SVE may be
      presented in one of two different formats: the old struct
      user_fpsimd_state format is embedded for describing the state of a
      thread with no live SVE state, whereas a new variable-layout
      structure is embedded for describing live SVE state.  This avoids a
      debugger needing to poll NT_PRFPREG in addition to NT_ARM_SVE, and
      allows existing userspace code to handle the non-SVE case without
      too much modification.
      
      For this to work, NT_ARM_SVE is defined with a fixed-format header
      of type struct user_sve_header, which the recipient can use to
      figure out the content, size and layout of the reset of the regset.
      Accessor macros are defined to allow the vector-length-dependent
      parts of the regset to be manipulated.
      Signed-off-by: NAlan Hayward <alan.hayward@arm.com>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Cc: Okamoto Takayuki <tokamoto@jp.fujitsu.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      43d4da2c
    • D
      arm64/sve: Preserve SVE registers around EFI runtime service calls · fdfa976c
      Dave Martin 提交于
      The EFI runtime services ABI allows EFI to make free use of the
      FPSIMD registers during EFI runtime service calls, subject to the
      callee-save requirements of the AArch64 procedure call standard.
      
      However, the SVE architecture allows upper bits of the SVE vector
      registers to be zeroed as a side-effect of FPSIMD V-register
      writes.  This means that the SVE vector registers must be saved in
      their entirety in order to avoid data loss: non-SVE-aware EFI
      implementations cannot restore them correctly.
      
      The non-IRQ case is already handled gracefully by
      kernel_neon_begin().  For the IRQ case, this patch allocates a
      suitable per-CPU stash buffer for the full SVE register state and
      uses it to preserve the affected registers around EFI calls.  It is
      currently unclear how the EFI runtime services ABI will be
      clarified with respect to SVE, so it safest to assume that the
      predicate registers and FFR must be saved and restored too.
      
      No attempt is made to restore the restore the vector length after
      a call, for now.  It is deemed rather insane for EFI to change it,
      and contemporary EFI implementations certainly won't.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      fdfa976c
    • D
      arm64/sve: Preserve SVE registers around kernel-mode NEON use · 1bd3f936
      Dave Martin 提交于
      Kernel-mode NEON will corrupt the SVE vector registers, due to the
      way they alias the FPSIMD vector registers in the hardware.
      
      This patch ensures that any live SVE register content for the task
      is saved by kernel_neon_begin().  The data will be restored in the
      usual way on return to userspace.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      1bd3f936
    • D
      arm64/sve: Probe SVE capabilities and usable vector lengths · 2e0f2478
      Dave Martin 提交于
      This patch uses the cpufeatures framework to determine common SVE
      capabilities and vector lengths, and configures the runtime SVE
      support code appropriately.
      
      ZCR_ELx is not really a feature register, but it is convenient to
      use it as a template for recording the maximum vector length
      supported by a CPU, using the LEN field.  This field is similar to
      a feature field in that it is a contiguous bitfield for which we
      want to determine the minimum system-wide value.  This patch adds
      ZCR as a pseudo-register in cpuinfo/cpufeatures, with appropriate
      custom code to populate it.  Finding the minimum supported value of
      the LEN field is left to the cpufeatures framework in the usual
      way.
      
      The meaning of ID_AA64ZFR0_EL1 is not architecturally defined yet,
      so for now we just require it to be zero.
      
      Note that much of this code is dormant and SVE still won't be used
      yet, since system_supports_sve() remains hardwired to false.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      2e0f2478
    • D
      arm64/sve: Backend logic for setting the vector length · 7582e220
      Dave Martin 提交于
      This patch implements the core logic for changing a task's vector
      length on request from userspace.  This will be used by the ptrace
      and prctl frontends that are implemented in later patches.
      
      The SVE architecture permits, but does not require, implementations
      to support vector lengths that are not a power of two.  To handle
      this, logic is added to check a requested vector length against a
      possibly sparse bitmap of available vector lengths at runtime, so
      that the best supported value can be chosen.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      7582e220
    • D
      arm64/sve: Signal handling support · 8cd969d2
      Dave Martin 提交于
      This patch implements support for saving and restoring the SVE
      registers around signals.
      
      A fixed-size header struct sve_context is always included in the
      signal frame encoding the thread's vector length at the time of
      signal delivery, optionally followed by a variable-layout structure
      encoding the SVE registers.
      
      Because of the need to preserve backwards compatibility, the FPSIMD
      view of the SVE registers is always dumped as a struct
      fpsimd_context in the usual way, in addition to any sve_context.
      
      The SVE vector registers are dumped in full, including bits 127:0
      of each register which alias the corresponding FPSIMD vector
      registers in the hardware.  To avoid any ambiguity about which
      alias to restore during sigreturn, the kernel always restores bits
      127:0 of each SVE vector register from the fpsimd_context in the
      signal frame (which must be present): userspace needs to take this
      into account if it wants to modify the SVE vector register contents
      on return from a signal.
      
      FPSR and FPCR, which are used by both FPSIMD and SVE, are not
      included in sve_context because they are always present in
      fpsimd_context anyway.
      
      For signal delivery, a new helper
      fpsimd_signal_preserve_current_state() is added to update _both_
      the FPSIMD and SVE views in the task struct, to make it easier to
      populate this information into the signal frame.  Because of the
      redundancy between the two views of the state, only one is updated
      otherwise.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      8cd969d2
    • D
      arm64/sve: Support vector length resetting for new processes · 79ab047c
      Dave Martin 提交于
      It's desirable to be able to reset the vector length to some sane
      default for new processes, since the new binary and its libraries
      may or may not be SVE-aware.
      
      This patch tracks the desired post-exec vector length (if any) in a
      new thread member sve_vl_onexec, and adds a new thread flag
      TIF_SVE_VL_INHERIT to control whether to inherit or reset the
      vector length.  Currently these are inactive.  Subsequent patches
      will provide the capability to configure them.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      79ab047c
    • D
      arm64/sve: Core task context handling · bc0ee476
      Dave Martin 提交于
      This patch adds the core support for switching and managing the SVE
      architectural state of user tasks.
      
      Calls to the existing FPSIMD low-level save/restore functions are
      factored out as new functions task_fpsimd_{save,load}(), since SVE
      now dynamically may or may not need to be handled at these points
      depending on the kernel configuration, hardware features discovered
      at boot, and the runtime state of the task.  To make these
      decisions as fast as possible, const cpucaps are used where
      feasible, via the system_supports_sve() helper.
      
      The SVE registers are only tracked for threads that have explicitly
      used SVE, indicated by the new thread flag TIF_SVE.  Otherwise, the
      FPSIMD view of the architectural state is stored in
      thread.fpsimd_state as usual.
      
      When in use, the SVE registers are not stored directly in
      thread_struct due to their potentially large and variable size.
      Because the task_struct slab allocator must be configured very
      early during kernel boot, it is also tricky to configure it
      correctly to match the maximum vector length provided by the
      hardware, since this depends on examining secondary CPUs as well as
      the primary.  Instead, a pointer sve_state in thread_struct points
      to a dynamically allocated buffer containing the SVE register data,
      and code is added to allocate and free this buffer at appropriate
      times.
      
      TIF_SVE is set when taking an SVE access trap from userspace, if
      suitable hardware support has been detected.  This enables SVE for
      the thread: a subsequent return to userspace will disable the trap
      accordingly.  If such a trap is taken without sufficient system-
      wide hardware support, SIGILL is sent to the thread instead as if
      an undefined instruction had been executed: this may happen if
      userspace tries to use SVE in a system where not all CPUs support
      it for example.
      
      The kernel will clear TIF_SVE and disable SVE for the thread
      whenever an explicit syscall is made by userspace.  For backwards
      compatibility reasons and conformance with the spirit of the base
      AArch64 procedure call standard, the subset of the SVE register
      state that aliases the FPSIMD registers is still preserved across a
      syscall even if this happens.  The remainder of the SVE register
      state logically becomes zero at syscall entry, though the actual
      zeroing work is currently deferred until the thread next tries to
      use SVE, causing another trap to the kernel.  This implementation
      is suboptimal: in the future, the fastpath case may be optimised
      to zero the registers in-place and leave SVE enabled for the task,
      where beneficial.
      
      TIF_SVE is also cleared in the following slowpath cases, which are
      taken as reasonable hints that the task may no longer use SVE:
       * exec
       * fork and clone
      
      Code is added to sync data between thread.fpsimd_state and
      thread.sve_state whenever enabling/disabling SVE, in a manner
      consistent with the SVE architectural programmer's model.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Alex Bennée <alex.bennee@linaro.org>
      [will: added #include to fix allnoconfig build]
      [will: use enable_daif in do_sve_acc]
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      bc0ee476
    • D
      arm64: fpsimd: Simplify uses of {set,clear}_ti_thread_flag() · 9cf5b54f
      Dave Martin 提交于
      The existing FPSIMD context switch code contains a couple of
      instances of {set,clear}_ti_thread(task_thread_info(task)).  Since
      there are thread flag manipulators that operate directly on
      task_struct, this verbosity isn't strictly needed.
      
      For consistency, this patch simplifies the affected calls.  This
      should have no impact on behaviour.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      9cf5b54f
    • D
      arm64: fpsimd: Correctly annotate exception helpers called from asm · 94ef7ecb
      Dave Martin 提交于
      A couple of FPSIMD exception handling functions that are called
      from entry.S are currently not annotated as such.
      
      This is not a big deal since asmlinkage does nothing on arm/arm64,
      but fixing the annotations is more consistent and may help avoid
      future surprises.
      
      This patch adds appropriate asmlinkage annotations for
      do_fpsimd_acc() and do_fpsimd_exc().
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      94ef7ecb
  4. 06 10月, 2017 1 次提交
  5. 18 9月, 2017 1 次提交
  6. 23 8月, 2017 1 次提交
    • D
      arm64: fpsimd: Prevent registers leaking across exec · 09662210
      Dave Martin 提交于
      There are some tricky dependencies between the different stages of
      flushing the FPSIMD register state during exec, and these can race
      with context switch in ways that can cause the old task's regs to
      leak across.  In particular, a context switch during the memset() can
      cause some of the task's old FPSIMD registers to reappear.
      
      Disabling preemption for this small window would be no big deal for
      performance: preemption is already disabled for similar scenarios
      like updating the FPSIMD registers in sigreturn.
      
      So, instead of rearranging things in ways that might swap existing
      subtle bugs for new ones, this patch just disables preemption
      around the FPSIMD state flushing so that races of this type can't
      occur here.  This brings fpsimd_flush_thread() into line with other
      code paths.
      
      Cc: stable@vger.kernel.org
      Fixes: 674c242c ("arm64: flush FP/SIMD state correctly after execve()")
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      09662210
  7. 19 8月, 2017 1 次提交
  8. 07 8月, 2017 1 次提交
  9. 04 8月, 2017 3 次提交
    • D
      arm64: neon: Remove support for nested or hardirq kernel-mode NEON · cb84d11e
      Dave Martin 提交于
      Support for kernel-mode NEON to be nested and/or used in hardirq
      context adds significant complexity, and the benefits may be
      marginal.  In practice, kernel-mode NEON is not used in hardirq
      context, and is rarely used in softirq context (by certain mac80211
      drivers).
      
      This patch implements an arm64 may_use_simd() function to allow
      clients to check whether kernel-mode NEON is usable in the current
      context, and simplifies kernel_neon_{begin,end}() to handle only
      saving of the task FPSIMD state (if any).  Without nesting, there
      is no other state to save.
      
      The partial fpsimd save/restore functions become redundant as a
      result of these changes, so they are removed too.
      
      The save/restore model is changed to operate directly on
      task_struct without additional percpu storage.  This simplifies the
      code and saves a bit of memory, but means that softirqs must now be
      disabled when manipulating the task fpsimd state from task context:
      correspondingly, preempt_{en,dis}sable() calls are upgraded to
      local_bh_{en,dis}able() as appropriate.  fpsimd_thread_switch()
      already runs with hardirqs disabled and so is already protected
      from softirqs.
      
      These changes should make it easier to support kernel-mode NEON in
      the presence of the Scalable Vector extension in the future.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      cb84d11e
    • D
      arm64: neon: Allow EFI runtime services to use FPSIMD in irq context · 4328825d
      Dave Martin 提交于
      In order to be able to cope with kernel-mode NEON being unavailable
      in hardirq/nmi context and non-nestable, we need special handling
      for EFI runtime service calls that may be made during an interrupt
      that interrupted a kernel_neon_begin()..._end() block.  This will
      occur if the kernel tries to write diagnostic data to EFI
      persistent storage during a panic triggered by an NMI for example.
      
      EFI runtime services specify an ABI that clobbers the FPSIMD state,
      rather than being able to use it optionally as an accelerator.
      This means that EFI is really a special case and can be handled
      specially.
      
      To enable EFI calls from interrupts, this patch creates dedicated
      __efi_fpsimd_{begin,end}() helpers solely for this purpose, which
      save/restore to a separate percpu buffer if called in a context
      where kernel_neon_begin() is not usable.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      4328825d
    • D
      arm64: fpsimd: Consistently use __this_cpu_ ops where appropriate · 50464185
      Dave Martin 提交于
      __this_cpu_ ops are not used consistently with regard to this_cpu_
      ops in a couple of places in fpsimd.c.
      
      Since preemption is explicitly disabled in
      fpsimd_restore_current_state() and fpsimd_update_current_state(),
      this patch converts this_cpu_ ops in those functions to __this_cpu_
      ops.  This doesn't save cost on arm64, but benefits from additional
      assertions in the core code.
      Signed-off-by: NDave Martin <Dave.Martin@arm.com>
      Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      50464185
  10. 02 3月, 2017 1 次提交
  11. 17 11月, 2016 1 次提交
    • S
      arm64: Support systems without FP/ASIMD · 82e0191a
      Suzuki K Poulose 提交于
      The arm64 kernel assumes that FP/ASIMD units are always present
      and accesses the FP/ASIMD specific registers unconditionally. This
      could cause problems when they are absent. This patch adds the
      support for kernel handling systems without FP/ASIMD by skipping the
      register access within the kernel. For kvm, we trap the accesses
      to FP/ASIMD and inject an undefined instruction exception to the VM.
      
      The callers of the exported kernel_neon_begin_partial() should
      make sure that the FP/ASIMD is supported.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Christoffer Dall <christoffer.dall@linaro.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      [catalin.marinas@arm.com: add comment on the ARM64_HAS_NO_FPSIMD conflict and the new location]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      82e0191a
  12. 20 9月, 2016 1 次提交
  13. 05 3月, 2016 1 次提交
  14. 02 12月, 2015 1 次提交
  15. 21 10月, 2015 1 次提交
  16. 27 8月, 2015 1 次提交
    • A
      arm64: flush FP/SIMD state correctly after execve() · 674c242c
      Ard Biesheuvel 提交于
      When a task calls execve(), its FP/SIMD state is flushed so that
      none of the original program state is observeable by the incoming
      program.
      
      However, since this flushing consists of setting the in-memory copy
      of the FP/SIMD state to all zeroes, the CPU field is set to CPU 0 as
      well, which indicates to the lazy FP/SIMD preserve/restore code that
      the FP/SIMD state does not need to be reread from memory if the task
      is scheduled again on CPU 0 without any other tasks having entered
      userland (or used the FP/SIMD in kernel mode) on the same CPU in the
      mean time. If this happens, the FP/SIMD state of the old program will
      still be present in the registers when the new program starts.
      
      So set the CPU field to the invalid value of NR_CPUS when performing
      the flush, by calling fpsimd_flush_task_state().
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NChunyan Zhang <chunyan.zhang@spreadtrum.com>
      Reported-by: NJanet Liu <janet.liu@spreadtrum.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      674c242c
  17. 12 6月, 2015 1 次提交
  18. 01 9月, 2014 1 次提交
  19. 08 5月, 2014 3 次提交
    • A
      arm64: add support for kernel mode NEON in interrupt context · 190f1ca8
      Ard Biesheuvel 提交于
      This patch modifies kernel_neon_begin() and kernel_neon_end(), so
      they may be called from any context. To address the case where only
      a couple of registers are needed, kernel_neon_begin_partial(u32) is
      introduced which takes as a parameter the number of bottom 'n' NEON
      q-registers required. To mark the end of such a partial section, the
      regular kernel_neon_end() should be used.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      190f1ca8
    • A
      arm64: defer reloading a task's FPSIMD state to userland resume · 005f78cd
      Ard Biesheuvel 提交于
      If a task gets scheduled out and back in again and nothing has touched
      its FPSIMD state in the mean time, there is really no reason to reload
      it from memory. Similarly, repeated calls to kernel_neon_begin() and
      kernel_neon_end() will preserve and restore the FPSIMD state every time.
      
      This patch defers the FPSIMD state restore to the last possible moment,
      i.e., right before the task returns to userland. If a task does not return to
      userland at all (for any reason), the existing FPSIMD state is preserved
      and may be reused by the owning task if it gets scheduled in again on the
      same CPU.
      
      This patch adds two more functions to abstract away from straight FPSIMD
      register file saves and restores:
      - fpsimd_restore_current_state -> ensure current's FPSIMD state is loaded
      - fpsimd_flush_task_state -> invalidate live copies of a task's FPSIMD state
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      005f78cd
    • A
      arm64: add abstractions for FPSIMD state manipulation · c51f9269
      Ard Biesheuvel 提交于
      There are two tacit assumptions in the FPSIMD handling code that will no longer
      hold after the next patch that optimizes away some FPSIMD state restores:
      . the FPSIMD registers of this CPU contain the userland FPSIMD state of
        task 'current';
      . when switching to a task, its FPSIMD state will always be restored from
        memory.
      
      This patch adds the following functions to abstract away from straight FPSIMD
      register file saves and restores:
      - fpsimd_preserve_current_state -> ensure current's FPSIMD state is saved
      - fpsimd_update_current_state -> replace current's FPSIMD state
      
      Where necessary, the signal handling and fork code are updated to use the above
      wrappers instead of poking into the FPSIMD registers directly.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      c51f9269
  20. 17 12月, 2013 1 次提交
  21. 28 9月, 2013 1 次提交
  22. 20 8月, 2013 1 次提交
  23. 17 9月, 2012 1 次提交