public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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