[RFC] ELF Relocatable x86 and x86_64 bzImages

Dave Jones · External Since: Mar 15, 2005 Posts: 720

On Fri, Aug 04, 2006 at 05:14:37PM -0600, Eric W. Biederman wrote:

> I guess the practical question is do people see a real performance benefit
> when loading the kernel at 4MB?

Linus claimed lmbench saw some huge wins. Others showed that for eg,
a kernel compile took the same amount of time, so take from that what you will..

> Possibly the right solution is to do like I did on x86_64 and simply remove
> CONFIG_PHYSICAL_START, and always place the kernel at 4MB, or something like
> that.
>
> The practical question is what to do to keep the complexity from spinning
> out of control. Removing CONFIG_PHYSICAL_START would seriously help with
> that.

Given the two primary uses of that option right now are a) the aforementioned
perf win and b) building kexec kernels, I doubt anyone would miss it once
we go relocatable Wink

Dave

--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

H. Peter Anvin · External Since: Feb 08, 2006 Posts: 1055

Dave Jones wrote:
> On Fri, Aug 04, 2006 at 05:14:37PM -0600, Eric W. Biederman wrote:
>
> > I guess the practical question is do people see a real performance benefit
> > when loading the kernel at 4MB?
>
> Linus claimed lmbench saw some huge wins. Others showed that for eg,
> a kernel compile took the same amount of time, so take from that what you will..
>
> > Possibly the right solution is to do like I did on x86_64 and simply remove
> > CONFIG_PHYSICAL_START, and always place the kernel at 4MB, or something like
> > that.
> >
> > The practical question is what to do to keep the complexity from spinning
> > out of control. Removing CONFIG_PHYSICAL_START would seriously help with
> > that.
>
> Given the two primary uses of that option right now are a) the aforementioned
> perf win and b) building kexec kernels, I doubt anyone would miss it once
> we go relocatable Wink

>

We DO want the performance gain with a conventional bootloader. The
perf win is about the location of the uncompressed kernel, not the
compressed kernel.

-hpa

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman · External Since: May 19, 2006 Posts: 1134

"H. Peter Anvin" <hpa.TakeThisOut@zytor.com> writes:

> Dave Jones wrote:
>> On Fri, Aug 04, 2006 at 05:14:37PM -0600, Eric W. Biederman wrote:
>> > I guess the practical question is do people see a real performance benefit
>> > when loading the kernel at 4MB?
>> Linus claimed lmbench saw some huge wins. Others showed that for eg,
>> a kernel compile took the same amount of time, so take from that what you
> will..

But Linus wasn't comparing the same version of the kernel. So it was
a bit unknown. Having someone reproduce those lm_bench numbers on the
exact same kernel would be interesting.

>> > Possibly the right solution is to do like I did on x86_64 and simply remove
>> > CONFIG_PHYSICAL_START, and always place the kernel at 4MB, or something like
>> > that.
>> > > The practical question is what to do to keep the complexity from spinning
>> > out of control. Removing CONFIG_PHYSICAL_START would seriously help with
>> > that.
>> Given the two primary uses of that option right now are a) the aforementioned
>> perf win and b) building kexec kernels, I doubt anyone would miss it once
>> we go relocatable Wink

>>
>
> We DO want the performance gain with a conventional bootloader. The perf win is
> about the location of the uncompressed kernel, not the compressed kernel.

Agreed.

We also need a way to boot a kernel on an old machine with limited memory.
Possibly we would only support this if PSE is not supported, which old machines
don't support.

The complication that the decompressor must relocation the image for
supporting old bootloaders is challenging in the context or a truly relocatable
kernel, where we run at the address the bootloader put us.

The basic other concern is how flexible do we need to be with respect to relocation.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Horms · External Since: Nov 26, 2004 Posts: 154

