linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/2] ARM: decouple CPU offlining from reboot/shutdown
Date: Thu, 13 Jun 2013 08:45:51 +0100	[thread overview]
Message-ID: <20130613074551.GA7769@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1371067281-655-2-git-send-email-swarren@wwwdotorg.org>

Hi Stephen,

On Wed, Jun 12, 2013 at 09:01:21PM +0100, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> Add comments to machine_shutdown()/halt()/power_off()/restart() that
> describe their purpose and/or requirements re: CPUs being active/not.
> 
> In machine_shutdown(), replace the call to smp_send_stop() with a call to
> disable_nonboot_cpus(). This completely disables all but one CPU, thus
> satisfying the requirement that only a single CPU be active for kexec.
> Adjust Kconfig dependencies for this change.
> 
> In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
> rather than via machine_shutdown(); these functions don't need to
> completely de-activate all CPUs using hotplug, but rather just quiesce
> them.
> 
> Remove smp_kill_cpus(), and its call from smp_send_stop().
> smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
> smp_ops.cpu_die() on the target CPUs first. At least some implementations
> of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
> for example. Since smp_send_stop() is only used for shutdown, halt, and
> power-off, there is no need to attempt any kind of CPU hotplug here.
> 
> Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
> relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
> that hotplug will work, or even that hotplug is implemented for a
> particular piece of HW that a multi-platform zImage runs on. Hence, add
> error-checking to machine_kexec() to determine whether it did work.

[...]

> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 282de48..6e8931c 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -184,30 +184,61 @@ int __init reboot_setup(char *str)
>  
>  __setup("reboot=", reboot_setup);
>  
> +/*
> + * Called by kexec, immediately prior to machine_kexec().
> + *
> + * This must completely disable all secondary CPUs; simply causing those CPUs
> + * to execute e.g. a RAM-based pin loop is not sufficient. This allows the
> + * kexec'd kernel to use any and all RAM as it sees fit, without having to
> + * avoid any code or data used by any SW CPU pin loop. The CPU hotplug
> + * functionality embodied in disable_nonboot_cpus() to achieve this.
> + */
>  void machine_shutdown(void)
>  {
> -#ifdef CONFIG_SMP
> -	smp_send_stop();
> -#endif
> +	disable_nonboot_cpus();
>  }

Any reason not to move this into machine_kexec and leave machine_shutdown
as a nop?

Anyway, I'm on holiday without internet until Tuesday, so for these two
patches:

  Acked-by: Will Deacon <will.deacon@arm.com>

Will

  parent reply	other threads:[~2013-06-13  7:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12 20:01 [PATCH V2 1/2] kexec: return error of machine_kexec() fails Stephen Warren
2013-06-12 20:01 ` [PATCH V2 2/2] ARM: decouple CPU offlining from reboot/shutdown Stephen Warren
2013-06-13  1:58   ` zhangfei gao
2013-06-13 15:05     ` Stephen Warren
2013-06-13  7:45   ` Will Deacon [this message]
2013-06-13 14:59     ` Stephen Warren
2013-06-13 17:11       ` Russell King - ARM Linux
2013-06-14  4:53         ` zhangfei gao
2013-06-13 17:10     ` Russell King - ARM Linux
2013-06-17 18:58   ` Stephen Warren
2013-06-17 19:41     ` Russell King - ARM Linux
2013-06-21 22:41 ` [PATCH V2 1/2] kexec: return error of machine_kexec() fails Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130613074551.GA7769@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).