Skip to content
  1. Jul 15, 2021
    • Mark Rutland's avatar
      arm64: entry: fix KCOV suppression · e6f85cbe
      Mark Rutland authored
      
      
      We suppress KCOV for entry.o rather than entry-common.o. As entry.o is
      built from entry.S, this is pointless, and permits instrumentation of
      entry-common.o, which is built from entry-common.c.
      
      Fix the Makefile to suppress KCOV for entry-common.o, as we had intended
      to begin with. I've verified with objdump that this is working as
      expected.
      
      Fixes: bf6fa2c0 ("arm64: entry: don't instrument entry code with KCOV")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20210715123049.9990-1-mark.rutland@arm.com
      
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      e6f85cbe
    • Mark Rutland's avatar
      arm64: entry: add missing noinstr · 31a7f0f6
      Mark Rutland authored
      
      
      We intend that all the early exception handling code is marked as
      `noinstr`, but we forgot this for __el0_error_handler_common(), which is
      called before we have completed entry from user mode. If it were
      instrumented, we could run into problems with RCU, lockdep, etc.
      
      Mark it as `noinstr` to prevent this.
      
      The few other functions in entry-common.c which do not have `noinstr` are
      called once we've completed entry, and are safe to instrument.
      
      Fixes: bb8e93a2 ("arm64: entry: convert SError handlers to C")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Joey Gouly <joey.gouly@arm.com>
      Cc: James Morse <james.morse@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20210714172801.16475-1-mark.rutland@arm.com
      
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      31a7f0f6
    • Mark Rutland's avatar
      arm64: mte: fix restoration of GCR_EL1 from suspend · 59f44069
      Mark Rutland authored
      
      
      Since commit:
      
        bad1e1c6 ("arm64: mte: switch GCR_EL1 in kernel entry and exit")
      
      we saved/restored the user GCR_EL1 value at exception boundaries, and
      update_gcr_el1_excl() is no longer used for this. However it is used to
      restore the kernel's GCR_EL1 value when returning from a suspend state.
      Thus, the comment is misleading (and an ISB is necessary).
      
      When restoring the kernel's GCR value, we need an ISB to ensure this is
      used by subsequent instructions. We don't necessarily get an ISB by
      other means (e.g. if the kernel is built without support for pointer
      authentication). As __cpu_setup() initialised GCR_EL1.Exclude to 0xffff,
      until a context synchronization event, allocation tag 0 may be used
      rather than the desired set of tags.
      
      This patch drops the misleading comment, adds the missing ISB, and for
      clarity folds update_gcr_el1_excl() into its only user.
      
      Fixes: bad1e1c6 ("arm64: mte: switch GCR_EL1 in kernel entry and exit")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20210714143843.56537-2-mark.rutland@arm.com
      
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      59f44069
  2. Jul 12, 2021
  3. Jul 08, 2021
  4. Jul 01, 2021
  5. Jun 22, 2021
  6. Jun 18, 2021
  7. Jun 17, 2021
  8. Jun 15, 2021
  9. Jun 13, 2021
  10. Jun 11, 2021
  11. Jun 08, 2021
    • Mark Brown's avatar
      arm64: smccc: Support SMCCC v1.3 SVE register saving hint · cfa7ff95
      Mark Brown authored
      
      
      SMCCC v1.2 requires that all SVE state be preserved over SMC calls which
      introduces substantial overhead in the common case where there is no SVE
      state in the registers. To avoid this SMCCC v1.3 introduces a flag which
      allows the caller to say that there is no state that needs to be preserved
      in the registers. Make use of this flag, setting it if the SMCCC version
      indicates support for it and the TIF_ flags indicate that there is no live
      SVE state in the registers, this avoids placing any constraints on when
      SMCCC calls can be done or triggering extra saving and reloading of SVE
      register state in the kernel.
      
      This would be straightforward enough except for the rather entertaining
      inline assembly we use to do SMCCC v1.1 calls to allow us to take advantage
      of the limited number of registers it clobbers. Deal with this by having a
      function which we call immediately before issuing the SMCCC call to make
      our checks and set the flag. Using alternatives the overhead if SVE is
      supported but not detected at runtime can be reduced to a single NOP.
      
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Reviewed-by: default avatarArd Biesheuvel <ardb@kernel.org>
      Reviewed-by: default avatarMarc Zyngier <maz@kernel.org>
      Link: https://lore.kernel.org/r/20210603184118.15090-1-broonie@kernel.org
      
      
      Signed-off-by: default avatarWill Deacon <will@kernel.org>
      cfa7ff95
  12. Jun 07, 2021
Loading