virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
	v12n <virtualization@lists.linux-foundation.org>,
	Vivek Goyal <vgoyal@in.ibm.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [PATCH RFC 6/7] i386: make the bzImage payload an ELF file
Date: Wed, 06 Jun 2007 16:41:30 -0700	[thread overview]
Message-ID: <4667462A.2010404@zytor.com> (raw)
In-Reply-To: <20070606230922.476662240@goop.org>

Jeremy Fitzhardinge wrote:
> This patch makes the payload of the bzImage file an ELF file.  In
> other words, the bzImage is structured as follows:
>  - boot sector
>  - 16bit setup code
>  - ELF header
>   - decompressor
>   - compressed kernel
> 
> A bootloader may find the start of the ELF file by looking at the
> setup_size entry in the boot params, and using that to find the offset
> of the ELF header.  The ELF Phdrs contain all the mapped memory
> required to decompress and start booting the kernel.
> 
> One slightly complex part of this is that the bzImage boot_params need
> to know about the internal structure of the ELF file, at least to the
> extent of being able to point the core32_start entry at the ELF file's
> entrypoint, so that loaders which use this field will still work.
> 
> Similarly, the ELF header needs to know how big the kernel vmlinux's
> bss segment is, in order to make sure is is mapped properly.
> 
> To handle these two cases, we generate abstracted versions of the
> object files which only contain the symbols we care about (generated
> with objcopy --strip-all --keep-symbol=X), and then include those
> symbol tables with ld -R.

I still believe that we should provide, in effect, vmlinux as a
(compressed) ELF file rather than provide the intermediate stage.  It
would reduce the complexity of testing (all information provided about a
stage have to be both guaranteed to even make sense in the future as
well as be tested to conform to such information) as well as cover a
larger number of environments -- any environment where injecting data
into memory is cheaper than execution is quite unhappy about the current
system.  Such environments include heterogeneous embedded systems (think
a slow CPU on a PCI card where the host CPU has direct access to the
memory on the card) as well as simulators/emulators.

For environments where so is appropriate it would even be possible to
run the setup, invoke the code32_setup hook to do the decompression (and
relocation, if appropriate) in host space.

This makes vmlinux (normally stripped) recoverable from the bzImage file
and so anything that is currently booting vmlinux would be serviced by
this scheme.

	-hpa

  reply	other threads:[~2007-06-06 23:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 22:58 [PATCH RFC 0/7] proposed updates to boot protocol and paravirt booting Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 1/7] update boot spec to 2.07 Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 2/7] add WEAK() for creating weak asm labels Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 3/7] allow linux/elf.h to be included in assembler Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 4/7] define ELF notes for adding to a boot image Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 5/7] i386: clean up bzImage generation Jeremy Fitzhardinge
2007-06-06 22:58 ` [PATCH RFC 6/7] i386: make the bzImage payload an ELF file Jeremy Fitzhardinge
2007-06-06 23:41   ` H. Peter Anvin [this message]
2007-06-06 23:56     ` Jeremy Fitzhardinge
     [not found]     ` <466749C8.2010700@goop.org>
2007-06-07  0:08       ` H. Peter Anvin
     [not found]       ` <46674C96.7090104@zytor.com>
2007-06-07  0:20         ` Jeremy Fitzhardinge
     [not found]         ` <46674F68.6030100@goop.org>
2007-06-07  0:42           ` H. Peter Anvin
     [not found]           ` <4667547B.8080502@zytor.com>
2007-06-07  1:01             ` Jeremy Fitzhardinge
2007-06-08  3:49             ` Vivek Goyal
     [not found]             ` <20070608034958.GA10728@in.ibm.com>
2007-06-08  4:01               ` H. Peter Anvin
2007-06-07  1:47     ` Rob Landley
     [not found]     ` <200706062147.21225.rob@landley.net>
2007-06-07  1:54       ` H. Peter Anvin
2007-06-07 16:08         ` Rob Landley
     [not found]         ` <200706071208.04777.rob@landley.net>
2007-06-07 16:14           ` H. Peter Anvin
2007-06-06 22:58 ` [PATCH RFC 7/7] i386: paravirt boot sequence Jeremy Fitzhardinge

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=4667462A.2010404@zytor.com \
    --to=hpa@zytor.com \
    --cc=ebiederm@xmission.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@in.ibm.com \
    --cc=virtualization@lists.linux-foundation.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).