From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3.7.0-rc4] ARM:smp: introduce smp_notify_cpu_stop to fix kexec smp case
Date: Thu, 15 Nov 2012 21:18:33 +0000 [thread overview]
Message-ID: <20121115211833.GD13998@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <1353003478-22291-1-git-send-email-srinivas.kandagatla@st.com>
Hello,
On Thu, Nov 15, 2012 at 06:17:58PM +0000, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Use-case is simple kexec on smp system.
>
> Lets say there are two cores core-0 and core-1.
>
> sequence here is:
> As part of kexec call, the secondary cores are stopped by calling
> machine_shutdown(), which in turn issues IPIs to off-line the other CPUs
> and then call smp_ops.cpu_kill.
>
> machine_shutdown invokes smp_send_stop from core-0 which then sends
> IPI_CPU_STOP ipi message for core-1 and then smp_kill_cpus call
> smp_ops.cpu_kill from core-0 with cpu=1.
>
> The expectation here is that cpu_kill will relocate secondary-core
> to safe location from primary-core(core-0).
Not quite. The expectation is actually that you wiggle a line to a power
controller and the secondary core either disappears or resets.
> This is a catch 22 situation for SOCs, which can't change PC's of other
> cores. At the point when cpu_kill is invoked, it cant execute any
> function calls for core-1, as it is off-line and is spinning in
> cpu_relax.
I thought these SoCs were fairly rare in production -- usually there is
some way to power down secondary cores.
> So the only way is to put the core into safe place by executing some
> SOC specific relocation code.
>
> Having a callback from ipi handler when cpu is stopped would be very
> usefull for SOC's which want to relocate the secondary-core to safe
> location.
I thought about this for Versatile Express but even if you do that, your
problems are just beginning. The bigger issue is co-ordinating with the
secondaries so you know when they're safely out of the way and you can
proceed with the kexec. Remember that you won't have working locks and you
can't cross-call a function because it won't actually return.
If you can solve the synchronisation problem then we can think about adding
these hooks.
Will
next prev parent reply other threads:[~2012-11-15 21:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-15 18:17 [RFC PATCH 3.7.0-rc4] ARM:smp: introduce smp_notify_cpu_stop to fix kexec smp case Srinivas KANDAGATLA
2012-11-15 21:18 ` Will Deacon [this message]
2012-11-16 8:39 ` Srinivas KANDAGATLA
2012-11-19 10:58 ` Will Deacon
2012-11-19 12:07 ` Srinivas KANDAGATLA
2012-11-19 12:16 ` Will Deacon
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=20121115211833.GD13998@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).