On Fri, Aug 04, 2006 at 05:14:37PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal RemoveThis @in.ibm.com> writes:
>
> > On Tue, Aug 01, 2006 at 04:58:49AM -0600, Eric W. Biederman wrote:
> >>
> >> The problem:
> >>
> >> We can't always run the kernel at 1MB or 2MB, and so people who need
> >> different addresses must build multiple kernels. The bzImage format
> >> can't even represent loading a kernel at other than it's default address.
> >> With kexec on panic now starting to be used by distros having a kernel
> >> not running at the default load address is starting to become common.
> >>
> > Hi Eric,
> >
> > There seems to be a small anomaly in the current set of patches for i386.
> >
> > For example if one compiles the kernel with CONFIG_RELOCATABLE=y
> > and CONFIG_PHYSICAL_START=0x400000 (4MB) and he uses grub to load
> > the kernel then kernel would run from 1MB location. I think user would
> > expect it to run from 4MB location.
>
> Agreed. That is a non-intuitive, and should probably be fixed.

I also agree that it is non-intitive. But I wonder if a cleaner
fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
it just a work around for the kernel not being relocatable, or
are there uses for it that relocation can't replace?

--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

H. Peter Anvin · External Since: Feb 08, 2006 Posts: 1055

Horms wrote:
>
> I also agree that it is non-intitive. But I wonder if a cleaner
> fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
> it just a work around for the kernel not being relocatable, or
> are there uses for it that relocation can't replace?
>

Yes, booting with the 2^n existing bootloaders.

Relocation, as far as I've understood this patch, refers to loaded
address, not runtime address.

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Magnus Damm · External Since: May 25, 2006 Posts: 48

On 8/8/06, H. Peter Anvin <hpa.DeleteThis@zytor.com> wrote:
> Horms wrote:
> >
> > I also agree that it is non-intitive. But I wonder if a cleaner
> > fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
> > it just a work around for the kernel not being relocatable, or
> > are there uses for it that relocation can't replace?
> >
>
> Yes, booting with the 2^n existing bootloaders.
>
> Relocation, as far as I've understood this patch, refers to loaded
> address, not runtime address.

I believe Erics patch implements the following (correct me if I'm wrong):

vmlinux:
vmlinux is extended to contain relocation information. Absolute
symbols are used for non-relocatable symbols, and section-relative
symbols are used for relocatable symbols.

bzImage loader:
The bzImage loader code is no longer required to be loaded at a fixed
address. The bzImage file contains vmlinux relocation information and
the bzImage loader adjusts the relocations in vmlinux before executing
it.

So I would say that the runtime address of symbols in vmlinux are
changed by the bzImage loader. Or maybe I'm misunderstanding?

/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman · External Since: May 19, 2006 Posts: 1134

"H. Peter Anvin" <hpa RemoveThis @zytor.com> writes:

> Horms wrote:
>> I also agree that it is non-intitive. But I wonder if a cleaner
>> fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
>> it just a work around for the kernel not being relocatable, or
>> are there uses for it that relocation can't replace?
>>
>
> Yes, booting with the 2^n existing bootloaders.

Which is something we certainly have to be careful with.

> Relocation, as far as I've understood this patch, refers to loaded address, not
> runtime address.

Actually it refers to both.

Basically we detect if we were loaded with a clueless bootloader,
aka at 1MB. If so we just load to whatever address the code was built
to run at. Otherwise the code stays put.

To be loaded and run at a different address is what is needed for the
crash dump scenario. Where we have to run at some reserved area
of physical memory that the original kernel did not run from.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Horms · External Since: Nov 26, 2004 Posts: 154

On Mon, Aug 07, 2006 at 09:32:23PM -0700, H. Peter Anvin wrote:
> Horms wrote:
> >
> >I also agree that it is non-intitive. But I wonder if a cleaner
> >fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
> >it just a work around for the kernel not being relocatable, or
> >are there uses for it that relocation can't replace?
> >
>
> Yes, booting with the 2^n existing bootloaders.

Ok, I must be confused then. I though CONFIG_PHYSICAL_START was
introduced in order to allow an alternative address to be provided for
kdump, and that previously it was hard-coded to some
architecture-specific value.

What I was really getting as is if it needs to be configurable at
compile time or not. Obviously there needs to be some sane default
regardless.

--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman · External Since: May 19, 2006 Posts: 1134

Horms <horms.RemoveThis@verge.net.au> writes:

> On Mon, Aug 07, 2006 at 09:32:23PM -0700, H. Peter Anvin wrote:
>> Horms wrote:
>> >
>> >I also agree that it is non-intitive. But I wonder if a cleaner
>> >fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
>> >it just a work around for the kernel not being relocatable, or
>> >are there uses for it that relocation can't replace?
>> >
>>
>> Yes, booting with the 2^n existing bootloaders.
>
> Ok, I must be confused then. I though CONFIG_PHYSICAL_START was
> introduced in order to allow an alternative address to be provided for
> kdump, and that previously it was hard-coded to some
> architecture-specific value.
>
> What I was really getting as is if it needs to be configurable at
> compile time or not. Obviously there needs to be some sane default
> regardless.

CONFIG_PHYSICAL_START has had 2 uses.
1) To allow a kernel to run a completely different address for use
with kexec on panic.
2) To allow the kernel to be better aligned for better performance.

