1. 12 Jul, 2018 20 commits
  2. 11 Jul, 2018 2 commits
  3. 10 Jul, 2018 1 commit
    • Arnd Bergmann's avatar
      arm64: make flatmem depend on !NUMA · 54501ac1
      Arnd Bergmann authored
      Building without NUMA but with FLATMEM results in a link error
      because mem_map[] is not available:
      
      aarch64-linux-ld -EB -maarch64elfb --no-undefined -X -pie -shared -Bsymbolic --no-apply-dynamic-relocs --build-id -o .tmp_vmlinux1 -T ./arch/arm64/kernel/vmlinux.lds --whole-archive built-in.a --no-whole-archive --start-group arch/arm64/lib/lib.a lib/lib.a --end-group
      init/do_mounts.o: In function `mount_block_root':
      do_mounts.c:(.init.text+0x1e8): undefined reference to `mem_map'
      arch/arm64/kernel/vdso.o: In function `vdso_init':
      vdso.c:(.init.text+0xb4): undefined reference to `mem_map'
      
      This uses the same trick as the other architectures, making flatmem
      depend on !NUMA to avoid the broken configuration.
      
      Fixes: e7d4bac4 ("arm64: add ARM64-specific support for flatmem")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      54501ac1
  4. 09 Jul, 2018 3 commits
    • Lorenzo Pieralisi's avatar
      arm64: numa: rework ACPI NUMA initialization · e1896249
      Lorenzo Pieralisi authored
      Current ACPI ARM64 NUMA initialization code in
      
      acpi_numa_gicc_affinity_init()
      
      carries out NUMA nodes creation and cpu<->node mappings at the same time
      in the arch backend so that a single SRAT walk is needed to parse both
      pieces of information.  This implies that the cpu<->node mappings must
      be stashed in an array (sized NR_CPUS) so that SMP code can later use
      the stashed values to avoid another SRAT table walk to set-up the early
      cpu<->node mappings.
      
      If the kernel is configured with a NR_CPUS value less than the actual
      processor entries in the SRAT (and MADT), the logic in
      acpi_numa_gicc_affinity_init() is broken in that the cpu<->node mapping
      is only carried out (and stashed for future use) only for a number of
      SRAT entries up to NR_CPUS, which do not necessarily correspond to the
      possible cpus detected at SMP initialization in
      acpi_map_gic_cpu_interface() (ie MADT and SRAT processor entries order
      is not enforced), which leaves the kernel with broken cpu<->node
      mappings.
      
      Furthermore, given the current ACPI NUMA code parsing logic in
      acpi_numa_gicc_affinity_init(), PXM domains for CPUs that are not parsed
      because they exceed NR_CPUS entries are not mapped to NUMA nodes (ie the
      PXM corresponding node is not created in the kernel) leaving the system
      with a broken NUMA topology.
      
      Rework the ACPI ARM64 NUMA initialization process so that the NUMA
      nodes creation and cpu<->node mappings are decoupled. cpu<->node
      mappings are moved to SMP initialization code (where they are needed),
      at the cost of an extra SRAT walk so that ACPI NUMA mappings can be
      batched before being applied, fixing current parsing pitfalls.
      Acked-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Tested-by: default avatarJohn Garry <john.garry@huawei.com>
      Fixes: d8b47fca ("arm64, ACPI, NUMA: NUMA support based on SRAT and
      SLIT")
      Link: http://lkml.kernel.org/r/1527768879-88161-2-git-send-email-xiexiuqi@huawei.comReported-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Punit Agrawal <punit.agrawal@arm.com>
      Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Hanjun Guo <guohanjun@huawei.com>
      Cc: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Xie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e1896249
    • Nikunj Kela's avatar
      arm64: add ARM64-specific support for flatmem · e7d4bac4
      Nikunj Kela authored
      Flatmem is useful in reducing kernel memory usage.
      One usecase is in kdump kernel. We are able to save
      ~14M by moving to flatmem scheme.
      
      Cc: xe-kernel@external.cisco.com
      Cc: Nikunj Kela <nkela@cisco.com>
      Signed-off-by: default avatarNikunj Kela <nkela@cisco.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      e7d4bac4
    • Will Deacon's avatar
      MAINTAINERS: arm64: Remove boot/dts/ directory from arm64 entry · d7c7118c
      Will Deacon authored
      The arm-soc tree does a good job handling .dts files, so exclude them
      from the ARM64 entry in MAINTAINERS.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      d7c7118c
  5. 06 Jul, 2018 12 commits
  6. 05 Jul, 2018 2 commits
    • Will Deacon's avatar
      arm64: insn: Don't fallback on nosync path for general insn patching · 693350a7
      Will Deacon authored
      Patching kernel instructions at runtime requires other CPUs to undergo
      a context synchronisation event via an explicit ISB or an IPI in order
      to ensure that the new instructions are visible. This is required even
      for "hotpatch" instructions such as NOP and BL, so avoid optimising in
      this case and always go via stop_machine() when performing general
      patching.
      
      ftrace isn't quite as strict, so it can continue to call the nosync
      code directly.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      693350a7
    • Will Deacon's avatar
      arm64: IPI each CPU after invalidating the I-cache for kernel mappings · 3b8c9f1c
      Will Deacon authored
      When invalidating the instruction cache for a kernel mapping via
      flush_icache_range(), it is also necessary to flush the pipeline for
      other CPUs so that instructions fetched into the pipeline before the
      I-cache invalidation are discarded. For example, if module 'foo' is
      unloaded and then module 'bar' is loaded into the same area of memory,
      a CPU could end up executing instructions from 'foo' when branching into
      'bar' if these instructions were fetched into the pipeline before 'foo'
      was unloaded.
      
      Whilst this is highly unlikely to occur in practice, particularly as
      any exception acts as a context-synchronizing operation, following the
      letter of the architecture requires us to execute an ISB on each CPU
      in order for the new instruction stream to be visible.
      Acked-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      3b8c9f1c