From: geoff@infradead.org (Geoff Levand)
To: linux-arm-kernel@lists.infradead.org
Subject: Kexec on arm64
Date: Mon, 28 Jul 2014 17:09:08 -0700 [thread overview]
Message-ID: <1406592548.28348.49.camel@smoke> (raw)
In-Reply-To: <20140728153812.GA2576@leverpostej>
Hi,
On Mon, 2014-07-28 at 16:38 +0100, Mark Rutland wrote:
> On Mon, Jul 28, 2014 at 04:00:18PM +0100, Arun Chandran wrote:
> > I have these changes to the code.
> > flush_icache_range((unsigned long)reboot_code_buffer,
> > - relocate_new_kernel_size);
> > + (unsigned long)(reboot_code_buffer + relocate_new_kernel_size));
Thanks, I introduced this in my last version in an attempt to clean up
the code, but on studying setup_restart(), I wonder if we even need to
do this icache flush here (see below).
> > /*
> > * Flush any data used by relocate_new_kernel in preparation for
> > #########
> > Passing of second variable to flush_icache_range() is wrong
> > it expects an address not length.
>
> A simpler option would be to nuke the entire icache before branching to
> the new image.
flush_cache_all(), which is called by setup_restart(), does a 'ic
ialluis'. The ARM says that this will invalidate all instruction caches
for the inner shareable domain. Do we need something more?
> > 2)
> >
> > #######
> > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > index 9ed7327..e3fc8d6 100644
> > --- a/arch/arm64/kernel/process.c
> > +++ b/arch/arm64/kernel/process.c
> >
> > @@ -84,12 +91,17 @@ void soft_restart(unsigned long addr)
> > {
> > typedef void (*phys_reset_t)(unsigned long);
> > phys_reset_t phys_reset;
> > + unsigned long jump_addr = addr;
> > +
> > + phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
> > +
> > + __flush_dcache_area(&jump_addr, 8);
> > + __flush_dcache_area(&phys_reset, 8);
>
> Are these values really not getting stashed in registers?
Looking at the disassembled code of soft_restart() from my compiler,
addr is being saved on the stack over the call to setup_restart(), which
I would expect it to do.
> If the compiler is spilling, then we have absolutely no guarantee about
> any part of the stack. If that's the case, then we can't use the stack
> at all. These need to be rewritten in asm if the compiler is spilling.
I think we just need to put the restart addr in a variable and flush
that to the PoC.
Arun, I pushed out a fixed version of soft_restart(), so please try
another UP + L3 boot.
-Geoff
next prev parent reply other threads:[~2014-07-29 0:09 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAFdej006OSyhgDcJ2iZdbjt+PtysN=i_+9Dr4GTmr=+t5yg4Kw@mail.gmail.com>
2014-07-15 17:04 ` Kexec on arm64 Geoff Levand
2014-07-16 17:57 ` Feng Kan
2014-07-16 23:04 ` Geoff Levand
2014-07-22 9:44 ` Arun Chandran
2014-07-22 13:25 ` Arun Chandran
2014-07-24 0:38 ` Geoff Levand
2014-07-24 9:36 ` Mark Rutland
2014-07-24 12:49 ` Arun Chandran
2014-07-25 0:17 ` Geoff Levand
2014-07-25 10:31 ` Arun Chandran
2014-07-25 10:36 ` Mark Rutland
2014-07-25 11:48 ` Arun Chandran
2014-07-25 12:14 ` Mark Rutland
2014-07-25 15:29 ` Arun Chandran
2014-07-26 0:18 ` Geoff Levand
2014-07-28 15:00 ` Arun Chandran
2014-07-28 15:38 ` Mark Rutland
2014-07-29 0:09 ` Geoff Levand [this message]
2014-07-29 9:10 ` Mark Rutland
2014-07-29 12:32 ` Arun Chandran
2014-07-29 13:35 ` Mark Rutland
2014-07-29 21:19 ` Geoff Levand
2014-07-30 7:22 ` Arun Chandran
2014-08-01 11:13 ` Arun Chandran
2014-08-03 14:47 ` Mark Rutland
2014-08-04 10:16 ` Arun Chandran
2014-08-04 11:35 ` Mark Rutland
2014-08-07 0:40 ` Geoff Levand
2014-08-07 9:59 ` Mark Rutland
2014-08-07 17:09 ` Geoff Levand
2014-08-04 17:21 ` Geoff Levand
2014-08-06 13:54 ` Arun Chandran
2014-08-06 15:51 ` Arun Chandran
2014-08-07 20:07 ` Geoff Levand
2014-08-08 5:46 ` Arun Chandran
2014-08-08 10:03 ` Arun Chandran
2014-08-12 5:42 ` Arun Chandran
2014-08-13 11:09 ` Arun Chandran
2014-08-26 22:32 ` Geoff Levand
2014-08-27 4:56 ` Arun Chandran
2014-07-30 5:46 ` Arun Chandran
2014-07-30 9:16 ` Mark Rutland
2014-07-30 7:01 ` Arun Chandran
2014-07-25 10:26 ` Arun Chandran
2014-07-25 11:29 ` Mark Rutland
2014-07-24 11:50 ` Arun Chandran
2014-07-30 3:26 ` Feng Kan
2014-07-24 0:10 ` Geoff Levand
2014-07-24 9:13 ` Mark Rutland
2014-07-09 10:13 Arun Chandran
2014-07-09 13:58 ` Arun Chandran
2014-07-09 18:49 ` Geoff Levand
2014-07-11 9:23 ` Arun Chandran
2014-07-11 16:58 ` Geoff Levand
2014-07-11 11:26 ` Arun Chandran
2014-07-12 0:19 ` Geoff Levand
2014-07-14 12:21 ` Arun Chandran
2014-07-11 15:43 ` Arun Chandran
2014-07-14 22:05 ` Geoff Levand
2014-07-15 15:28 ` Arun Chandran
2014-07-09 18:33 ` Geoff Levand
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=1406592548.28348.49.camel@smoke \
--to=geoff@infradead.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.