For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
Which will round our load address up to the nearest aligned address
and run the kernel there. That is roughly what I am doing on x86_64
at this point.

s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
behavior and allows the alignment optimization without getting into
weird semantics.

Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
where it was loaded and I assumed we always would. Since people have
realized better aligned kernels can run better this assumption became
false. Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
simple assumption of always running the kernel where it is loaded
modulo a little extra alignment.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Horms · External Since: Nov 26, 2004 Posts: 154

On Tue, Aug 08, 2006 at 01:23:15AM -0600, Eric W. Biederman wrote:
> Horms <horms RemoveThis @verge.net.au> writes:
>
> > On Mon, Aug 07, 2006 at 09:32:23PM -0700, H. Peter Anvin wrote:
> >> Horms wrote:
> >> >
> >> >I also agree that it is non-intitive. But I wonder if a cleaner
> >> >fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
> >> >it just a work around for the kernel not being relocatable, or
> >> >are there uses for it that relocation can't replace?
> >> >
> >>
> >> Yes, booting with the 2^n existing bootloaders.
> >
> > Ok, I must be confused then. I though CONFIG_PHYSICAL_START was
> > introduced in order to allow an alternative address to be provided for
> > kdump, and that previously it was hard-coded to some
> > architecture-specific value.
> >
> > What I was really getting as is if it needs to be configurable at
> > compile time or not. Obviously there needs to be some sane default
> > regardless.
>
> CONFIG_PHYSICAL_START has had 2 uses.
> 1) To allow a kernel to run a completely different address for use
> with kexec on panic.
> 2) To allow the kernel to be better aligned for better performance.

Thanks for making that clear

> For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
> Which will round our load address up to the nearest aligned address
> and run the kernel there. That is roughly what I am doing on x86_64
> at this point.
>
> s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
> behavior and allows the alignment optimization without getting into
> weird semantics.
>
> Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
> where it was loaded and I assumed we always would. Since people have
> realized better aligned kernels can run better this assumption became
> false. Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
> simple assumption of always running the kernel where it is loaded
> modulo a little extra alignment.

That sounds reasonable to me. Though it is a little less flexible,
do you think that could be a problem? Perhaps we could have both,
though that would probably be quite confusing.

--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

D. Hazelton · External Since: Aug 09, 2006 Posts: 8

On Tuesday 08 August 2006 03:58, Horms wrote:
> On Tue, Aug 08, 2006 at 01:23:15AM -0600, Eric W. Biederman wrote:
> > Horms <horms.RemoveThis@verge.net.au> writes:
<snip>
> > For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
> > Which will round our load address up to the nearest aligned address
> > and run the kernel there. That is roughly what I am doing on x86_64
> > at this point.
> >
> > s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
> > behavior and allows the alignment optimization without getting into
> > weird semantics.
> >
> > Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
> > where it was loaded and I assumed we always would. Since people have
> > realized better aligned kernels can run better this assumption became
> > false. Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
> > simple assumption of always running the kernel where it is loaded
> > modulo a little extra alignment.
>
> That sounds reasonable to me. Though it is a little less flexible,
> do you think that could be a problem? Perhaps we could have both,
> though that would probably be quite confusing.

