1. 28 Apr, 2016 2 commits
  2. 29 Feb, 2016 1 commit
  3. 25 Feb, 2016 1 commit
    • 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
  4. 04 Jan, 2016 1 commit
  5. 14 Dec, 2015 2 commits
  6. 07 Oct, 2015 1 commit
    • Will Deacon's avatar
      arm64: mm: rewrite ASID allocator and MM context-switching code · 5aec715d
      Will Deacon authored
      Our current switch_mm implementation suffers from a number of problems:
      
        (1) The ASID allocator relies on IPIs to synchronise the CPUs on a
            rollover event
      
        (2) Because of (1), we cannot allocate ASIDs with interrupts disabled
            and therefore make use of a TIF_SWITCH_MM flag to postpone the
            actual switch to finish_arch_post_lock_switch
      
        (3) We run context switch with a reserved (invalid) TTBR0 value, even
            though the ASID and pgd are updated atomically
      
        (4) We take a global spinlock (cpu_asid_lock) during context-switch
      
        (5) We use h/w broadcast TLB operations when they are not required
            (e.g. in flush_context)
      
      This patch addresses these problems by rewriting the ASID algorithm to
      match the bitmap-based arch/arm/ implementation more closely. This in
      turn allows us to remove much of the complications surrounding switch_mm,
      including the ugly thread flag.
      Reviewed-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      5aec715d
  7. 12 Aug, 2015 1 commit
  8. 21 Jul, 2015 2 commits
    • Alex Bennée's avatar
      KVM: arm64: introduce vcpu->arch.debug_ptr · 84e690bf
      Alex Bennée authored
      This introduces a level of indirection for the debug registers. Instead
      of using the sys_regs[] directly we store registers in a structure in
      the vcpu. The new kvm_arm_reset_debug_ptr() sets the debug ptr to the
      guest context.
      
      Because we no longer give the sys_regs offset for the sys_reg_desc->reg
      field, but instead the index into a debug-specific struct we need to
      add a number of additional trap functions for each register. Also as the
      generic generic user-space access code no longer works we have
      introduced a new pair of function pointers to the sys_reg_desc structure
      to override the generic code when needed.
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      84e690bf
    • Alex Bennée's avatar
      KVM: arm: introduce kvm_arm_init/setup/clear_debug · 56c7f5e7
      Alex Bennée authored
      This is a precursor for later patches which will need to do more to
      setup debug state before entering the hyp.S switch code. The existing
      functionality for setting mdcr_el2 has been moved out of hyp.S and now
      uses the value kept in vcpu->arch.mdcr_el2.
      
      As the assembler used to previously mask and preserve MDCR_EL2.HPMN I've
      had to add a mechanism to save the value of mdcr_el2 as a per-cpu
      variable during the initialisation code. The kernel never sets this
      number so we are assuming the bootcode has set up the correct value
      here.
      
      This also moves the conditional setting of the TDA bit from the hyp code
      into the C code which is currently used for the lazy debug register
      context switch code.
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      56c7f5e7
  9. 12 Jun, 2015 1 commit
  10. 12 Apr, 2015 1 commit
  11. 19 Mar, 2015 1 commit
  12. 27 Jan, 2015 1 commit
    • Lorenzo Pieralisi's avatar
      arm64: kernel: remove ARM64_CPU_SUSPEND config option · af3cfdbf
      Lorenzo Pieralisi authored
      ARM64_CPU_SUSPEND config option was introduced to make code providing
      context save/restore selectable only on platforms requiring power
      management capabilities.
      
      Currently ARM64_CPU_SUSPEND depends on the PM_SLEEP config option which
      in turn is set by the SUSPEND config option.
      
      The introduction of CPU_IDLE for arm64 requires that code configured
      by ARM64_CPU_SUSPEND (context save/restore) should be compiled in
      in order to enable the CPU idle driver to rely on CPU operations
      carrying out context save/restore.
      
      The ARM64_CPUIDLE config option (ARM64 generic idle driver) is therefore
      forced to select ARM64_CPU_SUSPEND, even if there may be (ie PM_SLEEP)
      failed dependencies, which is not a clean way of handling the kernel
      configuration option.
      
      For these reasons, this patch removes the ARM64_CPU_SUSPEND config option
      and makes the context save/restore dependent on CPU_PM, which is selected
      whenever either SUSPEND or CPU_IDLE are configured, cleaning up dependencies
      in the process.
      
      This way, code previously configured through ARM64_CPU_SUSPEND is
      compiled in whenever a power management subsystem requires it to be
      present in the kernel (SUSPEND || CPU_IDLE), which is the behaviour
      expected on ARM64 kernels.
      
      The cpu_suspend and cpu_init_idle CPU operations are added only if
      CPU_IDLE is selected, since they are CPU_IDLE specific methods and
      should be grouped and defined accordingly.
      
      PSCI CPU operations are updated to reflect the introduced changes.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      af3cfdbf
  13. 20 Jan, 2015 1 commit
  14. 11 Jul, 2014 4 commits
  15. 16 Dec, 2013 1 commit
    • Lorenzo Pieralisi's avatar
      arm64: kernel: cpu_{suspend/resume} implementation · 95322526
      Lorenzo Pieralisi authored
      Kernel subsystems like CPU idle and suspend to RAM require a generic
      mechanism to suspend a processor, save its context and put it into
      a quiescent state. The cpu_{suspend}/{resume} implementation provides
      such a framework through a kernel interface allowing to save/restore
      registers, flush the context to DRAM and suspend/resume to/from
      low-power states where processor context may be lost.
      
      The CPU suspend implementation relies on the suspend protocol registered
      in CPU operations to carry out a suspend request after context is
      saved and flushed to DRAM. The cpu_suspend interface:
      
      int cpu_suspend(unsigned long arg);
      
      allows to pass an opaque parameter that is handed over to the suspend CPU
      operations back-end so that it can take action according to the
      semantics attached to it. The arg parameter allows suspend to RAM and CPU
      idle drivers to communicate to suspend protocol back-ends; it requires
      standardization so that the interface can be reused seamlessly across
      systems, paving the way for generic drivers.
      
      Context memory is allocated on the stack, whose address is stashed in a
      per-cpu variable to keep track of it and passed to core functions that
      save/restore the registers required by the architecture.
      
      Even though, upon successful execution, the cpu_suspend function shuts
      down the suspending processor, the warm boot resume mechanism, based
      on the cpu_resume function, makes the resume path operate as a
      cpu_suspend function return, so that cpu_suspend can be treated as a C
      function by the caller, which simplifies coding the PM drivers that rely
      on the cpu_suspend API.
      
      Upon context save, the minimal amount of memory is flushed to DRAM so
      that it can be retrieved when the MMU is off and caches are not searched.
      
      The suspend CPU operation, depending on the required operations (eg CPU vs
      Cluster shutdown) is in charge of flushing the cache hierarchy either
      implicitly (by calling firmware implementations like PSCI) or explicitly
      by executing the required cache maintainance functions.
      
      Debug exceptions are disabled during cpu_{suspend}/{resume} operations
      so that debug registers can be saved and restored properly preventing
      preemption from debug agents enabled in the kernel.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      95322526
  16. 04 Jul, 2013 1 commit
  17. 12 Jun, 2013 1 commit
  18. 17 Sep, 2012 1 commit