From: Suzuki Poulose <suzuki@in.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: McClintock Matthew-B29882 <B29882@freescale.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: Question regarding the kexec support for FSL Book E
Date: Fri, 08 Apr 2011 10:17:17 +0530 [thread overview]
Message-ID: <4D9E9355.8010407@in.ibm.com> (raw)
In-Reply-To: <20110407162258.GA15298@linutronix.de>
On 04/07/11 21:52, Sebastian Andrzej Siewior wrote:
> * McClintock Matthew-B29882 | 2011-04-07 15:19:12 [+0000]:
>
>> On Thu, Apr 7, 2011 at 6:08 AM, Suzuki Poulose<suzuki@in.ibm.com> wrote:
>>> How is this case taken care of ? Is it via the temporary mapping ? What is
>>> the virtual
>>> address used by temporary mapping for the "relocate_new_kernel()" ?
>
> It is the same as the physical :) It is hard to tell where exactly the
> kernel image will be. It is somewhere between 0 and
> KEXEC_CONTROL_MEMORY_LIMIT. It is allocated in
> kimage_alloc_normal_control_pages(). It should not matter where it is.
I guess I got my answer :). The virtual address of the relocate_new_kernel() is
a kernel space VA, and hence would be above 2G (> PAGE_OFFSET), so there won't
be a clash of the 1:1 mapping that we create. Also, the src/destination pages
won't overlap the with the relocate_new_kernel. Hence we are safe.
>
>> When you load the new kexec image with kexec -l, I believe we make
>> sure we are in the first 2gb of memory. Then when you kexec, all the
>> TLB's are torn down and we setup a 1:1 virtual:physical mapping for
>> the first 2GB of memory. Then some assembly copies kernel from the
>> stored location to the destination and we boot the new kernel.
>
> arch/powerpc/include/asm/kexec.h:
> |#ifdef CONFIG_FSL_BOOKE
> |
> |/*
> | * On FSL-BookE we setup a 1:1 mapping which covers the first 2GiB of memory
> | * and therefore we can only deal with memory within this range
> | */
> |#define KEXEC_SOURCE_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1)
> |#define KEXEC_DESTINATION_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1)
> |#define KEXEC_CONTROL_MEMORY_LIMIT (2 * 1024 * 1024 * 1024UL - 1)
> |
> |#else
>
> So the kernel never gives memory above 2GiB to userland.
Right. If the page allocated is above 2GiB Physical Address, it is discarded,
and we look for new page.
Thanks
Suzuki
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2011-04-08 4:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4D9D5F17.2040208@in.ibm.com>
2011-04-07 8:23 ` Question regarding the kexec support for FSL Book E Sebastian Andrzej Siewior
2011-04-07 11:08 ` Suzuki Poulose
2011-04-07 15:19 ` McClintock Matthew-B29882
2011-04-07 16:22 ` Sebastian Andrzej Siewior
2011-04-08 4:47 ` Suzuki Poulose [this message]
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=4D9E9355.8010407@in.ibm.com \
--to=suzuki@in.ibm.com \
--cc=B29882@freescale.com \
--cc=ananth@in.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=kexec@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