More than reasonable. By changing this it seems that the kernel would still
work with older bootloaders, function properly under kexec and might actually
lead to a way to potentially recover a system from a crash without a reboot
by allowing the kexec'd kernel to reset the system.

Of course the last is only a wish... Never happen because of the complexity
involved. It would require a lot of work (I'd do this, but I'm currently
arguing with the kernel over my attempts at building a functional DRM backed
console) in having to switch back to real-mode to make the proper BIOS calls
to reset the busses et. al. before switching *back* to kernel mode to run the
standard startup.

Still, by letting a kernel run where it's loaded plus some modulo to get it
properly aligned in memory solves several problems. It removes the need for
CONFIG_PHYSICAL_START and the code involved in handling that. The kexec code
that reserves memory for the new kernel image can be tweaked to always
allocate the memory *aligned*...

Anyway, I'd better get back to the DRMCon code...

DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Rachita Kothiyal · External Since: Aug 11, 2006 Posts: 1

On Fri, Aug 04, 2006 at 06:56:11PM -0400, Vivek Goyal wrote:
>
> Signed-off-by: Vivek Goyal <vgoyal RemoveThis @in.ibm.com>
> ---
>
> arch/i386/boot/compressed/head.S | 32 ++++++++++++++++++++++++++++++--
> 1 file changed, 30 insertions(+), 2 deletions(-)
>
> diff -puN arch/i386/boot/compressed/head.S~debug1-patch arch/i386/boot/compressed/head.S
> --- linux-2.6.18-rc3-1M/arch/i386/boot/compressed/head.S~debug1-patch 2006-08-04 18:03:02.000000000 -0400
> +++ linux-2.6.18-rc3-1M-root/arch/i386/boot/compressed/head.S 2006-08-04 18:18:26.000000000 -0400
> @@ -60,13 +60,32 @@ startup_32:
> * a relocatable kernel this is the delta to our load address otherwise
> * this is the delta to CONFIG_PHYSICAL start.
> */
> +
> #ifdef CONFIG_RELOCTABLE
^^^^^^^^^
Vivek, did you mean CONFIG_RELOCATABLE ?

Thanks
Rachita

> + /* If loaded by non kexec boot loader, then we will be loaded
> + * at 1MB fixed address. But probably the intention is to run
> + * from a address for which kernel has been compiled which can
> + * be non 1MB.
> + */
> + xorl %eax, %eax
> + movb 0x210(%esi), %al
> +
> + / * check boot loader type. Kexec bootloader id 9, version any */
> + shrl $4, %eax
> + subl $0x9, %eax
> + jnz 1f
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Vivek Goyal · External Since: May 15, 2006 Posts: 286

On Fri, Aug 11, 2006 at 06:41:28PM +0530, Rachita Kothiyal wrote:
> On Fri, Aug 04, 2006 at 06:56:11PM -0400, Vivek Goyal wrote:
> >
> > Signed-off-by: Vivek Goyal <vgoyal RemoveThis @in.ibm.com>
> > ---
> >
> > arch/i386/boot/compressed/head.S | 32 ++++++++++++++++++++++++++++++--
> > 1 file changed, 30 insertions(+), 2 deletions(-)
> >
> > diff -puN arch/i386/boot/compressed/head.S~debug1-patch arch/i386/boot/compressed/head.S
> > --- linux-2.6.18-rc3-1M/arch/i386/boot/compressed/head.S~debug1-patch 2006-08-04 18:03:02.000000000 -0400
> > +++ linux-2.6.18-rc3-1M-root/arch/i386/boot/compressed/head.S 2006-08-04 18:18:26.000000000 -0400
> > @@ -60,13 +60,32 @@ startup_32:
> > * a relocatable kernel this is the delta to our load address otherwise
> > * this is the delta to CONFIG_PHYSICAL start.
> > */
> > +
> > #ifdef CONFIG_RELOCTABLE
> ^^^^^^^^^
> Vivek, did you mean CONFIG_RELOCATABLE ?
>
Hi Rachita,

