From: Vivek Goyal <vgoyal@redhat.com>
To: Bernhard Walle <bwalle@suse.de>
Cc: x86@kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] x86: Find offset for crashkernel reservation automatically
Date: Fri, 27 Jun 2008 09:32:56 -0400 [thread overview]
Message-ID: <20080627133256.GB5801@redhat.com> (raw)
In-Reply-To: <1214510048-21215-1-git-send-email-bwalle@suse.de>
On Thu, Jun 26, 2008 at 09:54:08PM +0200, Bernhard Walle wrote:
> This patch removes the need of the crashkernel=...@offset parameter to define
> a fixed offset for crashkernel reservation. That feature can be used together
> with a relocatable kernel where the kexec-tools relocate the kernel and
> get the actual offset from /proc/iomem.
>
> The use case is a kernel where the .text+.data+.bss is after 16M physical
> memory (debug kernel with lockdep on x86_64 can cause that) which caused a
> major pain in autoconfiguration in our distribution.
>
> Also, that patch unifies crashdump architectures a bit since IA64 has
> that semantics from the very beginning of the kdump port.
>
> Please provide feedback!
>
Hi Bernhard,
This looks like a good idea. That means distributions don't have to
hardcode the crashbase at 16MB and the decision to find a free memory
can be left on kernel. Users will also find it easy that way.
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
> arch/x86/kernel/setup.c | 70 +++++++++++++++++++++++++++++++++++------------
> 1 files changed, 52 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a81d82c..c30bb7b 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -435,6 +435,34 @@ static inline unsigned long long get_total_mem(void)
> }
>
> #ifdef CONFIG_KEXEC
> +
> +/**
> + * Reserve @size bytes of crashkernel memory at any suitable offset.
> + *
> + * @size: Size of the crashkernel memory to reserve.
> + * Returns the base address on success, and -1ULL on failure.
> + */
> +unsigned long long find_and_reserve_crashkernel(unsigned long long size)
> +{
> + const unsigned long long alignment = 16<<20; /* 16M */
> + unsigned long long start = 0LL;
> +
> + while (1) {
> + int ret;
> +
> + start = find_e820_area(start, ULONG_MAX, size, alignment);
> + if (start == -1ULL)
> + return start;
> +
> + /* try to reserve it */
> + ret = reserve_bootmem_generic(start, size, BOOTMEM_EXCLUSIVE);
> + if (ret >= 0)
> + return start;
> +
> + start += alignment;
> + }
I think both i386 and x86_64 relocatable kernels had some upper limits
where these could be loaded (Eric had mentioned those in the patch. I
don't remember these). It might be a good idea to capture it here
making sure "start" does not cross those limits otherwise don't reserve
the memory.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: Bernhard Walle <bwalle@suse.de>
Cc: kexec@lists.infradead.org, x86@kernel.org,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH] x86: Find offset for crashkernel reservation automatically
Date: Fri, 27 Jun 2008 09:32:56 -0400 [thread overview]
Message-ID: <20080627133256.GB5801@redhat.com> (raw)
In-Reply-To: <1214510048-21215-1-git-send-email-bwalle@suse.de>
On Thu, Jun 26, 2008 at 09:54:08PM +0200, Bernhard Walle wrote:
> This patch removes the need of the crashkernel=...@offset parameter to define
> a fixed offset for crashkernel reservation. That feature can be used together
> with a relocatable kernel where the kexec-tools relocate the kernel and
> get the actual offset from /proc/iomem.
>
> The use case is a kernel where the .text+.data+.bss is after 16M physical
> memory (debug kernel with lockdep on x86_64 can cause that) which caused a
> major pain in autoconfiguration in our distribution.
>
> Also, that patch unifies crashdump architectures a bit since IA64 has
> that semantics from the very beginning of the kdump port.
>
> Please provide feedback!
>
Hi Bernhard,
This looks like a good idea. That means distributions don't have to
hardcode the crashbase at 16MB and the decision to find a free memory
can be left on kernel. Users will also find it easy that way.
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
> arch/x86/kernel/setup.c | 70 +++++++++++++++++++++++++++++++++++------------
> 1 files changed, 52 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a81d82c..c30bb7b 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -435,6 +435,34 @@ static inline unsigned long long get_total_mem(void)
> }
>
> #ifdef CONFIG_KEXEC
> +
> +/**
> + * Reserve @size bytes of crashkernel memory at any suitable offset.
> + *
> + * @size: Size of the crashkernel memory to reserve.
> + * Returns the base address on success, and -1ULL on failure.
> + */
> +unsigned long long find_and_reserve_crashkernel(unsigned long long size)
> +{
> + const unsigned long long alignment = 16<<20; /* 16M */
> + unsigned long long start = 0LL;
> +
> + while (1) {
> + int ret;
> +
> + start = find_e820_area(start, ULONG_MAX, size, alignment);
> + if (start == -1ULL)
> + return start;
> +
> + /* try to reserve it */
> + ret = reserve_bootmem_generic(start, size, BOOTMEM_EXCLUSIVE);
> + if (ret >= 0)
> + return start;
> +
> + start += alignment;
> + }
I think both i386 and x86_64 relocatable kernels had some upper limits
where these could be loaded (Eric had mentioned those in the patch. I
don't remember these). It might be a good idea to capture it here
making sure "start" does not cross those limits otherwise don't reserve
the memory.
Thanks
Vivek
next prev parent reply other threads:[~2008-06-27 13:33 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-26 19:54 [PATCH] x86: Find offset for crashkernel reservation automatically Bernhard Walle
2008-06-26 19:54 ` Bernhard Walle
2008-06-27 13:32 ` Vivek Goyal [this message]
2008-06-27 13:32 ` Vivek Goyal
2008-06-27 13:42 ` Vivek Goyal
2008-06-27 13:42 ` Vivek Goyal
2008-06-27 14:06 ` Bernhard Walle
2008-06-27 14:06 ` Bernhard Walle
2008-06-27 14:19 ` Vivek Goyal
2008-06-27 14:19 ` Vivek Goyal
2008-06-27 14:22 ` Bernhard Walle
2008-06-27 14:22 ` Bernhard Walle
2008-06-27 18:00 ` Eric W. Biederman
2008-06-27 18:00 ` Eric W. Biederman
2008-06-27 18:29 ` Bernhard Walle
2008-06-27 18:29 ` Bernhard Walle
2008-07-03 13:14 ` Ingo Molnar
2008-07-03 13:14 ` Ingo Molnar
2008-07-14 7:11 ` Yinghai Lu
2008-07-14 7:11 ` Yinghai Lu
2008-07-14 9:24 ` Bernhard Walle
2008-07-14 9:24 ` Bernhard Walle
2008-07-14 9:44 ` Eric W. Biederman
2008-07-14 9:44 ` Eric W. Biederman
2008-07-14 17:06 ` Yinghai Lu
2008-07-14 17:06 ` Yinghai Lu
2008-07-14 17:30 ` Eric W. Biederman
2008-07-14 17:30 ` Eric W. Biederman
2008-07-14 18:17 ` Yinghai Lu
2008-07-14 18:17 ` Yinghai Lu
2008-07-14 18:41 ` Eric W. Biederman
2008-07-14 18:41 ` Eric W. Biederman
2008-07-14 18:47 ` Bernhard Walle
2008-07-14 18:47 ` Bernhard Walle
2008-07-14 18:55 ` Eric W. Biederman
2008-07-14 18:55 ` Eric W. Biederman
2008-07-14 19:08 ` Yinghai Lu
2008-07-14 19:08 ` Yinghai Lu
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=20080627133256.GB5801@redhat.com \
--to=vgoyal@redhat.com \
--cc=bwalle@suse.de \
--cc=ebiederm@xmission.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.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.