1. 01 Aug, 2014 1 commit
    • Mark Rutland's avatar
      arm64: add newline to I-cache policy string · ea171967
      Mark Rutland authored
      Due to a missing newline in the I-cache policy detection log output,
      it's possible to get some ratehr unfortunate output at boot time:
      
      CPU1: Booted secondary processor
      Detected VIPT I-cache on CPU1CPU2: Booted secondary processor
      Detected VIPT I-cache on CPU2CPU3: Booted secondary processor
      Detected VIPT I-cache on CPU3CPU4: Booted secondary processor
      Detected PIPT I-cache on CPU4CPU5: Booted secondary processor
      Detected PIPT I-cache on CPU5Brought up 6 CPUs
      SMP: Total of 6 processors activated.
      
      This patch adds the missing newline to the format string, cleaning up
      the output.
      
      Fixes: 59ccc0d4 ("arm64: cachetype: report weakest cache policy")
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      ea171967
  2. 31 Jul, 2014 3 commits
  3. 30 Jul, 2014 1 commit
    • Arun Chandran's avatar
      arm64: vdso: fix build error when switching from LE to BE · 1915e2ad
      Arun Chandran authored
      Building a kernel with CPU_BIG_ENDIAN fails if there are stale objects
      from a !CPU_BIG_ENDIAN build. Due to a missing FORCE prerequisite on an
      if_changed rule in the VDSO Makefile, we attempt to link a stale LE
      object into the new BE kernel.
      
      According to Documentation/kbuild/makefiles.txt, FORCE is required for
      if_changed rules and forgetting it is a common mistake, so fix it by
      'Forcing' the build of vdso. This patch fixes build errors like these:
      
      arch/arm64/kernel/vdso/note.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/note.o
      
      arch/arm64/kernel/vdso/sigreturn.o: compiled for a little endian system and target is big endian
      failed to merge target specific data of file arch/arm64/kernel/vdso/sigreturn.o
      Tested-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarArun Chandran <achandran@mvista.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      1915e2ad
  4. 25 Jul, 2014 1 commit
  5. 24 Jul, 2014 1 commit
  6. 23 Jul, 2014 5 commits
  7. 21 Jul, 2014 1 commit
  8. 18 Jul, 2014 7 commits
    • Mark Rutland's avatar
      arm64: cpuinfo: print info for all CPUs · d7a49086
      Mark Rutland authored
      Currently reading /proc/cpuinfo will result in information being read
      out of the MIDR_EL1 of the current CPU, and the information is not
      associated with any particular logical CPU number.
      
      This is problematic for systems with heterogeneous CPUs (i.e.
      big.LITTLE) where MIDR fields will vary across CPUs, and the output will
      differ depending on the executing CPU.
      
      This patch reorganises the code responsible for /proc/cpuinfo to print
      information per-cpu. In the process, we perform several cleanups:
      
      * Property names are coerced to lower-case (to match "processor" as per
        glibc's expectations).
      * Property names are simplified and made to match the MIDR field names.
      * Revision is changed to hex as with every other field.
      * The meaningless Architecture property is removed.
      * The ripe-for-abuse Machine field is removed.
      
      The features field (a human-readable representation of the hwcaps)
      remains printed once, as this is expected to remain in use as the
      globally support CPU features. To enable the possibility of the addition
      of per-cpu HW feature information later, this is printed before any
      CPU-specific information.
      
      Comments are added to guide userspace developers in the right direction
      (using the hwcaps provided in auxval). Hopefully where userspace
      applications parse /proc/cpuinfo rather than using the readily available
      hwcaps, they limit themselves to reading said first line.
      
      If CPU features differ from each other, the previously installed sanity
      checks will give us some advance notice with warnings and
      TAINT_CPU_OUT_OF_SPEC. If we are lucky, we will never see such systems.
      Rework will be required in many places to support such systems anyway.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      [catalin.marinas@arm.com: remove machine_name as it is no longer reported]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      d7a49086
    • Mark Rutland's avatar
      arm64: add runtime system sanity checks · 127161aa
      Mark Rutland authored
      Unexpected variation in certain system register values across CPUs is an
      indicator of potential problems with a system. The kernel expects CPUs
      to be mostly identical in terms of supported features, even in systems
      with heterogeneous CPUs, with uniform instruction set support being
      critical for the correct operation of userspace.
      
      To help detect issues early where hardware violates the expectations of
      the kernel, this patch adds simple runtime sanity checks on important ID
      registers in the bring up path of each CPU.
      
      Where CPUs are fundamentally mismatched, set TAINT_CPU_OUT_OF_SPEC.
      Given that the kernel assumes CPUs are identical feature wise, let's not
      pretend that we expect such configurations to work. Supporting such
      configurations would require massive rework, and hopefully they will
      never exist.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      127161aa
    • Mark Rutland's avatar
      arm64: cachetype: report weakest cache policy · 59ccc0d4
      Mark Rutland authored
      In big.LITTLE systems, the I-cache policy may differ across CPUs, and
      thus we must always meet the most stringent maintenance requirements of
      any I-cache in the system when performing maintenance to ensure
      correctness. Unfortunately this requirement is not met as we always look
      at the current CPU's cache type register to determine the maintenance
      requirements.
      
      This patch causes the I-cache policy of all CPUs to be taken into
      account for icache_is_aliasing and icache_is_aivivt. If any I-cache in
      the system is aliasing or AIVIVT, the respective function will return
      true. At boot each CPU may set flags to identify that at least one
      I-cache in the system is aliasing and/or AIVIVT.
      
      The now unused and potentially misleading icache_policy function is
      removed.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      59ccc0d4
    • Mark Rutland's avatar
      arm64: cpuinfo: record cpu system register values · df857416
      Mark Rutland authored
      Several kernel subsystems need to know details about CPU system register
      values, sometimes for CPUs other than that they are executing on. Rather
      than hard-coding system register accesses and cross-calls for these
      cases, this patch adds logic to record various system register values at
      boot-time. This may be used for feature reporting, firmware bug
      detection, etc.
      
      Separate hooks are added for the boot and hotplug paths to enable
      one-time intialisation and cold/warm boot value mismatch detection in
      later patches.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Reviewed-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      df857416
    • Lorenzo Pieralisi's avatar
      arm64: kernel: add missing __init section marker to cpu_suspend_init · 18ab7db6
      Lorenzo Pieralisi authored
      Suspend init function must be marked as __init, since it is not needed
      after the kernel has booted. This patch moves the cpu_suspend_init()
      function to the __init section.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      18ab7db6
    • Lorenzo Pieralisi's avatar
      arm64: kernel: add __init marker to PSCI init functions · b9e97ef9
      Lorenzo Pieralisi authored
      PSCI init functions must be marked as __init so that they are freed
      by the kernel upon boot.
      
      This patch marks the PSCI init functions as such since they need not
      be persistent in the kernel address space after the kernel has booted.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      b9e97ef9
    • Lorenzo Pieralisi's avatar
      arm64: kernel: enable PSCI cpu operations on UP systems · 756854d9
      Lorenzo Pieralisi authored
      PSCI CPU operations have to be enabled on UP kernels so that calls
      like eg cpu_suspend can be made functional on UP too.
      
      This patch reworks the PSCI CPU operations so that they can be
      enabled on UP systems.
      Acked-by: default avatarMark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      756854d9
  9. 17 Jul, 2014 5 commits
  10. 10 Jul, 2014 8 commits
    • Mark Rutland's avatar
      arm64: Enable TEXT_OFFSET fuzzing · da57a369
      Mark Rutland authored
      The arm64 Image header contains a text_offset field which bootloaders
      are supposed to read to determine the offset (from a 2MB aligned "start
      of memory" per booting.txt) at which to load the kernel. The offset is
      not well respected by bootloaders at present, and due to the lack of
      variation there is little incentive to support it. This is unfortunate
      for the sake of future kernels where we may wish to vary the text offset
      (even zeroing it).
      
      This patch adds options to arm64 to enable fuzz-testing of text_offset.
      CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET forces the text offset to a random
      16-byte aligned value value in the range [0..2MB) upon a build of the
      kernel. It is recommended that distribution kernels enable randomization
      to test bootloaders such that any compliance issues can be fixed early.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarTom Rini <trini@ti.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      da57a369
    • Mark Rutland's avatar
      arm64: Update the Image header · a2c1d73b
      Mark Rutland authored
      Currently the kernel Image is stripped of everything past the initial
      stack, and at runtime the memory is initialised and used by the kernel.
      This makes the effective minimum memory footprint of the kernel larger
      than the size of the loaded binary, though bootloaders have no mechanism
      to identify how large this minimum memory footprint is. This makes it
      difficult to choose safe locations to place both the kernel and other
      binaries required at boot (DTB, initrd, etc), such that the kernel won't
      clobber said binaries or other reserved memory during initialisation.
      
      Additionally when big endian support was added the image load offset was
      overlooked, and is currently of an arbitrary endianness, which makes it
      difficult for bootloaders to make use of it. It seems that bootloaders
      aren't respecting the image load offset at present anyway, and are
      assuming that offset 0x80000 will always be correct.
      
      This patch adds an effective image size to the kernel header which
      describes the amount of memory from the start of the kernel Image binary
      which the kernel expects to use before detecting memory and handling any
      memory reservations. This can be used by bootloaders to choose suitable
      locations to load the kernel and/or other binaries such that the kernel
      will not clobber any memory unexpectedly. As before, memory reservations
      are required to prevent the kernel from clobbering these locations
      later.
      
      Both the image load offset and the effective image size are forced to be
      little-endian regardless of the native endianness of the kernel to
      enable bootloaders to load a kernel of arbitrary endianness. Bootloaders
      which wish to make use of the load offset can inspect the effective
      image size field for a non-zero value to determine if the offset is of a
      known endianness. To enable software to determine the endinanness of the
      kernel as may be required for certain use-cases, a new flags field (also
      little-endian) is added to the kernel header to export this information.
      
      The documentation is updated to clarify these details. To discourage
      future assumptions regarding the value of text_offset, the value at this
      point in time is removed from the main flow of the documentation (though
      kept as a compatibility note). Some minor formatting issues in the
      documentation are also corrected.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarTom Rini <trini@ti.com>
      Cc: Geoff Levand <geoff@infradead.org>
      Cc: Kevin Hilman <kevin.hilman@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      a2c1d73b
    • Mark Rutland's avatar
      arm64: place initial page tables above the kernel · bd00cd5f
      Mark Rutland authored
      Currently we place swapper_pg_dir and idmap_pg_dir below the kernel
      image, between PHYS_OFFSET and (PHYS_OFFSET + TEXT_OFFSET). However,
      bootloaders may use portions of this memory below the kernel and we do
      not parse the memory reservation list until after the MMU has been
      enabled. As such we may clobber some memory a bootloader wishes to have
      preserved.
      
      To enable the use of all of this memory by bootloaders (when the
      required memory reservations are communicated to the kernel) it is
      necessary to move our initial page tables elsewhere. As we currently
      have an effectively unbound requirement for memory at the end of the
      kernel image for .bss, we can place the page tables here.
      
      This patch moves the initial page table to the end of the kernel image,
      after the BSS. As they do not consist of any initialised data they will
      be stripped from the kernel Image as with the BSS. The BSS clearing
      routine is updated to stop at __bss_stop rather than _end so as to not
      clobber the page tables, and memory reservations made redundant by the
      new organisation are removed.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      bd00cd5f
    • Mark Rutland's avatar
      arm64: head.S: remove unnecessary function alignment · 909a4069
      Mark Rutland authored
      Currently __turn_mmu_on is aligned to 64 bytes to ensure that it doesn't
      span any page boundary, which simplifies the idmap and spares us
      requiring an additional page table to map half of the function. In
      keeping with other important requirements in architecture code, this
      fact is undocumented.
      
      Additionally, as the function consists of three instructions totalling
      12 bytes with no literal pool data, a smaller alignment of 16 bytes
      would be sufficient.
      
      This patch reduces the alignment to 16 bytes and documents the
      underlying reason for the alignment. This reduces the required alignment
      of the entire .head.text section from 64 bytes to 16 bytes, though it
      may still be aligned to a larger value depending on TEXT_OFFSET.
      Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
      Tested-by: default avatarLaura Abbott <lauraa@codeaurora.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      909a4069
    • AKASHI Takahiro's avatar
      arm64: audit: Add audit hook in syscall_trace_enter/exit() · 5701ede8
      AKASHI Takahiro authored
      This patch adds auditing functions on entry to or exit from
      every system call invocation.
      Acked-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Acked-by Will Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarAKASHI Takahiro <takahiro.akashi@linaro.org>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      5701ede8
    • Catalin Marinas's avatar
      arm64: Add __NR_* definitions for compat syscalls · f3e5c847
      Catalin Marinas authored
      This patch adds __NR_* definitions to asm/unistd32.h, moves the
      __NR_compat_* definitions to asm/unistd.h and removes all the explicit
      unistd32.h includes apart from the one building the compat syscall
      table. The aim is to have the compat __NR_* definitions available but
      without colliding with the native syscall definitions (required by
      lib/compat_audit.c to avoid duplicating the audit header files between
      native and compat).
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      f3e5c847
    • Larry Bassel's avatar
      arm64: enable context tracking · 6c81fe79
      Larry Bassel authored
      Make calls to ct_user_enter when the kernel is exited
      and ct_user_exit when the kernel is entered (in el0_da,
      el0_ia, el0_svc, el0_irq and all of the "error" paths).
      
      These macros expand to function calls which will only work
      properly if el0_sync and related code has been rearranged
      (in a previous patch of this series).
      
      The calls to ct_user_exit are made after hw debugging has been
      enabled (enable_dbg_and_irq).
      
      The call to ct_user_enter is made at the beginning of the
      kernel_exit macro.
      
      This patch is based on earlier work by Kevin Hilman.
      Save/restore optimizations were also done by Kevin.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarKevin Hilman <khilman@linaro.org>
      Tested-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarLarry Bassel <larry.bassel@linaro.org>
      Signed-off-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6c81fe79
    • Larry Bassel's avatar
      arm64: adjust el0_sync so that a function can be called · 6ab6463a
      Larry Bassel authored
      To implement the context tracker properly on arm64,
      a function call needs to be made after debugging and
      interrupts are turned on, but before the lr is changed
      to point to ret_to_user(). If the function call
      is made after the lr is changed the function will not
      return to the correct place.
      
      For similar reasons, defer the setting of x0 so that
      it doesn't need to be saved around the function call
      (save far_el1 in x26 temporarily instead).
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Reviewed-by: default avatarKevin Hilman <khilman@linaro.org>
      Tested-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarLarry Bassel <larry.bassel@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6ab6463a
  11. 09 Jul, 2014 2 commits
  12. 08 Jul, 2014 1 commit
  13. 04 Jul, 2014 1 commit
  14. 18 Jun, 2014 3 commits