Thanks for catching this. Yes I meant CONFIG_RELOCATABLE.

Thanks
Vivek

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Vivek Goyal · External Since: May 15, 2006 Posts: 286

On Tue, Aug 08, 2006 at 01:23:15AM -0600, Eric W. Biederman wrote:
> Horms <horms.DeleteThis@verge.net.au> writes:
>
> > On Mon, Aug 07, 2006 at 09:32:23PM -0700, H. Peter Anvin wrote:
> >> Horms wrote:
> >> >
> >> >I also agree that it is non-intitive. But I wonder if a cleaner
> >> >fix would be to remove CONFIG_PHYSICAL_START all together. Isn't
> >> >it just a work around for the kernel not being relocatable, or
> >> >are there uses for it that relocation can't replace?
> >> >
> >>
> >> Yes, booting with the 2^n existing bootloaders.
> >
> > Ok, I must be confused then. I though CONFIG_PHYSICAL_START was
> > introduced in order to allow an alternative address to be provided for
> > kdump, and that previously it was hard-coded to some
> > architecture-specific value.
> >
> > What I was really getting as is if it needs to be configurable at
> > compile time or not. Obviously there needs to be some sane default
> > regardless.
>
> CONFIG_PHYSICAL_START has had 2 uses.
> 1) To allow a kernel to run a completely different address for use
> with kexec on panic.
> 2) To allow the kernel to be better aligned for better performance.
>
> For maintenance reasons I propose we introduce CONFIG_PHYSICAL_ALIGN.
> Which will round our load address up to the nearest aligned address
> and run the kernel there. That is roughly what I am doing on x86_64
> at this point.
>
> s/CONFIG_PHYSICAL_START/CONFIG_PHYSICAL_ALIGN/ gives me well defined
> behavior and allows the alignment optimization without getting into
> weird semantics.
>
> Before CONFIG_PHYSICAL_START we _always_ ran the arch/i386 kernel
> where it was loaded and I assumed we always would. Since people have
> realized better aligned kernels can run better this assumption became
> false. Going to CONFIG_PHYSICAL_ALIGN allows us to return to the
> simple assumption of always running the kernel where it is loaded
> modulo a little extra alignment.
>

Hi Eric,

I have tried implementing your idea of replacing CONFIG_PHYSICAL_START
with CONFIG_PHYSICAL_ALIGN. Please find attached the patch.

It applies on top of your relocatable kernel patch series.

I guess there should be a way for running kernel to tell user space
that what's the offset of the addr at which kernel is running to
the address for which kernel has been compiled. This info can be useful
for debuggers in case they happen to debug the core of a kernel which
was not running at compiled addr.

Thanks
Vivek

o Get rid of CONFIG_PHYSICAL_START and implement CONFIG_PHYSICAL_ALIGN

Signed-off-by: Vivek Goyal <vgoyal.DeleteThis@in.ibm.com>
---

arch/i386/Kconfig | 34 ++++++++++++++++++----------------
arch/i386/boot/bootsect.S | 8 ++++----
arch/i386/boot/compressed/head.S | 28 ++++++++++++++++------------
arch/i386/boot/compressed/misc.c | 7 ++++---
arch/i386/boot/compressed/vmlinux.lds | 3 +++
arch/i386/kernel/vmlinux.lds.S | 5 +++--
include/asm-i386/boot.h | 6 +++++-
7 files changed, 53 insertions(+), 38 deletions(-)

diff -puN arch/i386/Kconfig~i386-implement-config-physical-align-option arch/i386/Kconfig
--- linux-2.6.18-rc3-1M/arch/i386/Kconfig~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/Kconfig 2006-08-17 11:28:40.000000000 -0400
@@ -773,24 +773,26 @@ config RELOCATABLE
must live at a different physical address than the primary
kernel.

