From: achandran@mvista.com (Arun Chandran)
To: linux-arm-kernel@lists.infradead.org
Subject: Kexec on arm64
Date: Fri, 25 Jul 2014 20:59:08 +0530 [thread overview]
Message-ID: <CAFdej028aK_hopC906JY_FPSHtRiYwqH3ee2eJq3bRiOuVXGqg@mail.gmail.com> (raw)
In-Reply-To: <20140725121448.GB19632@leverpostej>
On Fri, Jul 25, 2014 at 5:44 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Jul 25, 2014 at 12:48:04PM +0100, Arun Chandran wrote:
>> Hi Geoff,
>>
>> On Fri, Jul 25, 2014 at 5:47 AM, Geoff Levand <geoff@infradead.org> wrote:
>> > Hi,
>> >
>> > On Thu, 2014-07-24 at 10:36 +0100, Mark Rutland wrote:
>> >> On Thu, Jul 24, 2014 at 01:38:07AM +0100, Geoff Levand wrote:
>> >
>> >> > All memory management for the main cpu is done by the arch code. Kexec
>> >> > and cpu hot plug only work with the secondary cpus, so the problem would
>> >> > be in the arch memory code, either in setup_restart() for shutdown, or
>> >> > in the startup code.
>> >>
>> >> It's possible that soft_restart and setup_restart are a little dodgy, as
>> >> they also rely on the compiler being smart and not touching the stack
>> >> after setup_restart().
>> >>
>> >> However, they provide absolutely no guarantee that any data has been
>> >> flushed out to the PoC [1]. If you require any data to be flushed out to the
>> >> PoC so as to be visible to noncacheable accesses, you will need to
>> >> ensure that this is flushed by VA before soft_restart is called. Data
>> >> may have migrated to another cache (e.g. another CPU, or the L3) where
>> >> it is not visible.
>> >
>> > OK, kexec's reset routine relocate_new_kernel does use a few global
>> > variables that are set by the main kexec routines. I added a call to
>> > __flush_dcache_area(), which uses 'dc civac' for those.
>> >
>> > I had thought the call to __flush_dcache_all, which uses 'dc cisw', in
>> > flush_cache_all() would be enough.
>> >
>> > Arun, I also fixed UP builds. Could you pull my latest and try with L3
>> > enabled?
>> >
>> I got this working. As 'Mark Rutland' pointed in another mail that
>> it could be problem with flushing the cache; I did a read of
>> 1GB data from start of RAM to a volatile var. I assume that
>> this will clear and invalidate all that in cache (L1=32K, L2=256 K, L3=8M)
>
> You've managed to get the cache to evict some lines, which proves my
> theory, but this is absolute nonsense and guarantees nothing.
>
> So NAK to this.
>
Yes I was just shooting wildly.
> If you need to perform cache maintenance to guarantee data is visible to
> non-cacheable accesses you _must_ use the architected mechanism for
> cleaning data to the PoC: DC CVAC. We have wrappers for flushing ranges.
>
> Anything else is nonsense and does not provide the guarantee you need.
>
> That said, I still am not sure what guarantee you are attempting to get.
> Which data do you need out at the PoC?
>
I tried flushing the jump addr
##########
+static unsigned long jump_addr_save;
void soft_restart(unsigned long addr)
{
typedef void (*phys_reset_t)(unsigned long);
phys_reset_t phys_reset;
+ phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
+ jump_addr_save = addr;
+ __flush_dcache_area(&jump_addr_save, 16);
+ __flush_dcache_area(&phys_reset, 16);
setup_restart();
/* Switch to the identity mapping */
- phys_reset = (phys_reset_t)virt_to_phys(cpu_reset);
- phys_reset(addr);
+ phys_reset(jump_addr_save);
/* Should never get here */
BUG();
###########
And flushing all the source and destination pages of the kexeced
kernel
##########
diff --git a/arch/arm64/kernel/machine_kexec.c
b/arch/arm64/kernel/machine_kexec.c
index 2995c78..3edf567 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -221,6 +221,8 @@ static void _kexec_entry_dump(const char *func, int line,
addr,
(unsigned
long)virt_to_phys(dest),
dest);
+ __flush_dcache_area(addr, PAGE_SIZE);
+ __flush_dcache_area(dest, PAGE_SIZE);
dest += PAGE_SIZE;
break;
case IND_DONE:
###########
It still fails(not reboot to kexeced kernel); That means I miss
flushing of some other
area.
--Arun
> Thanks,
> Mark.
>
>>
>> ###################
>> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
>> index 786daa6..90418f3 100644
>> --- a/arch/arm64/kernel/process.c
>> +++ b/arch/arm64/kernel/process.c
>> @@ -63,6 +63,10 @@ static inline void smp_secondary_shutdown(void) {}
>>
>> static void setup_restart(void)
>> {
>> + volatile u64 tmp;
>> + volatile u64 *addr;
>> +
>> + addr = (u64 *)(0xffffffc000000000);
>> /*
>> * Tell the mm system that we are going to reboot -
>> * we may need it to insert some 1:1 mappings so that
>> @@ -75,6 +79,11 @@ static void setup_restart(void)
>> /* Clean and invalidate caches */
>> flush_cache_all();
>>
>> + for ( ;addr < (u64 *)0xffffffc040000000; addr++)
>> + {
>> + tmp = *addr;
>> + }
>> +
>> /* Turn D-cache off */
>> cpu_cache_off();
>>
>> ###################
>>
>> With the above change latest kernel @
>> https://git.linaro.org/people/geoff.levand/linux-kexec.git
>> is able to do kexec with L3 enabled in UP scenario.
>>
>> --Arun
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > -Geoff
>> >
>>
next prev parent reply other threads:[~2014-07-25 15:29 UTC|newest]
Thread overview: 49+ 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 [this message]
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
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
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=CAFdej028aK_hopC906JY_FPSHtRiYwqH3ee2eJq3bRiOuVXGqg@mail.gmail.com \
--to=achandran@mvista.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).