[RFC PATCH 3.7.0-rc4] ARM:smp: introduce smp_notify_cpu_stop to fix kexec smp case
Will Deacon
will.deacon at arm.com
Mon Nov 19 05:58:48 EST 2012
On Fri, Nov 16, 2012 at 08:39:19AM +0000, Srinivas KANDAGATLA wrote:
> On 15/11/12 21:18, Will Deacon wrote:
> >
> > 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.
>
> Yes I agree and understand the limitation.
> The callback should simple and just relocate the secondary core to a
> safe place which in our case is a holding pen, which is safe and not in
> the system ram.
> After the callback, the secondary core will be spinning in the holding
> pen which will be released once they get a matching cpu-id.
> And this approach works perfectly ok on our chips and I guess should
> work for other chips aswell.
But how do you know when the callback is complete? That's the part that is
tricky as you need to avoid clobbering the kernel image before you know for
sure that all the secondaries are out of the way. I think you either need
some horrible homebrew locking primitives or something in hardware to signal
back to the primary CPU.
> > If you can solve the synchronisation problem then we can think about adding
> > these hooks.
>
> I think the call back code should not do anything complex other than few
> lines of assembly or jump to a holding pen, this way it does not need
> any synchronization calls or system infrastructure.
See above.
Will
More information about the linux-arm-kernel
mailing list