From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
"hbabu@us.ibm.com" <hbabu@us.ibm.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>, "Huang\,
Ying" <ying.huang@intel.com>, "mingo@elte.hu" <mingo@elte.hu>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"sam@ravnborg.org" <sam@ravnborg.org>
Subject: Re: RFC: x86: relocatable kernel changes (revised spec)
Date: Mon, 11 May 2009 09:03:02 -0700 [thread overview]
Message-ID: <4A084C36.3010808@zytor.com> (raw)
In-Reply-To: <m1vdo7hn2i.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
>
>> +Field name: init_size
>> +Type: read
>> +Offset/size: 0x25c/4
>> +
>> + This field indicates the amount of linear contiguous memory starting
>> + at the kernel load address (rounded up to kernel_alignment) that the
>> + kernel needs before it is capable of examining its memory map. This
>> + is not the same thing as the total amount of memory the kernel needs
>> + to boot, but it can be used by a relocating boot loader to help
>> + select a safe load address for the kernel.
>
> This wording is a bit unclear.
>
> Can we finally say that it is safe to put the initrd immediately after
> the kernel?
>
I *believe* we can, as the brk limit checking should catch overruns.
The only question is whether or not there will me memory allocated off
the memory map before the initrd is reserved; I *think* the answer is no
but I haven't done the audit.
> The rounding up part of that comment is unclear.
The rounding up was to reflect the automatic moving upwards from the
load address to the next kernel_alignment datum.
> Peter did your implementation of init_size take into account the maximum expansion
> during decompression? At a quick glance at your previous patches I couldn't
> tell. I know were in that direction with zoffset.h and voffset.h but I don't
> recognize the formula for where I put the pic decompressor in your calculation
> of this.
It does take it into account. The pic decompressor is located at
(ZO_)z_extract_offset; the actual formula moved into mkpiggy.c.
I have regenerated the tip:x86/kbuild-phys branch to be only cleanups
(with the intent of putting the policy changes cleanly on top), and much
better structured. I hadn't originally expected this to turn into so
much of a cleanup effort.
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=shortlog;h=x86/kbuild-phys
This checkin, in particular, should answer that question, I believe:
http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=commitdiff;h=02a884c0fe7ec8459d00d34b7d4101af21fc4a86
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2009-05-11 16:07 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-07 22:26 [PATCH 00/14] RFC: x86: relocatable kernel changes H. Peter Anvin
2009-05-07 22:26 ` [PATCH 01/14] x86, boot: align the .bss section in the decompressor H. Peter Anvin
2009-05-08 7:17 ` Sam Ravnborg
2009-05-08 8:18 ` Eric Dumazet
2009-05-08 16:54 ` H. Peter Anvin
2009-05-08 7:53 ` Cyrill Gorcunov
2009-05-08 17:03 ` H. Peter Anvin
2009-05-08 17:15 ` Cyrill Gorcunov
2009-05-08 17:21 ` H. Peter Anvin
2009-05-07 22:26 ` [PATCH 02/14] x86, boot: honor CONFIG_PHYSICAL_START when relocatable H. Peter Anvin
2009-05-08 7:34 ` Sam Ravnborg
2009-05-08 16:58 ` H. Peter Anvin
2009-05-07 22:26 ` [PATCH 03/14] x86, config: change defaults PHYSICAL_START and PHYSICAL_ALIGN H. Peter Anvin
2009-05-08 7:36 ` Sam Ravnborg
2009-05-08 9:47 ` Ingo Molnar
2009-05-08 17:01 ` H. Peter Anvin
2009-05-07 22:26 ` [PATCH 04/14] x86, boot: unify use LOAD_PHYSICAL_ADDR and LOAD_PHYSICAL_ALIGN H. Peter Anvin
2009-05-07 22:26 ` [PATCH 05/14] kbuild: allow compressors (gzip, bzip2, lzma) to take multiple inputs H. Peter Anvin
2009-05-08 7:42 ` Sam Ravnborg
2009-05-08 20:18 ` H. Peter Anvin
2009-05-08 20:47 ` Sam Ravnborg
2009-05-08 20:49 ` H. Peter Anvin
2009-05-08 21:33 ` Sam Ravnborg
2009-05-07 22:26 ` [PATCH 06/14] x86: add a Kconfig symbol for when relocations are needed H. Peter Anvin
2009-05-07 22:26 ` [PATCH 07/14] x86, boot: simplify arch/x86/boot/compressed/Makefile H. Peter Anvin
2009-05-08 7:45 ` Sam Ravnborg
2009-05-07 22:26 ` [PATCH 08/14] x86, boot: use BP_scratch in arch/x86/boot/compressed/head_*.S H. Peter Anvin
2009-05-07 22:26 ` [PATCH 09/14] x86, boot: add new runtime_address and runtime_size bzImage fields H. Peter Anvin
2009-05-08 7:55 ` Sam Ravnborg
2009-05-08 21:09 ` H. Peter Anvin
2009-05-08 21:35 ` Sam Ravnborg
2009-05-07 22:26 ` [PATCH 10/14] x86, doc: document the runtime_start " H. Peter Anvin
2009-05-07 22:26 ` [PATCH 11/14] x86, boot: use rep movsq to move kernel on 64 bits H. Peter Anvin
2009-05-07 22:27 ` [PATCH 12/14] x86, boot: zero EFLAGS on 32 bits H. Peter Anvin
2009-05-07 22:27 ` [PATCH 13/14] x86: make CONFIG_RELOCATABLE the default H. Peter Anvin
2009-05-07 22:27 ` [PATCH 14/14] x86, defconfig: update defconfigs to relocatable H. Peter Anvin
2009-05-08 1:23 ` [PATCH 00/14] RFC: x86: relocatable kernel changes Eric W. Biederman
2009-05-08 5:31 ` H. Peter Anvin
2009-05-08 6:54 ` Eric W. Biederman
2009-05-08 18:04 ` H. Peter Anvin
2009-05-08 18:47 ` H. Peter Anvin
2009-05-11 5:18 ` RFC: x86: relocatable kernel changes (revised spec) H. Peter Anvin
2009-05-11 11:54 ` Eric W. Biederman
2009-05-11 16:03 ` H. Peter Anvin [this message]
2009-05-11 17:56 ` RFC: x86: relocatable kernel changes (revised spec v2) H. Peter Anvin
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=4A084C36.3010808@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=hbabu@us.ibm.com \
--cc=hpa@linux.intel.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=ying.huang@intel.com \
/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