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.
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "hbabu@us.ibm.com" <hbabu@us.ibm.com>, "Huang, Ying" <ying.huang@intel.com>, "mingo@elte.hu" <mingo@elte.hu>, "H. Peter Anvin" <hpa@linux.intel.com>, "sam@ravnborg.org" <sam@ravnborg.org>, "tglx@linutronix.de" <tglx@linutronix.de>, "vgoyal@redhat.com" <vgoyal@redhat.com> 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. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2009-05-11 16:07 UTC|newest] Thread overview: 90+ 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 ` 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-07 22:26 ` H. Peter Anvin 2009-05-08 7:17 ` Sam Ravnborg 2009-05-08 7:17 ` Sam Ravnborg 2009-05-08 8:18 ` Eric Dumazet 2009-05-08 8:18 ` Eric Dumazet 2009-05-08 16:54 ` H. Peter Anvin 2009-05-08 16:54 ` H. Peter Anvin 2009-05-08 7:53 ` Cyrill Gorcunov 2009-05-08 7:53 ` Cyrill Gorcunov 2009-05-08 17:03 ` H. Peter Anvin 2009-05-08 17:03 ` H. Peter Anvin 2009-05-08 17:15 ` Cyrill Gorcunov 2009-05-08 17:15 ` Cyrill Gorcunov 2009-05-08 17:21 ` H. Peter Anvin 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-07 22:26 ` H. Peter Anvin 2009-05-08 7:34 ` Sam Ravnborg 2009-05-08 7:34 ` Sam Ravnborg 2009-05-08 16:58 ` H. Peter Anvin 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-07 22:26 ` H. Peter Anvin 2009-05-08 7:36 ` Sam Ravnborg 2009-05-08 7:36 ` Sam Ravnborg 2009-05-08 9:47 ` Ingo Molnar 2009-05-08 9:47 ` Ingo Molnar 2009-05-08 17:01 ` H. Peter Anvin 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 ` 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-07 22:26 ` H. Peter Anvin 2009-05-08 7:42 ` Sam Ravnborg 2009-05-08 7:42 ` Sam Ravnborg 2009-05-08 20:18 ` H. Peter Anvin 2009-05-08 20:18 ` H. Peter Anvin 2009-05-08 20:47 ` Sam Ravnborg 2009-05-08 20:47 ` Sam Ravnborg 2009-05-08 20:49 ` H. Peter Anvin 2009-05-08 20:49 ` H. Peter Anvin 2009-05-08 21:33 ` Sam Ravnborg 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 ` H. Peter Anvin 2009-05-07 22:26 ` [PATCH 07/14] x86, boot: simplify arch/x86/boot/compressed/Makefile H. Peter Anvin 2009-05-07 22:26 ` H. Peter Anvin 2009-05-08 7:45 ` Sam Ravnborg 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 ` 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-07 22:26 ` H. Peter Anvin 2009-05-08 7:55 ` Sam Ravnborg 2009-05-08 7:55 ` Sam Ravnborg 2009-05-08 21:09 ` H. Peter Anvin 2009-05-08 21:09 ` H. Peter Anvin 2009-05-08 21:35 ` Sam Ravnborg 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 ` 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:26 ` 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 ` 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 ` H. Peter Anvin 2009-05-07 22:27 ` [PATCH 14/14] x86, defconfig: update defconfigs to relocatable H. Peter Anvin 2009-05-07 22:27 ` H. Peter Anvin 2009-05-08 1:23 ` [PATCH 00/14] RFC: x86: relocatable kernel changes Eric W. Biederman 2009-05-08 1:23 ` Eric W. Biederman 2009-05-08 5:31 ` H. Peter Anvin 2009-05-08 5:31 ` H. Peter Anvin 2009-05-08 6:54 ` Eric W. Biederman 2009-05-08 6:54 ` Eric W. Biederman 2009-05-08 18:04 ` H. Peter Anvin 2009-05-08 18:04 ` H. Peter Anvin 2009-05-08 18:47 ` 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 5:18 ` H. Peter Anvin 2009-05-11 11:54 ` Eric W. Biederman 2009-05-11 11:54 ` Eric W. Biederman 2009-05-11 16:03 ` H. Peter Anvin [this message] 2009-05-11 16:03 ` H. Peter Anvin 2009-05-11 17:56 ` RFC: x86: relocatable kernel changes (revised spec v2) H. Peter Anvin 2009-05-11 17:56 ` 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: linkBe 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.