1. 25 Nov, 2014 10 commits
    • Mark Rutland's avatar
      arm64: sanity checks: add missing newline to print · efdf4211
      Mark Rutland authored
      A missing newline in the WARN_TAINT_ONCE string results in ugly and
      somewhat difficult to read output in the case of a sanity check failure,
      as the next print does not appear on a new line:
      
        Unsupported CPU feature variation.Modules linked in:
      
      This patch adds the missing newline, fixing the output formatting.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      efdf4211
    • Mark Rutland's avatar
      arm64: sanity checks: ignore ID_MMFR0.AuxReg · 9760270c
      Mark Rutland authored
      It seems that Cortex-A53 r0p4 added support for AIFSR and ADFSR, and
      ID_MMFR0.AuxReg has been updated accordingly to report this fact. As
      Cortex-A53 could be paired with CPUs which do not implement these
      registers (e.g. all current revisions of Cortex-A57), this may trigger a
      sanity check failure at boot.
      
      The AuxReg value describes the availability of the ACTLR, AIFSR, and
      ADFSR registers, which are only of use to 32-bit guest OSs, and have
      IMPLEMENTATION DEFINED contents. Given the nature of these registers it
      is likely that KVM will need to trap accesses regardless of whether the
      CPUs are heterogeneous.
      
      This patch masks out the ID_MMFR0.AuxReg value from the sanity checks,
      preventing spurious warnings at boot time.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reported-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      9760270c
    • Mark Brown's avatar
      arm64: topology: Fix handling of multi-level cluster MPIDR-based detection · 1cefdaea
      Mark Brown authored
      The only requirement the scheduler has on cluster IDs is that they must
      be unique.  When enumerating the topology based on MPIDR information the
      kernel currently generates cluster IDs by using the first level of
      affinity above the core ID (either level one or two depending on if the
      core has multiple threads) however the ARMv8 architecture allows for up
      to three levels of affinity.  This means that an ARMv8 system may
      contain cores which have MPIDRs identical other than affinity level
      three which with current code will cause us to report multiple cores
      with the same identification to the scheduler in violation of its
      uniqueness requirement.
      
      Ensure that we do not violate the scheduler requirements on systems that
      uses all the affinity levels by incorporating both affinity levels two
      and three into the cluser ID when the cores are not threaded.
      
      While no currently known hardware uses multi-level clusters it is better
      to program defensively, this will help ease bringup of systems that have
      them and will ensure that things like distribution install media do not
      need to be respun to replace kernels in order to deploy such systems.
      In the worst case the system will work but perform suboptimally until a
      kernel modified to handle the new topology better is installed, in the
      best case this will be an adequate description of such topologies for
      the scheduler to perform well.
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1cefdaea
    • Andre Przywara's avatar
      arm64: protect alternatives workarounds with Kconfig options · c0a01b84
      Andre Przywara authored
      Not all of the errata we have workarounds for apply necessarily to all
      SoCs, so people compiling a kernel for one very specific SoC may not
      need to patch the kernel.
      Introduce a new submenu in the "Platform selection" menu to allow
      people to turn off certain bugs if they are not affected. By default
      all of them are enabled.
      Normal users or distribution kernels shouldn't bother to deselect any
      bugs here, since the alternatives framework will take care of
      patching them in only if needed.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      [will: moved kconfig menu under `Kernel Features']
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      c0a01b84
    • Andre Przywara's avatar
      arm64: add Cortex-A57 erratum 832075 workaround · 5afaa1fc
      Andre Przywara authored
      The ARM erratum 832075 applies to certain revisions of Cortex-A57,
      one of the workarounds is to change device loads into using
      load-aquire semantics.
      This is achieved using the alternatives framework.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      5afaa1fc
    • Andre Przywara's avatar
      arm64: add Cortex-A53 cache errata workaround · 301bcfac
      Andre Przywara authored
      The ARM errata 819472, 826319, 827319 and 824069 define the same
      workaround for these hardware issues in certain Cortex-A53 parts.
      Use the new alternatives framework and the CPU MIDR detection to
      patch "cache clean" into "cache clean and invalidate" instructions if
      an affected CPU is detected at runtime.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      [will: add __maybe_unused to squash gcc warning]
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      301bcfac
    • Andre Przywara's avatar
      arm64: detect silicon revisions and set cap bits accordingly · e116a375
      Andre Przywara authored
      After each CPU has been started, we iterate through a list of
      CPU features or bugs to detect CPUs which need (or could benefit
      from) kernel code patches.
      For each feature/bug there is a function which checks if that
      particular CPU is affected. We will later provide some more generic
      functions for common things like testing for certain MIDR ranges.
      We do this for every CPU to cover big.LITTLE systems properly as
      well.
      If a certain feature/bug has been detected, the capability bit will
      be set, so that later the call to apply_alternatives() will trigger
      the actual code patching.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e116a375
    • Andre Przywara's avatar
      arm64: add alternative runtime patching · e039ee4e
      Andre Przywara authored
      With a blatant copy of some x86 bits we introduce the alternative
      runtime patching "framework" to arm64.
      This is quite basic for now and we only provide the functions we need
      at this time.
      This is connected to the newly introduced feature bits.
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e039ee4e
    • Andre Przywara's avatar
      arm64: add cpu_capabilities bitmap · 930da09f
      Andre Przywara authored
      For taking note if at least one CPU in the system needs a bug
      workaround or would benefit from a code optimization, we create a new
      bitmap to hold (artificial) feature bits.
      Since elf_hwcap is part of the userland ABI, we keep it alone and
      introduce a new data structure for that (along with some accessors).
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      930da09f
    • Will Deacon's avatar
      arm64: fix return code check when changing emulation handler · 90963395
      Will Deacon authored
      update_insn_emulation_mode() returns 0 on success, so we should be
      treating any non-zero values as failure, rather than the other way
      around. Otherwise, writes to the sysctl file controlling the emulation
      are ignored and immediately rolled back.
      Reported-by: default avatarGene Hackmann <ghackmann@google.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      90963395
  2. 20 Nov, 2014 6 commits
  3. 17 Nov, 2014 1 commit
  4. 14 Nov, 2014 3 commits
    • Will Deacon's avatar
      arm64: entry: use ldp/stp instead of push/pop when saving/restoring regs · 63648dd2
      Will Deacon authored
      The push/pop instructions can be suboptimal when saving/restoring large
      amounts of data to/from the stack, for example on entry/exit from the
      kernel. This is because:
      
        (1) They act on descending addresses (i.e. the newly decremented sp),
            which may defeat some hardware prefetchers
      
        (2) They introduce an implicit dependency between each instruction, as
            the sp has to be updated in order to resolve the address of the
            next access.
      
      This patch removes the push/pop instructions from our kernel entry/exit
      macros in favour of ldp/stp plus offset.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      63648dd2
    • Will Deacon's avatar
      arm64: entry: avoid writing lr explicitly for constructing return paths · d54e81f9
      Will Deacon authored
      Using an explicit adr instruction to set the link register to point at
      ret_fast_syscall/ret_to_user can defeat branch and return stack predictors.
      
      Instead, use the standard calling instructions (bl, blr) and have an
      unconditional branch as the following instruction.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d54e81f9
    • Mark Rutland's avatar
      arm64: Fix up /proc/cpuinfo · 44b82b77
      Mark Rutland authored
      Commit d7a49086 (arm64: cpuinfo: print info for all CPUs)
      attempted to clean up /proc/cpuinfo, but due to concerns regarding
      further changes was reverted in commit 5e39977e (Revert "arm64:
      cpuinfo: print info for all CPUs").
      
      There are two major issues with the arm64 /proc/cpuinfo format
      currently:
      
      * The "Features" line describes (only) the 64-bit hwcaps, which is
        problematic for some 32-bit applications which attempt to parse it. As
        the same names are used for analogous ISA features (e.g. aes) despite
        these generally being architecturally unrelated, it is not possible to
        simply append the 64-bit and 32-bit hwcaps in a manner that might not
        be misleading to some applications.
      
        Various potential solutions have appeared in vendor kernels. Typically
        the format of the Features line varies depending on whether the task
        is 32-bit.
      
      * Information is only printed regarding a single CPU. This does not
        match the ARM format, and does not provide sufficient information in
        big.LITTLE systems where CPUs are heterogeneous. The CPU information
        printed is queried from the current CPU's registers, which is racy
        w.r.t. cross-cpu migration.
      
      This patch attempts to solve these issues. The following changes are
      made:
      
      * When a task with a LINUX32 personality attempts to read /proc/cpuinfo,
        the "Features" line contains the decoded 32-bit hwcaps, as with the
        arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns
        with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In
        the absense of compat support, the Features line is empty.
      
        The set of hwcaps injected into a task's auxval are unaffected.
      
      * Properties are printed per-cpu, as with the ARM port. The per-cpu
        information is queried from pre-recorded cpu information (as used by
        the sanity checks).
      
      * As with the previous attempt at fixing up /proc/cpuinfo, the hardware
        field is removed. The only users so far are 32-bit applications tied
        to particular boards, so no portable applications should be affected,
        and this should prevent future tying to particular boards.
      
      The following differences remain:
      
      * No model_name is printed, as this cannot be queried from the hardware
        and cannot be provided in a stable fashion. Use of the CPU
        {implementor,variant,part,revision} fields is sufficient to identify a
        CPU and is portable across arm and arm64.
      
      * The following system-wide properties are not provided, as they are not
        possible to provide generally. Programs relying on these are already
        tied to particular (32-bit only) boards:
        - Hardware
        - Revision
        - Serial
      
      No software has yet been identified for which these remaining
      differences are problematic.
      
      Cc: Greg Hackmann <ghackmann@google.com>
      Cc: Ian Campbell <ijc@hellion.org.uk>
      Cc: Serban Constantinescu <serban.constantinescu@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: cross-distro@lists.linaro.org
      Cc: linux-api@vger.kernel.org
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      44b82b77
  5. 07 Nov, 2014 1 commit
  6. 06 Nov, 2014 3 commits
  7. 05 Nov, 2014 7 commits
  8. 24 Oct, 2014 1 commit
  9. 03 Oct, 2014 4 commits
    • Laszlo Ersek's avatar
      arm64: efi: Format EFI memory type & attrs with efi_md_typeattr_format() · 65ba758f
      Laszlo Ersek authored
      An example log excerpt demonstrating the change:
      
      Before the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data]
      >   0x000040001000-0x00004007ffff [Conventional Memory]
      >   0x000040080000-0x00004072afff [Loader Data]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory]
      >   0x0000964e9000-0x0000964e9fff [Loader Data]
      >   0x0000964ea000-0x000096c52fff [Loader Code]
      >   0x000096c53000-0x00009709dfff [Boot Code]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data]*
      >   0x0000970f5000-0x000097117fff [Runtime Code]*
      >   0x000097118000-0x000097199fff [Runtime Data]*
      >   0x00009719a000-0x0000971dffff [Runtime Code]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory]
      >   0x0000997f9000-0x0000998f1fff [Boot Data]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory]
      >   0x0000999eb000-0x00009af09fff [Boot Data]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory]
      >   0x00009af22000-0x00009af46fff [Boot Data]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory]
      >   0x00009af5c000-0x00009afe1fff [Boot Data]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory]
      >   0x00009afe3000-0x00009c01ffff [Boot Data]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory]
      >   0x00009efc0000-0x00009f14efff [Boot Code]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code]*
      >   0x00009f163000-0x00009f194fff [Runtime Data]*
      >   0x00009f195000-0x00009f197fff [Boot Data]*
      >   0x00009f198000-0x00009f198fff [Runtime Data]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory]
      >   0x00009f1ad000-0x00009f1affff [Boot Data]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O]
      
      After the patch:
      
      > Processing EFI memory map:
      >   0x000040000000-0x000040000fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040001000-0x00004007ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x000040080000-0x00004072afff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00004072b000-0x00005fdfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe00000-0x00005fe0ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x00005fe10000-0x0000964e8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964e9000-0x0000964e9fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000964ea000-0x000096c52fff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
      >   0x000096c53000-0x00009709dfff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009709e000-0x0000970b3fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970b4000-0x0000970f4fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000970f5000-0x000097117fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x000097118000-0x000097199fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009719a000-0x0000971dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x0000971e0000-0x0000997f8fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000997f9000-0x0000998f1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x0000998f2000-0x0000999eafff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x0000999eb000-0x00009af09fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af0a000-0x00009af21fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af22000-0x00009af46fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009af47000-0x00009af5bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009af5c000-0x00009afe1fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009afe2000-0x00009afe2fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009afe3000-0x00009c01ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009c020000-0x00009efbffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009efc0000-0x00009f14efff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f14f000-0x00009f162fff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f163000-0x00009f194fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f195000-0x00009f197fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f198000-0x00009f198fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f199000-0x00009f1acfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
      >   0x00009f1ad000-0x00009f1affff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b0000-0x00009f1b0fff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
      >   0x00009f1b1000-0x00009fffffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]*
      >   0x000004000000-0x000007ffffff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      >   0x000009010000-0x000009010fff [Memory Mapped I/O  |RUN|  |  |  |   |  |  |  |UC]
      
      The attribute bitmap is now displayed, in decoded form.
      Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      65ba758f
    • Dave Young's avatar
      arm64/efi: Do not enter virtual mode if booting with efi=noruntime or noefi · 6632210f
      Dave Young authored
      In case efi runtime disabled via noefi kernel cmdline
      arm64_enter_virtual_mode should error out.
      
      At the same time move early_memunmap(memmap.map, mapsize) to the
      beginning of the function or it will leak early mem.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      6632210f
    • Dave Young's avatar
      arm64/efi: uefi_init error handling fix · 88f8abd5
      Dave Young authored
      There's one early memmap leak in uefi_init error path, fix it and
      slightly tune the error handling code.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Acked-by: default avatarMark Salter <msalter@redhat.com>
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      88f8abd5
    • Uwe Kleine-König's avatar
      ARM64: make of_device_ids const · c8fdd497
      Uwe Kleine-König authored
      of_device_ids (i.e. compatible strings and the respective data) are not
      supposed to change at runtime. All functions working with of_device_ids
      provided by <linux/of.h> work with const of_device_ids. So mark the
      only non-const struct in arch/arm64 as const, too.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      c8fdd497
  10. 02 Oct, 2014 1 commit
  11. 30 Sep, 2014 1 commit
  12. 26 Sep, 2014 2 commits