From: "H. Peter Anvin" <h.peter.anvin@intel.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: "H. Peter Anvin" <hpa@linux.intel.com>, linux-kernel@vger.kernel.org, vgoyal@redhat.com, hbabu@us.ibm.com, kexec@lists.infradead.org, ying.huang@intel.com, mingo@elte.hu, tglx@linutronix.de, sam@ravnborg.org Subject: Re: [PATCH 00/14] RFC: x86: relocatable kernel changes Date: Thu, 07 May 2009 22:31:39 -0700 [thread overview] Message-ID: <4A03C3BB.3070401@intel.com> (raw) In-Reply-To: <m14ovwz8ua.fsf@fess.ebiederm.org> Eric W. Biederman wrote: > Peter do you plan to update pxelinux or other bootloaders to use the > relocatable kernel feature? Yes. > The direction of this patch seems reasonable. The details are broken. > The common case for relocatable kernels today is kdump. A situation > with very minimal memory. In that situation the kernel needs to run > where we put it, modifying the kernel to not run where it gets put > is a problem. I thought in the kdump case you typically loaded it pretty high? Either which way, kdump is always loaded by kexec, so it should just be a matter of updating kexec to zero the runtime_start field, no? Basically this is the bootloader saying "do what I say, dammit." Since the existing protocol doesn't have a way to unambiguously communicate one direction versus another (see below), it seems like a relatively small issue involving only one tool. Suboptimal, yes. > With the code as it is today you can get the exact same behavior > by simply bumping up the minimum alignment to 16MB, and a lot less code > and no changes needed to any bootloaders. > > Is your goal to setup a scenario where on small memory systems a bootloader > like pxelinux can support a relocatable kernel and load it a lower > address? If so that seems reasonable. Yes. > With that said how about we change the logic to: > > if (load_addr == legacy_load_addr) /* 0x100000 */ > use config_physical_start > else if aligned > noop > else > /* Crap this is bad align the kernel and hope something works. */ > > That gets the desired behavior we override bootloaders that are not > smart and taking relocation into account. I am really not comfortable > with having code that will override a bootloader doing something > reasonable. I'm not sure that is quite right either, because if alignment is configured to be 1 MB or less then 1 MB is a perfectly legitimate address for a relocating bootloader to want to use, even if it is not configured in. It would be more than a bit odd to not have that be permitted. > I expect we will still want to update kexec to be able to take > advantage of loadtime_size (runtime_size seems like the wrong name). Well, it is the amount of memory the kernel needs during runtime (as opposed to during loading.) I admit it's not an ideal name, though. On the other hand, simply calling it kernel_start and kernel_size seemed ambiguous. -hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <h.peter.anvin@intel.com> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, hbabu@us.ibm.com, ying.huang@intel.com, mingo@elte.hu, "H. Peter Anvin" <hpa@linux.intel.com>, sam@ravnborg.org, tglx@linutronix.de, vgoyal@redhat.com Subject: Re: [PATCH 00/14] RFC: x86: relocatable kernel changes Date: Thu, 07 May 2009 22:31:39 -0700 [thread overview] Message-ID: <4A03C3BB.3070401@intel.com> (raw) In-Reply-To: <m14ovwz8ua.fsf@fess.ebiederm.org> Eric W. Biederman wrote: > Peter do you plan to update pxelinux or other bootloaders to use the > relocatable kernel feature? Yes. > The direction of this patch seems reasonable. The details are broken. > The common case for relocatable kernels today is kdump. A situation > with very minimal memory. In that situation the kernel needs to run > where we put it, modifying the kernel to not run where it gets put > is a problem. I thought in the kdump case you typically loaded it pretty high? Either which way, kdump is always loaded by kexec, so it should just be a matter of updating kexec to zero the runtime_start field, no? Basically this is the bootloader saying "do what I say, dammit." Since the existing protocol doesn't have a way to unambiguously communicate one direction versus another (see below), it seems like a relatively small issue involving only one tool. Suboptimal, yes. > With the code as it is today you can get the exact same behavior > by simply bumping up the minimum alignment to 16MB, and a lot less code > and no changes needed to any bootloaders. > > Is your goal to setup a scenario where on small memory systems a bootloader > like pxelinux can support a relocatable kernel and load it a lower > address? If so that seems reasonable. Yes. > With that said how about we change the logic to: > > if (load_addr == legacy_load_addr) /* 0x100000 */ > use config_physical_start > else if aligned > noop > else > /* Crap this is bad align the kernel and hope something works. */ > > That gets the desired behavior we override bootloaders that are not > smart and taking relocation into account. I am really not comfortable > with having code that will override a bootloader doing something > reasonable. I'm not sure that is quite right either, because if alignment is configured to be 1 MB or less then 1 MB is a perfectly legitimate address for a relocating bootloader to want to use, even if it is not configured in. It would be more than a bit odd to not have that be permitted. > I expect we will still want to update kexec to be able to take > advantage of loadtime_size (runtime_size seems like the wrong name). Well, it is the amount of memory the kernel needs during runtime (as opposed to during loading.) I admit it's not an ideal name, though. On the other hand, simply calling it kernel_start and kernel_size seemed ambiguous. -hpa _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2009-05-08 5:35 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 [this message] 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 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=4A03C3BB.3070401@intel.com \ --to=h.peter.anvin@intel.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.