From: "H. Peter Anvin" <hpa@zytor.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: hacklu <embedway.linux@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: why the decompressed procedure move kernel from address 0x100000(1M) to 0x1000000(16M) +x
Date: Sat, 02 Jun 2012 20:10:08 -0700 [thread overview]
Message-ID: <4FCAD590.8000506@zytor.com> (raw)
In-Reply-To: <87ipf9gtsb.fsf@xmission.com>
On 06/02/2012 04:48 PM, Eric W. Biederman wrote:
On 06/02/2012 04:48 PM, Eric W. Biederman wrote:
> hacklu <embedway.linux@gmail.com> writes:
>
>> hi all,
>> recently, I got some puzzle when I read source code of the system boot. I need
>> some help.
>>
>> at the end of src/arch/x86/boot/header.S, kernel jump to 0x100000(where is the
>> src/arch/x86/boot/compressed/head_32.S).
>> in __this__ head_32.S, I found the kernel is move to 0x1000000(mostly is to
>> here) +x. the x distance is used for decompressed buf. must leave some distance
>> for decompressing without overlap.
>>
>> after the move, kernel is decompressed at 0x1000000(16m). and jump to it.
>>
>> so why not decompressed kernel at 0x100000(1M) to 0x1000000(16m) directly
>> without moving?
>>
>> is the move necessary?
>
> The move is nececcessary if we are doing the decompression in place.
> Without a move it is hard to tell if there are going to be overlapping
> address problems. The move is cheap so there is no apparent reason
> to optimize it away.
>
Well, right now we do two copies (one before decompression, and one
after while parsing the ELF payload.) It would be nice to get rid of at
least one but preferably both (when possible.)
Boot time does matter, although this isn't a huge amount of time, it is
something that can be shaved off relatively cheaply.
-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:[~2012-06-03 3:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 5:56 why the decompressed procedure move kernel from address 0x100000(1M) to 0x1000000(16M) +x hacklu
2012-06-02 23:48 ` Eric W. Biederman
2012-06-03 3:10 ` H. Peter Anvin [this message]
2012-06-03 8:41 ` Eric W. Biederman
2012-06-03 13:01 ` H. Peter Anvin
2012-06-03 20:30 ` [PATCH 1/2] x86, boot: Don't overlap the compressed and non-compressed image Eric W. Biederman
2012-06-03 20:32 ` [PATCH 2/2] x86, boot: Optimize the elf header handling Eric W. Biederman
2012-07-01 14:56 ` [tip:x86/boot] " tip-bot for Eric W. Biederman
2012-07-01 15:04 ` [PATCH 2/2] " H. Peter Anvin
2012-07-01 15:34 ` H. Peter Anvin
2012-07-01 16:08 ` Eric W. Biederman
2012-07-01 16:11 ` H. Peter Anvin
2012-07-01 16:26 ` Eric W. Biederman
2012-07-01 16:44 ` H. Peter Anvin
2012-07-01 17:09 ` Eric W. Biederman
2012-07-01 17:15 ` H. Peter Anvin
2012-07-01 18:25 ` Eric W. Biederman
2012-07-01 18:37 ` H. Peter Anvin
2012-07-01 19:20 ` Eric W. Biederman
2012-07-01 19:23 ` H. Peter Anvin
2012-07-01 20:40 ` Eric W. Biederman
2012-07-01 20:52 ` H. Peter Anvin
2012-07-09 6:50 ` Eric W. Biederman
2012-07-09 6:52 ` [PATCH 1/4] x86 boot: Jump to the entry point address in the elf header Eric W. Biederman
2012-07-09 6:53 ` [PATCH 2/4] x86 boot: Optimize the elf header handling Eric W. Biederman
2012-07-09 6:55 ` [PATCH 3/4] x86 boot: When building vmlinux.bin properly precompute the memory image Eric W. Biederman
2012-07-09 6:56 ` [PATCH 4/4] x86 boot: Tell ld the kernel doesn't want 2MB file offset alignment Eric W. Biederman
2012-07-09 6:59 ` [PATCH 1/4] x86 boot: Jump to the entry point address in the elf header Eric W. Biederman
2012-07-02 16:56 ` [PATCH 2/2] x86, boot: Optimize the elf header handling Tejun Heo
2012-07-09 7:03 ` Eric W. Biederman
2012-07-01 2:23 ` [PATCH 1/2] x86, boot: Don't overlap the compressed and non-compressed image Eric W. Biederman
2012-07-01 2:32 ` H. Peter Anvin
2012-07-01 5:22 ` Eric W. Biederman
2012-07-01 14:55 ` [tip:x86/boot] x86, boot: Don' t " tip-bot for Eric W. Biederman
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=4FCAD590.8000506@zytor.com \
--to=hpa@zytor.com \
--cc=ebiederm@xmission.com \
--cc=embedway.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).