-config PHYSICAL_START
- hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
-
- default "0x1000000" if CRASH_DUMP
+config PHYSICAL_ALIGN
+ hex "Alignment value to which kernel should be aligned" if (EMBEDDED)
default "0x100000"
- range 0x100000 0x37c00000
+ range 0x2000 0x400000
help
- This gives the physical address where the kernel is loaded. Normally
- for regular kernels this value is 0x100000 (1MB). But in the case
- of kexec on panic the fail safe kernel needs to run at a different
- address than the panic-ed kernel. This option is used to set the load
- address for kernels used to capture crash dump on being kexec'ed
- after panic. The default value for crash dump kernels is
- 0x1000000 (16MB). This can also be set based on the "X" value as
- specified in the "crashkernel=YM@XM" command line boot parameter
- passed to the panic-ed kernel. Typically this parameter is set as
- crashkernel=64M@16M. Please take a look at
- Documentation/kdump/kdump.txt for more details about crash dumps.
+ This value puts the alignment restrictions on physical address
+ where kernel is loaded and run from. Kernel is compiled for an
+ address which meets above alignment restriction.
+
+ If bootloader loads the kernel at a non-aligned address and
+ CONFIG_RELOCATABLE is set, kernel will move itself to nearest
+ address aligned to above value and run from there.
+
+ If bootloader loads the kernel at a non-aligned address and
+ CONFIG_RELOCATABLE is not set, kernel will ignore the run time
+ load address and decompress itself to the address it has been
+ compiled for and run from there. The address for which kernel is
+ compiled already meets above alignment restrictions. Hence the
+ end result is that kernel runs from a physical address meeting above
+ alignment restrictions.

Don't change this unless you know what you are doing.

diff -puN include/asm-i386/boot.h~i386-implement-config-physical-align-option include/asm-i386/boot.h
--- linux-2.6.18-rc3-1M/include/asm-i386/boot.h~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/include/asm-i386/boot.h 2006-08-17 10:56:46.000000000 -0400
@@ -12,4 +12,8 @@
#define EXTENDED_VGA 0xfffe /* 80x50 mode */
#define ASK_VGA 0xfffd /* ask for it at bootup */

-#endif
+/* Physical address where kenrel should be loaded. */
+#define LOAD_PHYSICAL_ADDR ((0x100000 + CONFIG_PHYSICAL_ALIGN - 1) \
+ & ~(CONFIG_PHYSICAL_ALIGN - 1))
+
+#endif /* _LINUX_BOOT_H */
diff -puN arch/i386/kernel/vmlinux.lds.S~i386-implement-config-physical-align-option arch/i386/kernel/vmlinux.lds.S
--- linux-2.6.18-rc3-1M/arch/i386/kernel/vmlinux.lds.S~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/kernel/vmlinux.lds.S 2006-08-17 10:56:46.000000000 -0400
@@ -2,13 +2,14 @@
* Written by Martin Mares <mj.DeleteThis@atrey.karlin.mff.cuni.cz>;
*/

-#define LOAD_OFFSET __PAGE_OFFSET
+#define LOAD_OFFSET __PAGE_OFFSET

#include <linux/config.h>
#include <asm-generic/vmlinux.lds.h>
#include <asm/thread_info.h>
#include <asm/page.h>
#include <asm/cache.h>
+#include <asm/boot.h>

OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
@@ -16,7 +17,7 @@ ENTRY(phys_startup_32)
jiffies = jiffies_64;
SECTIONS
{
- . = LOAD_OFFSET + CONFIG_PHYSICAL_START;
+ . = LOAD_OFFSET + LOAD_PHYSICAL_ADDR;
phys_startup_32 = startup_32 - LOAD_OFFSET;
/* read-only */
.text : AT(ADDR(.text) - LOAD_OFFSET) {
diff -puN arch/i386/boot/bootsect.S~i386-implement-config-physical-align-option arch/i386/boot/bootsect.S
--- linux-2.6.18-rc3-1M/arch/i386/boot/bootsect.S~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/boot/bootsect.S 2006-08-17 12:37:19.000000000 -0400
@@ -69,7 +69,7 @@ ehdr:
#endif
.word EM_386 # e_machine
.int 1 # e_version
- .int CONFIG_PHYSICAL_START # e_entry
+ .int LOAD_PHYSICAL_ADDR # e_entry
.int phdr - _start # e_phoff
.int 0 # e_shoff
.int 0 # e_flags
@@ -90,12 +90,12 @@ normalize:
phdr:
.int PT_LOAD # p_type
.int (SETUPSECTS+1)*512 # p_offset
- .int __PAGE_OFFSET + CONFIG_PHYSICAL_START # p_vaddr
- .int CONFIG_PHYSICAL_START # p_paddr
+ .int LOAD_PHYSICAL_ADDR + __PAGE_OFFSET # p_vaddr
+ .int LOAD_PHYSICAL_ADDR # p_paddr
.int SYSSIZE*16 # p_filesz
.int 0 # p_memsz
.int PF_R | PF_W | PF_X # p_flags
- .int 4*1024*1024 # p_align
+ .int CONFIG_PHYSICAL_ALIGN # p_align
e_phdr1:

.int PT_NOTE # p_type
diff -puN arch/i386/boot/compressed/vmlinux.lds~i386-implement-config-physical-align-option arch/i386/boot/compressed/vmlinux.lds
--- linux-2.6.18-rc3-1M/arch/i386/boot/compressed/vmlinux.lds~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/boot/compressed/vmlinux.lds 2006-08-17 10:56:46.000000000 -0400
@@ -3,6 +3,9 @@ OUTPUT_ARCH(i386)
ENTRY(startup_32)
SECTIONS
{
+ /* Be careful parts of head.S assume startup_32 is at
+ * address 0.
+ */
. = 0 ;
.text.head : {
_head = . ;
diff -puN arch/i386/boot/compressed/head.S~i386-implement-config-physical-align-option arch/i386/boot/compressed/head.S
--- linux-2.6.18-rc3-1M/arch/i386/boot/compressed/head.S~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/boot/compressed/head.S 2006-08-17 11:12:51.000000000 -0400
@@ -27,6 +27,7 @@
#include <linux/linkage.h>
#include <asm/segment.h>
#include <asm/page.h>
+#include <asm/boot.h>

.section ".text.head"
.globl startup_32
@@ -53,17 +54,19 @@ startup_32:
1: popl %ebp
subl $1b, %ebp

-/* Compute the delta between where we were compiled to run at
- * and where the code will actually run at.
+
+/* %ebp contains the address we are loaded at by the boot loader and %ebx
+ * contains the address where we should move the kernel image temporarily
+ * for safe in-place decompression.
*/
- /* Start with the delta to where the kernel will run at. If we are
- * a relocatable kernel this is the delta to our load address otherwise
- * this is the delta to CONFIG_PHYSICAL start.
- */
+
#ifdef CONFIG_RELOCTABLE
- movl %ebp, %ebx
+ movl %ebp, %ebx
+ addl $(CONFIG_PHYSICAL_ALIGN - 1), %ebx
+ andl $(~(CONFIG_PHYSICAL_ALIGN - 1)), %ebx
+
#else
- movl $(CONFIG_PHYSICAL_START - startup_32), %ebx
+ movl $LOAD_PHYSICAL_ADDR, %ebx
#endif

/* Replace the compressed data size with the uncompressed size */
@@ -95,9 +98,10 @@ startup_32:
/* Compute the kernel start address.
*/
#ifdef CONFIG_RELOCATABLE
- leal startup_32(%ebp), %ebp
+ addl $(CONFIG_PHYSICAL_ALIGN - 1), %ebp
+ andl $(~(CONFIG_PHYSICAL_ALIGN - 1)), %ebp
#else
- movl $CONFIG_PHYSICAL_START, %ebp
+ movl $LOAD_PHYSICAL_ADDR, %ebp
#endif

/*
@@ -151,8 +155,8 @@ relocated:
* and where it was actually loaded.
*/
movl %ebp, %ebx
- subl $CONFIG_PHYSICAL_START, %ebx
-
+ subl $LOAD_PHYSICAL_ADDR, %ebx
+ jz 2f /* Nothing to be done if loaded at compiled addr. */
/*
* Process relocations.
*/
diff -puN arch/i386/boot/compressed/misc.c~i386-implement-config-physical-align-option arch/i386/boot/compressed/misc.c
--- linux-2.6.18-rc3-1M/arch/i386/boot/compressed/misc.c~i386-implement-config-physical-align-option 2006-08-17 10:56:46.000000000 -0400
+++ linux-2.6.18-rc3-1M-root/arch/i386/boot/compressed/misc.c 2006-08-17 11:19:05.000000000 -0400
@@ -18,6 +18,7 @@
#include <asm/io.h>
#include <asm/setup.h>
#include <asm/page.h>
+#include <asm/boot.h>

/* WARNING!!
* This code is compiled with -fPIC and it is relocated dynamically
@@ -585,12 +586,12 @@ asmlinkage void decompress_kernel(void *
insize = input_len;
inptr = 0;

- if (((u32)output - CONFIG_PHYSICAL_START) & 0x3fffff)
- error("Destination address not 4M aligned");
+ if ((u32)output & (CONFIG_PHYSICAL_ALIGN -1))
+ error("Destination address not CONFIG_PHYSICAL_ALIGN aligned");
if (end > ((-__PAGE_OFFSET-(512 <<20)-1) & 0x7fffffff))
error("Destination address too large");
#ifndef CONFIG_RELOCATABLE
- if ((u32)output != CONFIG_PHYSICAL_START)
+ if ((u32)output != LOAD_PHYSICAL_ADDR)
error("Wrong destination address");
#endif

_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Yinghai Lu · External Since: Oct 25, 2006 Posts: 12

On 8/1/06, Eric W. Biederman <ebiederm.DeleteThis@xmission.com> wrote:
> I guess I could take this in some slightly smaller steps.
> But this does wind up with decompressor being 64bit code.

Sorry to bring out the old mail.

except reusing the uncompressor in 32bit, is there any reason that you
removed startup_32 for vmlinux but keep startup_32 for bzImage?

that will make vmlinux use 64bit boot loader only.

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Eric W. Biederman · External Since: May 19, 2006 Posts: 1134

"Yinghai Lu" <yinghai.lu RemoveThis @amd.com> writes:

> On 8/1/06, Eric W. Biederman <ebiederm RemoveThis @xmission.com> wrote:
>> I guess I could take this in some slightly smaller steps.
>> But this does wind up with decompressor being 64bit code.
>
> Sorry to bring out the old mail.
>
> except reusing the uncompressor in 32bit, is there any reason that you
> removed startup_32 for vmlinux but keep startup_32 for bzImage?
>
> that will make vmlinux use 64bit boot loader only.

If you are booting a vmlinux you read the ELF header. The ELF header
only describes the native mode. Therefore no 32bit entry makes much sense.

bzImage is something else entirely.

Eric

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Yinghai Lu · External Since: Oct 25, 2006 Posts: 12

On 11/4/06, Eric W. Biederman <ebiederm.DeleteThis@xmission.com> wrote:
> If you are booting a vmlinux you read the ELF header. The ELF header
> only describes the native mode. Therefore no 32bit entry makes much sense.
>
Yes, but if you keep the startup_32 and it will be at 0x200000, and
startup_64 will be 0x200100. and entry point in ELF header is
0x200100.
by removing startup_32, startup_64 will be 0x200000. and entry point
in ehdr is 0x200000.
So I assume entry_point in elf_header could be used by 64bit
bootloader and phdr[1].p_addr could be used by 32bit boot loader.

YH

ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x200100
Start of program headers: 64 (bytes into file)
Start of section headers: 7192496 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 42
Section header string table index: 39

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000100000 0xffffffff80200000 0x0000000000200000
0x000000000032f508 0x000000000032f508 R E 100000
LOAD 0x0000000000430000 0xffffffff80530000 0x0000000000530000
0x0000000000148ec8 0x0000000000148ec8 RWE 100000
LOAD 0x0000000000600000 0xffffffffff600000 0x0000000000679000
0x0000000000000c08 0x0000000000000c08 RWE 100000
LOAD 0x000000000067a000 0xffffffff8067a000 0x000000000067a000
0x000000000005dd68 0x00000000000e91c8 RWE 100000
NOTE 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 R 8
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/