1. 25 Feb, 2016 4 commits
    • Suzuki K Poulose's avatar
      arm64: Ensure the secondary CPUs have safe ASIDBits size · 13f417f3
      Suzuki K Poulose authored
      Adds a hook for checking whether a secondary CPU has the
      features used already by the kernel during early boot, based
      on the boot CPU and plugs in the check for ASID size.
      
      The ID_AA64MMFR0_EL1:ASIDBits determines the size of the mm context
      id and is used in the early boot to make decisions. The value is
      picked up from the Boot CPU and cannot be delayed until other CPUs
      are up. If a secondary CPU has a smaller size than that of the Boot
      CPU, things will break horribly and the usual SANITY check is not good
      enough to prevent the system from crashing. So, crash the system with
      enough information.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      13f417f3
    • Suzuki K Poulose's avatar
      arm64: Add helper for extracting ASIDBits · 038dc9c6
      Suzuki K Poulose authored
      Add a helper to extract ASIDBits on the current cpu
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      038dc9c6
    • Suzuki K Poulose's avatar
      arm64: Enable CPU capability verification unconditionally · fd9c2790
      Suzuki K Poulose authored
      We verify the capabilities of the secondary CPUs only when
      hotplug is enabled. The boot time activated CPUs do not
      go through the verification by checking whether the system
      wide capabilities were initialised or not.
      
      This patch removes the capability check dependency on CONFIG_HOTPLUG_CPU,
      to make sure that all the secondary CPUs go through the check.
      The boot time activated CPUs will still skip the system wide
      capability check. The plan is to hook in a check for CPU features
      used by the kernel at early boot up, based on the Boot CPU values.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      fd9c2790
    • Suzuki K Poulose's avatar
      arm64: Handle early CPU boot failures · bb905274
      Suzuki K Poulose authored
      A secondary CPU could fail to come online due to insufficient
      capabilities and could simply die or loop in the kernel.
      e.g, a CPU with no support for the selected kernel PAGE_SIZE
      loops in kernel with MMU turned off.
      or a hotplugged CPU which doesn't have one of the advertised
      system capability will die during the activation.
      
      There is no way to synchronise the status of the failing CPU
      back to the master. This patch solves the issue by adding a
      field to the secondary_data which can be updated by the failing
      CPU. If the secondary CPU fails even before turning the MMU on,
      it updates the status in a special variable reserved in the head.txt
      section to make sure that the update can be cache invalidated safely
      without possible sharing of cache write back granule.
      
      Here are the possible states :
      
       -1. CPU_MMU_OFF - Initial value set by the master CPU, this value
      indicates that the CPU could not turn the MMU on, hence the status
      could not be reliably updated in the secondary_data. Instead, the
      CPU has updated the status @ __early_cpu_boot_status.
      
       0. CPU_BOOT_SUCCESS - CPU has booted successfully.
      
       1. CPU_KILL_ME - CPU has invoked cpu_ops->die, indicating the
      master CPU to synchronise by issuing a cpu_ops->cpu_kill.
      
       2. CPU_STUCK_IN_KERNEL - CPU couldn't invoke die(), instead is
      looping in the kernel. This information could be used by say,
      kexec to check if it is really safe to do a kexec reboot.
      
       3. CPU_PANIC_KERNEL - CPU detected some serious issues which
      requires kernel to crash immediately. The secondary CPU cannot
      call panic() until it has initialised the GIC. This flag can
      be used to instruct the master to do so.
      
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSuzuki K Poulose <suzuki.poulose@arm.com>
      [catalin.marinas@arm.com: conflict resolution]
      [catalin.marinas@arm.com: converted "status" from int to long]
      [catalin.marinas@arm.com: updated update_early_cpu_boot_status to use str_l]
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      bb905274
  2. 24 Feb, 2016 17 commits
  3. 23 Feb, 2016 3 commits
  4. 19 Feb, 2016 1 commit
  5. 18 Feb, 2016 15 commits