All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 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.