[PATCHv3 0/3] x86: boot protocol updates. - Kernel

This is a discussion on [PATCHv3 0/3] x86: boot protocol updates. - Kernel ; Updates since last time: - Rebased to latest x86.git#mm (no changes required). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: H. Peter Anvin Cc: Jeremy Fitzhardinge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of ...

+ Reply to Thread
Results 1 to 18 of 18

Thread: [PATCHv3 0/3] x86: boot protocol updates.

  1. [PATCHv3 0/3] x86: boot protocol updates.

    Updates since last time:
    - Rebased to latest x86.git#mm (no changes required).

    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: Jeremy Fitzhardinge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    On Wed, 2008-02-13 at 20:54 +0000, Ian Campbell wrote:
    > This allows other boot loaders such as the Xen domain builder the
    > opportunity to extract the ELF file.


    Right, Xen currently can't boot bzImage (it needs the ELF image) so you
    still can't use the same kernel image on Xen as bare-metal.

    > +Field name: compressed_payload_offset
    > +Type: read
    > +Offset/size: 0x248/4
    > +Protocol: 2.08+
    > +
    > + If non-zero then this field contains the offset from the end of the
    > + real-mode code to the compressed payload. The compression format
    > + should be determined using the standard magic number, currently only
    > + gzip is used.


    Should probably mention that the payload format is expected to be ELF.

    > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
    > index f88458e..9695aff 100644
    > --- a/arch/x86/boot/Makefile
    > +++ b/arch/x86/boot/Makefile
    > @@ -94,6 +94,20 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
    >
    > SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
    >
    > +sed-offsets := -e 's/^00*/0/' \
    > + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/\#define \2 0x\1/p'
    > +
    > +quiet_cmd_offsets = OFFSETS $@
    > + cmd_offsets = $(NM) $< | sed -n $(sed-offsets) > $@
    > +
    > +$(obj)/offsets.h: $(obj)/compressed/vmlinux FORCE
    > + $(call if_changed,offsets)
    > +
    > +targets += offsets.h
    > +
    > +AFLAGS_header.o += -I$(obj)
    > +$(obj)/header.o: $(obj)/offsets.h


    How about this?

    +sed-offsets := -e 's/^00*/0/' \
    + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/-D\2=0x\1 /p'
    +
    +$(obj)/header.o: AFLAGS_header.o += $(shell $(NM) $(obj)/compressed/vmlinux | sed -n $(sed-offsets))
    +$(obj)/header.o: $(obj)/compressed/vmlinux FORCE

    Cheers,
    Mark.

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

  3. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    On Thu, 2008-02-14 at 17:01 +0000, Ian Campbell wrote:
    > On Thu, 2008-02-14 at 11:34 +0000, Mark McLoughlin wrote:
    > > On Wed, 2008-02-13 at 20:54 +0000, Ian Campbell wrote:
    > > > This allows other boot loaders such as the Xen domain builder the
    > > > opportunity to extract the ELF file.

    > >
    > > Right, Xen currently can't boot bzImage (it needs the ELF image) so you
    > > still can't use the same kernel image on Xen as bare-metal.

    >
    > I have a xen domain builder patch as well. I was waiting for the Linux
    > side to gain some traction before putting it forward (I'd attach it now
    > but it's at home on a laptop which is sleeping).


    Yep, just want to highlight to people that your patches (or an
    alternative) are needed before the same pv_ops kernel truly can be used
    on bare-metal and Xen.

    > > How about this?
    > >
    > > +sed-offsets := -e 's/^00*/0/' \
    > > + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/-D\2=0x\1 /p'
    > > +
    > > +$(obj)/header.o: AFLAGS_header.o += $(shell $(NM) $(obj)/compressed/vmlinux | sed -n $(sed-offsets))
    > > +$(obj)/header.o: $(obj)/compressed/vmlinux FORCE

    >
    > That's probably a neater way of doing it. Although the ".../header.o:
    > AFLAGS_header.o" is redundant, either
    > header.o: AFLAGS += foo


    With this, AFLAGS would apply to building when building the
    prerequisites of header.o too, which you don't want

    The make manual says:

    "when you define a target-specific variable that variable value is
    also in effect for all prerequisites of this target, and all their
    prerequisites"

    > or
    > AFLAGS_header.o += foo
    > with the second being preferred in Linux Makefiles I think.


    And with this, it would try and read vmlinux before it is built.

    But, hmm, given the fact that the variable is defined when building
    prerequisites, you'd think that even in my version AFLAGS would be
    evaluated before building vmlinux.

    Cheers,
    Mark.

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

  4. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.


    On Thu, 2008-02-14 at 17:01 +0000, Ian Campbell wrote:
    >
    > I have a xen domain builder patch as well. I was waiting for the Linux
    > side to gain some traction before putting it forward (I'd attach it
    > now but it's at home on a laptop which is sleeping).


    Here it is:

    # HG changeset patch
    # User ijc@hellion.org.uk
    # Date 1203011758 0
    # Node ID 3079b4b3835e3aba52bb6548bbbced70471a9f32
    # Parent 42369d21641d6297dc369441c3bfd355880d28c0
    Support loading Linux bzImage v2.08 and up.

    Signed-off-by : Ian Campbell

    diff -r 42369d21641d -r 3079b4b3835e tools/libxc/Makefile
    --- a/tools/libxc/Makefile Thu Jan 31 16:23:35 2008 +0000
    +++ b/tools/libxc/Makefile Thu Feb 14 17:55:58 2008 +0000
    @@ -40,6 +40,7 @@ GUEST_SRCS-y += libelf-dominfo.c libelf-
    # new domain builder
    GUEST_SRCS-y += xc_dom_core.c xc_dom_boot.c
    GUEST_SRCS-y += xc_dom_elfloader.c
    +GUEST_SRCS-y += xc_dom_bzimageloader.c
    GUEST_SRCS-y += xc_dom_binloader.c
    GUEST_SRCS-y += xc_dom_compat_linux.c

    diff -r 42369d21641d -r 3079b4b3835e tools/libxc/xc_dom_bzimageloader.c
    --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/tools/libxc/xc_dom_bzimageloader.c Thu Feb 14 17:55:58 2008 +0000
    @@ -0,0 +1,159 @@
    +/*
    + * Xen domain builder -- bzImage bits
    + *
    + * Parse and load bzImage kernel images.
    + *
    + * This relies on version 2.08 of the boot protocol, which contains an
    + * ELF file embedded in the bzImage. The loader extracts this ELF
    + * image and passes it off to the standard ELF loader.
    + *
    + * This code is licenced under the GPL.
    + * written 2006 by Gerd Hoffmann .
    + * written 2007 by Jeremy Fitzhardinge
    + * written 2008 by Ian Campbell
    + *
    + */
    +#include
    +#include
    +#include
    +
    +#include "xg_private.h"
    +#include "xc_dom.h"
    +
    +struct setup_header {
    + uint8_t _pad0[0x1f1]; /* skip uninteresting stuff */
    + uint8_t setup_sects;
    + uint16_t root_flags;
    + uint32_t syssize;
    + uint16_t ram_size;
    + uint16_t vid_mode;
    + uint16_t root_dev;
    + uint16_t boot_flag;
    + uint16_t jump;
    + uint32_t header;
    +#define HDR_MAGIC "HdrS"
    +#define HDR_MAGIC_SZ 4
    + uint16_t version;
    +#define VERSION(h,l) (((h)<<8) | (l))
    + uint32_t realmode_swtch;
    + uint16_t start_sys;
    + uint16_t kernel_version;
    + uint8_t type_of_loader;
    + uint8_t loadflags;
    + uint16_t setup_move_size;
    + uint32_t code32_start;
    + uint32_t ramdisk_image;
    + uint32_t ramdisk_size;
    + uint32_t bootsect_kludge;
    + uint16_t heap_end_ptr;
    + uint16_t _pad1;
    + uint32_t cmd_line_ptr;
    + uint32_t initrd_addr_max;
    + uint32_t kernel_alignment;
    + uint8_t relocatable_kernel;
    + uint8_t _pad2[3];
    + uint32_t cmdline_size;
    + uint32_t hardware_subarch;
    + uint64_t hardware_subarch_data;
    + uint32_t compressed_payload_offset;
    + uint32_t compressed_payload_length;
    +} __attribute__((packed));
    +
    +extern struct xc_dom_loader elf_loader;
    +
    +static unsigned int compressed_offset(struct setup_header *hdr)
    +{
    + unsigned int off;
    +
    + off = (hdr->setup_sects + 1) * 512;
    + off += hdr->compressed_payload_offset;
    + return off;
    +}
    +
    +static int check_bzimage_kernel(struct xc_dom_image *dom, int verbose)
    +{
    + struct setup_header *hdr;
    +
    + if ( dom->kernel_blob == NULL )
    + {
    + if ( verbose )
    + xc_dom_panic(XC_INTERNAL_ERROR, "%s: no kernel image loaded\n",
    + __FUNCTION__);
    + return -EINVAL;
    + }
    + if ( dom->kernel_size < sizeof(struct setup_header) )
    + {
    + if ( verbose )
    + xc_dom_panic(XC_INTERNAL_ERROR, "%s: kernel image too small\n",
    + __FUNCTION__);
    + return -EINVAL;
    + }
    +
    + hdr = dom->kernel_blob;
    +
    + if ( memcmp(&hdr->header, HDR_MAGIC, HDR_MAGIC_SZ) != 0 )
    + {
    + if ( verbose )
    + xc_dom_panic(XC_INVALID_KERNEL, "%s: kernel is not a bzImage\n",
    + __FUNCTION__);
    + return -EINVAL;
    + }
    +
    + if ( hdr->version < VERSION(2,8) )
    + {
    + if ( verbose )
    + xc_dom_panic(XC_INVALID_KERNEL, "%s: boot protocol too old (%04x)\n",
    + __FUNCTION__, hdr->version);
    + return -EINVAL;
    + }
    +
    + dom->kernel_blob = dom->kernel_blob + compressed_offset(hdr);
    + dom->kernel_size = hdr->compressed_payload_length;
    +
    + if ( xc_dom_try_gunzip(dom, &dom->kernel_blob, &dom->kernel_size) == -1 )
    + {
    + if ( verbose )
    + xc_dom_panic(XC_INVALID_KERNEL, "%s: unable to decompress kernel\n",
    + __FUNCTION__);
    + return -EINVAL;
    + }
    +
    + return elf_loader.probe(dom);
    +}
    +
    +static int xc_dom_probe_bzimage_kernel(struct xc_dom_image *dom)
    +{
    + return check_bzimage_kernel(dom, 0);
    +}
    +
    +static int xc_dom_parse_bzimage_kernel(struct xc_dom_image *dom)
    +{
    + return elf_loader.parser(dom);
    +}
    +
    +static int xc_dom_load_bzimage_kernel(struct xc_dom_image *dom)
    +{
    + return elf_loader.loader(dom);
    +}
    +
    +static struct xc_dom_loader bzimage_loader = {
    + .name = "Linux bzImage",
    + .probe = xc_dom_probe_bzimage_kernel,
    + .parser = xc_dom_parse_bzimage_kernel,
    + .loader = xc_dom_load_bzimage_kernel,
    +};
    +
    +static void __init register_loader(void)
    +{
    + xc_dom_register_loader(&bzimage_loader);
    +}
    +
    +/*
    + * Local variables:
    + * mode: C
    + * c-set-style: "BSD"
    + * c-basic-offset: 4
    + * tab-width: 4
    + * indent-tabs-mode: nil
    + * End:
    + */
    diff -r 42369d21641d -r 3079b4b3835e tools/libxc/xc_dom_elfloader.c
    --- a/tools/libxc/xc_dom_elfloader.c Thu Jan 31 16:23:35 2008 +0000
    +++ b/tools/libxc/xc_dom_elfloader.c Thu Feb 14 17:55:58 2008 +0000
    @@ -281,7 +281,7 @@ static int xc_dom_load_elf_kernel(struct

    /* ------------------------------------------------------------------------ */

    -static struct xc_dom_loader elf_loader = {
    +struct xc_dom_loader elf_loader = {
    .name = "ELF-generic",
    .probe = xc_dom_probe_elf_kernel,
    .parser = xc_dom_parse_elf_kernel,

    --
    Ian Campbell

    The English have no respect for their language, and will not teach
    their children to speak it.
    -- G. B. Shaw

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

  5. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.


    On Thu, 2008-02-14 at 17:37 +0000, Mark McLoughlin wrote:
    > On Thu, 2008-02-14 at 17:01 +0000, Ian Campbell wrote:
    > With this, AFLAGS would apply to building when building the
    > prerequisites of header.o too, which you don't want
    >
    > The make manual says:
    >
    > "when you define a target-specific variable that variable value is
    > also in effect for all prerequisites of this target, and all their
    > prerequisites"


    Ah yes, quite right.

    I think given that subtleties of these kinds of variable definitions
    it's probably clearer to stick with the header file way of doing things.
    it's nice and straight forward.

    Ian.
    --
    Ian Campbell

    Davis' Law of Traffic Density:
    The density of rush-hour traffic is directly proportional to
    1.5 times the amount of extra time you allow to arrive on time.

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

  6. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.


    On Thu, 2008-02-14 at 17:01 +0000, Ian Campbell wrote:
    >
    > > > +Field name: compressed_payload_offset
    > > > +Type: read
    > > > +Offset/size: 0x248/4
    > > > +Protocol: 2.08+
    > > > +
    > > > + If non-zero then this field contains the offset from the end of

    > the
    > > > + real-mode code to the compressed payload. The compression

    > format
    > > > + should be determined using the standard magic number, currently

    > only
    > > > + gzip is used.

    > >
    > > Should probably mention that the payload format is expected to

    > be ELF.
    >
    > Agreed. Probably the same deal as the compression format, i.e. use the
    > magic number but only ELF is possible today (even less likely to
    > change than the compression format I guess...).


    Updated with a note about ELF format payload.

    I've also changed the fields to just payload_{offset,length} and
    adjusted the description to allow for the possibility of non-compressed
    ELF payloads. I don't have a use for it myself but I can see how it
    might be useful (embedded systems?) so it seems reasonable not to rule
    it out. ELF-in-gzip and plain ELF can both be identified by magic
    numbers.

    Ian.
    ---
    >From 544c003d4067d895556180fc11a951e211202d0d Mon Sep 17 00:00:00 2001

    From: Ian Campbell
    Date: Thu, 14 Feb 2008 18:29:01 +0000
    Subject: [PATCH] x86: use ELF format in compressed images.

    This allows other boot loaders such as the Xen domain builder the
    opportunity to extract the ELF file.

    Signed-off-by: Ian Campbell
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: Jeremy Fitzhardinge
    Cc: virtualization@lists.linux-foundation.org
    ---
    Documentation/i386/boot.txt | 20 +++++++++++++
    arch/x86/boot/Makefile | 14 +++++++++
    arch/x86/boot/compressed/Makefile | 2 +-
    arch/x86/boot/compressed/misc.c | 56 +++++++++++++++++++++++++++++++++++++
    arch/x86/boot/header.S | 4 ++
    5 files changed, 95 insertions(+), 1 deletions(-)

    diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
    index fc49b79..f2e54e5 100644
    --- a/Documentation/i386/boot.txt
    +++ b/Documentation/i386/boot.txt
    @@ -170,6 +170,8 @@ Offset Proto Name Meaning
    0238/4 2.06+ cmdline_size Maximum size of the kernel command line
    023C/4 2.07+ hardware_subarch Hardware subarchitecture
    0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
    +0248/4 2.08+ payload_offset Offset of kernel payload
    +024C/4 2.08+ payload_length Length of kernel payload

    (1) For backwards compatibility, if the setup_sects field contains 0, the
    real value is 4.
    @@ -512,6 +514,24 @@ Protocol: 2.07+

    A pointer to data that is specific to hardware subarch

    +Field name: payload_offset
    +Type: read
    +Offset/size: 0x248/4
    +Protocol: 2.08+
    +
    + If non-zero then this field contains the offset from the end of the
    + real-mode code to the payload.
    +
    + The payload may be compressed. The format of both the compressed and
    + uncompressed data should be determined using the standard magic
    + numbers. Currently only gzip compressed ELF is used.
    +
    +Field name: payload_length
    +Type: read
    +Offset/size: 0x24c/4
    +Protocol: 2.08+
    +
    + The length of the payload.

    **** THE KERNEL COMMAND LINE

    diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
    index f88458e..9695aff 100644
    --- a/arch/x86/boot/Makefile
    +++ b/arch/x86/boot/Makefile
    @@ -94,6 +94,20 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE

    SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))

    +sed-offsets := -e 's/^00*/0/' \
    + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/\#define \2 0x\1/p'
    +
    +quiet_cmd_offsets = OFFSETS $@
    + cmd_offsets = $(NM) $< | sed -n $(sed-offsets) > $@
    +
    +$(obj)/offsets.h: $(obj)/compressed/vmlinux FORCE
    + $(call if_changed,offsets)
    +
    +targets += offsets.h
    +
    +AFLAGS_header.o += -I$(obj)
    +$(obj)/header.o: $(obj)/offsets.h
    +
    LDFLAGS_setup.elf := -T
    $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
    $(call if_changed,ld)
    diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
    index d2b9f3b..92fdd35 100644
    --- a/arch/x86/boot/compressed/Makefile
    +++ b/arch/x86/boot/compressed/Makefile
    @@ -22,7 +22,7 @@ $(obj)/vmlinux: $(src)/vmlinux_$(BITS).lds $(obj)/head_$(BITS).o $(obj)/misc.o $
    $(call if_changed,ld)
    @:

    -OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
    +OBJCOPYFLAGS_vmlinux.bin := -R .comment -S
    $(obj)/vmlinux.bin: vmlinux FORCE
    $(call if_changed,objcopy)

    diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
    index 8182e32..69aec2f 100644
    --- a/arch/x86/boot/compressed/misc.c
    +++ b/arch/x86/boot/compressed/misc.c
    @@ -15,6 +15,10 @@
    * we just keep it from happening
    */
    #undef CONFIG_PARAVIRT
    +#ifdef CONFIG_X86_32
    +#define _ASM_DESC_H_ 1
    +#endif
    +
    #ifdef CONFIG_X86_64
    #define _LINUX_STRING_H_ 1
    #define __LINUX_BITMAP_H 1
    @@ -22,6 +26,7 @@

    #include
    #include
    +#include
    #include
    #include
    #include
    @@ -365,6 +370,56 @@ static void error(char *x)
    asm("hlt");
    }

    +static void parse_elf(void *output)
    +{
    +#ifdef CONFIG_X86_64
    + Elf64_Ehdr ehdr;
    + Elf64_Phdr *phdrs, *phdr;
    +#else
    + Elf32_Ehdr ehdr;
    + Elf32_Phdr *phdrs, *phdr;
    +#endif
    + void *dest;
    + int i;
    +
    + memcpy(&ehdr, output, sizeof(ehdr));
    + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 ||
    + ehdr.e_ident[EI_MAG1] != ELFMAG1 ||
    + ehdr.e_ident[EI_MAG2] != ELFMAG2 ||
    + ehdr.e_ident[EI_MAG3] != ELFMAG3)
    + {
    + error("Kernel is not a valid ELF file");
    + return;
    + }
    +
    + putstr("Parsing ELF... ");
    +
    + phdrs = malloc(sizeof(*phdrs) * ehdr.e_phnum);
    + if (!phdrs)
    + error("Failed to allocate space for phdrs");
    +
    + memcpy(phdrs, output + ehdr.e_phoff, sizeof(*phdrs) * ehdr.e_phnum);
    +
    + for (i=0; i + phdr = &phdrs[i];
    +
    + switch (phdr->p_type) {
    + case PT_LOAD:
    +#ifdef CONFIG_RELOCATABLE
    + dest = output;
    + dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);
    +#else
    + dest = (void*)(phdr->p_paddr);
    +#endif
    + memcpy(dest,
    + output + phdr->p_offset,
    + phdr->p_filesz);
    + break;
    + default: /* Ignore other PT_* */ break;
    + }
    + }
    +}
    +
    asmlinkage void decompress_kernel(void *rmode, memptr heap,
    uch *input_data, unsigned long input_len,
    uch *output)
    @@ -408,6 +463,7 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
    makecrc();
    putstr("\nDecompressing Linux... ");
    gunzip();
    + parse_elf(output);
    putstr("done.\nBooting the kernel.\n");
    return;
    }
    diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
    index 64ad901..4085616 100644
    --- a/arch/x86/boot/header.S
    +++ b/arch/x86/boot/header.S
    @@ -22,6 +22,7 @@
    #include
    #include
    #include "boot.h"
    +#include "offsets.h"

    SETUPSECTS = 4 /* default nr of setup-sectors */
    BOOTSEG = 0x07C0 /* original address of boot-sector */
    @@ -223,6 +224,9 @@ hardware_subarch: .long 0 # subarchitecture, added with 2.07

    hardware_subarch_data: .quad 0

    +payload_offset: .long input_data
    +payload_length: .long input_data_end-input_data
    +
    # End of setup header ################################################## ###

    .section ".inittext", "ax"
    --
    1.5.4



    --
    Ian Campbell

    The moss on the tree does not fear the talons of the hawk.

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

  7. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    Ian Campbell wrote:
    >
    > Agreed. Probably the same deal as the compression format, i.e. use the
    > magic number but only ELF is possible today (even less likely to change
    > than the compression format I guess...).
    >


    Quite.

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

  8. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    Ian Campbell wrote:
    > On Thu, 2008-02-14 at 17:01 +0000, Ian Campbell wrote:
    >
    >> I have a xen domain builder patch as well. I was waiting for the Linux
    >> side to gain some traction before putting it forward (I'd attach it
    >> now but it's at home on a laptop which is sleeping).
    >>

    >
    > Here it is:
    >
    > # HG changeset patch
    > # User ijc@hellion.org.uk
    > # Date 1203011758 0
    > # Node ID 3079b4b3835e3aba52bb6548bbbced70471a9f32
    > # Parent 42369d21641d6297dc369441c3bfd355880d28c0
    > Support loading Linux bzImage v2.08 and up.
    >


    Do you also have a patch to update the boot protocol?

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

  9. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    Jeremy Fitzhardinge wrote:
    >
    > Do you also have a patch to update the boot protocol?
    >


    Looking for anything different than the root of this thread?

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

  10. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    H. Peter Anvin wrote:
    > Jeremy Fitzhardinge wrote:
    >>
    >> Do you also have a patch to update the boot protocol?
    >>

    >
    > Looking for anything different than the root of this thread?


    Yes, the patch for the Xen domain builder to boot a bzImage using the
    Linux boot protocol rather than the Xen one. Ian's patch will extract
    the ELF file from the bzImage, but still boot it by finding the Xen
    entrypoint in the notes, with %esi pointing to the Xen start_info rather
    than the boot_params (unless I'm missing something).

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

  11. Re: [PATCHv3 0/3] x86: boot protocol updates.

    On Wed, 13 Feb 2008, Ian Campbell wrote:

    > Updates since last time:
    > - Rebased to latest x86.git#mm (no changes required).
    >


    Applied. Thanks,

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

  12. Re: [PATCHv3 0/3] x86: boot protocol updates.


    On Sun, 2008-02-17 at 15:04 +0100, Thomas Gleixner wrote:
    > On Wed, 13 Feb 2008, Ian Campbell wrote:
    >
    > > Updates since last time:
    > > - Rebased to latest x86.git#mm (no changes required).
    > >

    >
    > Applied. Thanks,


    Thank you.

    Could you take this version of "1/3 x86: use ELF format in compressed
    images" instead? It contains a slightly improved version of the doc
    section making it clear that ELF is used for the uncompressed data. It
    also renames the field to just payload_{offset,length} so as to not rule
    out the possibility of uncompressed payloads.

    >From 7d2b37d7b0342e748320e2104adbdd8ba0b3666d Mon Sep 17 00:00:00 2001

    From: Ian Campbell
    Date: Thu, 14 Feb 2008 18:29:01 +0000
    Subject: [PATCH] x86: use ELF format in compressed images.

    This allows other boot loaders such as the Xen domain builder the
    opportunity to extract the ELF file.

    Signed-off-by: Ian Campbell
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: H. Peter Anvin
    Cc: Jeremy Fitzhardinge
    Cc: virtualization@lists.linux-foundation.org
    ---
    Documentation/i386/boot.txt | 20 +++++++++++++
    arch/x86/boot/Makefile | 14 +++++++++
    arch/x86/boot/compressed/Makefile | 2 +-
    arch/x86/boot/compressed/misc.c | 56 +++++++++++++++++++++++++++++++++++++
    arch/x86/boot/header.S | 4 ++
    5 files changed, 95 insertions(+), 1 deletions(-)

    diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
    index fc49b79..f2e54e5 100644
    --- a/Documentation/i386/boot.txt
    +++ b/Documentation/i386/boot.txt
    @@ -170,6 +170,8 @@ Offset Proto Name Meaning
    0238/4 2.06+ cmdline_size Maximum size of the kernel command line
    023C/4 2.07+ hardware_subarch Hardware subarchitecture
    0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
    +0248/4 2.08+ payload_offset Offset of kernel payload
    +024C/4 2.08+ payload_length Length of kernel payload

    (1) For backwards compatibility, if the setup_sects field contains 0, the
    real value is 4.
    @@ -512,6 +514,24 @@ Protocol: 2.07+

    A pointer to data that is specific to hardware subarch

    +Field name: payload_offset
    +Type: read
    +Offset/size: 0x248/4
    +Protocol: 2.08+
    +
    + If non-zero then this field contains the offset from the end of the
    + real-mode code to the payload.
    +
    + The payload may be compressed. The format of both the compressed and
    + uncompressed data should be determined using the standard magic
    + numbers. Currently only gzip compressed ELF is used.
    +
    +Field name: payload_length
    +Type: read
    +Offset/size: 0x24c/4
    +Protocol: 2.08+
    +
    + The length of the payload.

    **** THE KERNEL COMMAND LINE

    diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
    index f88458e..9695aff 100644
    --- a/arch/x86/boot/Makefile
    +++ b/arch/x86/boot/Makefile
    @@ -94,6 +94,20 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE

    SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))

    +sed-offsets := -e 's/^00*/0/' \
    + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/\#define \2 0x\1/p'
    +
    +quiet_cmd_offsets = OFFSETS $@
    + cmd_offsets = $(NM) $< | sed -n $(sed-offsets) > $@
    +
    +$(obj)/offsets.h: $(obj)/compressed/vmlinux FORCE
    + $(call if_changed,offsets)
    +
    +targets += offsets.h
    +
    +AFLAGS_header.o += -I$(obj)
    +$(obj)/header.o: $(obj)/offsets.h
    +
    LDFLAGS_setup.elf := -T
    $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
    $(call if_changed,ld)
    diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
    index d2b9f3b..92fdd35 100644
    --- a/arch/x86/boot/compressed/Makefile
    +++ b/arch/x86/boot/compressed/Makefile
    @@ -22,7 +22,7 @@ $(obj)/vmlinux: $(src)/vmlinux_$(BITS).lds $(obj)/head_$(BITS).o $(obj)/misc.o $
    $(call if_changed,ld)
    @:

    -OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
    +OBJCOPYFLAGS_vmlinux.bin := -R .comment -S
    $(obj)/vmlinux.bin: vmlinux FORCE
    $(call if_changed,objcopy)

    diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
    index 8182e32..69aec2f 100644
    --- a/arch/x86/boot/compressed/misc.c
    +++ b/arch/x86/boot/compressed/misc.c
    @@ -15,6 +15,10 @@
    * we just keep it from happening
    */
    #undef CONFIG_PARAVIRT
    +#ifdef CONFIG_X86_32
    +#define _ASM_DESC_H_ 1
    +#endif
    +
    #ifdef CONFIG_X86_64
    #define _LINUX_STRING_H_ 1
    #define __LINUX_BITMAP_H 1
    @@ -22,6 +26,7 @@

    #include
    #include
    +#include
    #include
    #include
    #include
    @@ -365,6 +370,56 @@ static void error(char *x)
    asm("hlt");
    }

    +static void parse_elf(void *output)
    +{
    +#ifdef CONFIG_X86_64
    + Elf64_Ehdr ehdr;
    + Elf64_Phdr *phdrs, *phdr;
    +#else
    + Elf32_Ehdr ehdr;
    + Elf32_Phdr *phdrs, *phdr;
    +#endif
    + void *dest;
    + int i;
    +
    + memcpy(&ehdr, output, sizeof(ehdr));
    + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 ||
    + ehdr.e_ident[EI_MAG1] != ELFMAG1 ||
    + ehdr.e_ident[EI_MAG2] != ELFMAG2 ||
    + ehdr.e_ident[EI_MAG3] != ELFMAG3)
    + {
    + error("Kernel is not a valid ELF file");
    + return;
    + }
    +
    + putstr("Parsing ELF... ");
    +
    + phdrs = malloc(sizeof(*phdrs) * ehdr.e_phnum);
    + if (!phdrs)
    + error("Failed to allocate space for phdrs");
    +
    + memcpy(phdrs, output + ehdr.e_phoff, sizeof(*phdrs) * ehdr.e_phnum);
    +
    + for (i=0; i + phdr = &phdrs[i];
    +
    + switch (phdr->p_type) {
    + case PT_LOAD:
    +#ifdef CONFIG_RELOCATABLE
    + dest = output;
    + dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);
    +#else
    + dest = (void*)(phdr->p_paddr);
    +#endif
    + memcpy(dest,
    + output + phdr->p_offset,
    + phdr->p_filesz);
    + break;
    + default: /* Ignore other PT_* */ break;
    + }
    + }
    +}
    +
    asmlinkage void decompress_kernel(void *rmode, memptr heap,
    uch *input_data, unsigned long input_len,
    uch *output)
    @@ -408,6 +463,7 @@ asmlinkage void decompress_kernel(void *rmode, memptr heap,
    makecrc();
    putstr("\nDecompressing Linux... ");
    gunzip();
    + parse_elf(output);
    putstr("done.\nBooting the kernel.\n");
    return;
    }
    diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
    index 64ad901..4085616 100644
    --- a/arch/x86/boot/header.S
    +++ b/arch/x86/boot/header.S
    @@ -22,6 +22,7 @@
    #include
    #include
    #include "boot.h"
    +#include "offsets.h"

    SETUPSECTS = 4 /* default nr of setup-sectors */
    BOOTSEG = 0x07C0 /* original address of boot-sector */
    @@ -223,6 +224,9 @@ hardware_subarch: .long 0 # subarchitecture, added with 2.07

    hardware_subarch_data: .quad 0

    +payload_offset: .long input_data
    +payload_length: .long input_data_end-input_data
    +
    # End of setup header ################################################## ###

    .section ".inittext", "ax"
    --
    1.5.4


    --
    Ian Campbell

    Modern art is what happens when painters stop looking at girls and persuade
    themselves that they have a better idea.
    -- John Ciardi

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

  13. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    On Wed, Feb 13, 2008 at 1:54 PM, Ian Campbell wrote:
    > This allows other boot loaders such as the Xen domain builder the
    > opportunity to extract the ELF file.
    >
    > Signed-off-by: Ian Campbell
    > Cc: Thomas Gleixner
    > Cc: Ingo Molnar
    > Cc: H. Peter Anvin
    > Cc: Jeremy Fitzhardinge
    > Cc: virtualization@lists.linux-foundation.org
    > ---
    > Documentation/i386/boot.txt | 18 ++++++++++++
    > arch/x86/boot/Makefile | 14 +++++++++
    > arch/x86/boot/compressed/Makefile | 2 +-
    > arch/x86/boot/compressed/misc.c | 56 +++++++++++++++++++++++++++++++++++++
    > arch/x86/boot/header.S | 6 ++++
    > 5 files changed, 95 insertions(+), 1 deletions(-)
    >
    > diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt
    > index fc49b79..b5f5ba1 100644
    > --- a/Documentation/i386/boot.txt
    > +++ b/Documentation/i386/boot.txt
    > @@ -170,6 +170,8 @@ Offset Proto Name Meaning
    > 0238/4 2.06+ cmdline_size Maximum size of the kernel command line
    > 023C/4 2.07+ hardware_subarch Hardware subarchitecture
    > 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data
    > +0248/4 2.08+ compressed_payload_offset
    > +024C/4 2.08+ compressed_payload_length
    >
    > (1) For backwards compatibility, if the setup_sects field contains 0, the
    > real value is 4.
    > @@ -512,6 +514,22 @@ Protocol: 2.07+
    >
    > A pointer to data that is specific to hardware subarch
    >
    > +Field name: compressed_payload_offset
    > +Type: read
    > +Offset/size: 0x248/4
    > +Protocol: 2.08+
    > +
    > + If non-zero then this field contains the offset from the end of the
    > + real-mode code to the compressed payload. The compression format
    > + should be determined using the standard magic number, currently only
    > + gzip is used.
    > +
    > +Field name: compressed_payload_length
    > +Type: read
    > +Offset/size: 0x24c/4
    > +Protocol: 2.08+
    > +
    > + The length of the compressed payload.
    >
    > **** THE KERNEL COMMAND LINE
    >
    > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
    > index f88458e..9695aff 100644
    > --- a/arch/x86/boot/Makefile
    > +++ b/arch/x86/boot/Makefile
    > @@ -94,6 +94,20 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
    >
    > SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
    >
    > +sed-offsets := -e 's/^00*/0/' \
    > + -e 's/^\([0-9a-fA-F]*\) . \(input_data\|input_data_end\)$$/\#define \2 0x\1/p'
    > +
    > +quiet_cmd_offsets = OFFSETS $@
    > + cmd_offsets = $(NM) $< | sed -n $(sed-offsets) > $@
    > +
    > +$(obj)/offsets.h: $(obj)/compressed/vmlinux FORCE
    > + $(call if_changed,offsets)
    > +
    > +targets += offsets.h
    > +
    > +AFLAGS_header.o += -I$(obj)
    > +$(obj)/header.o: $(obj)/offsets.h
    > +
    > LDFLAGS_setup.elf := -T
    > $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
    > $(call if_changed,ld)
    > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
    > index d2b9f3b..92fdd35 100644
    > --- a/arch/x86/boot/compressed/Makefile
    > +++ b/arch/x86/boot/compressed/Makefile
    > @@ -22,7 +22,7 @@ $(obj)/vmlinux: $(src)/vmlinux_$(BITS).lds $(obj)/head_$(BITS).o $(obj)/misc.o $
    > $(call if_changed,ld)
    > @:
    >
    > -OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
    > +OBJCOPYFLAGS_vmlinux.bin := -R .comment -S
    > $(obj)/vmlinux.bin: vmlinux FORCE
    > $(call if_changed,objcopy)
    >
    > diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
    > index 8182e32..69aec2f 100644
    > --- a/arch/x86/boot/compressed/misc.c
    > +++ b/arch/x86/boot/compressed/misc.c
    > @@ -15,6 +15,10 @@
    > * we just keep it from happening
    > */
    > #undef CONFIG_PARAVIRT
    > +#ifdef CONFIG_X86_32
    > +#define _ASM_DESC_H_ 1
    > +#endif
    > +
    > #ifdef CONFIG_X86_64
    > #define _LINUX_STRING_H_ 1
    > #define __LINUX_BITMAP_H 1
    > @@ -22,6 +26,7 @@
    >
    > #include
    > #include
    > +#include
    > #include
    > #include
    > #include
    > @@ -365,6 +370,56 @@ static void error(char *x)
    > asm("hlt");
    > }
    >
    > +static void parse_elf(void *output)
    > +{
    > +#ifdef CONFIG_X86_64
    > + Elf64_Ehdr ehdr;
    > + Elf64_Phdr *phdrs, *phdr;
    > +#else
    > + Elf32_Ehdr ehdr;
    > + Elf32_Phdr *phdrs, *phdr;
    > +#endif
    > + void *dest;
    > + int i;
    > +
    > + memcpy(&ehdr, output, sizeof(ehdr));
    > + if(ehdr.e_ident[EI_MAG0] != ELFMAG0 ||
    > + ehdr.e_ident[EI_MAG1] != ELFMAG1 ||
    > + ehdr.e_ident[EI_MAG2] != ELFMAG2 ||
    > + ehdr.e_ident[EI_MAG3] != ELFMAG3)
    > + {
    > + error("Kernel is not a valid ELF file");
    > + return;
    > + }
    > +
    > + putstr("Parsing ELF... ");
    > +
    > + phdrs = malloc(sizeof(*phdrs) * ehdr.e_phnum);
    > + if (!phdrs)
    > + error("Failed to allocate space for phdrs");
    > +
    > + memcpy(phdrs, output + ehdr.e_phoff, sizeof(*phdrs) * ehdr.e_phnum);
    > +
    > + for (i=0; i > + phdr = &phdrs[i];
    > +
    > + switch (phdr->p_type) {
    > + case PT_LOAD:
    > +#ifdef CONFIG_RELOCATABLE
    > + dest = output;
    > + dest += (phdr->p_paddr - LOAD_PHYSICAL_ADDR);
    > +#else
    > + dest = (void*)(phdr->p_paddr);
    > +#endif
    > + memcpy(dest,
    > + output + phdr->p_offset,
    > + phdr->p_filesz);
    > + break;


    so will cost every bzImage extra memory copy? that could be 18M or
    even more big.

    wonder if can have one some other kind elf format, and offset load
    address to avoid that mem copy.

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

  14. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.


    On Sun, 2008-04-06 at 00:03 -0700, Yinghai Lu wrote:
    > so will cost every bzImage extra memory copy? that could be 18M or
    > even more big.


    Is it a huge deal for something that happens exactly once on boot? How
    does the time take compare with the time to do the decompression?

    18M seems like an awfully large kernel image to me. My distro (Debian)
    kernel is more like 3M uncompressed. If someone was interested in fast
    booting presumably they would either build a kernel with exactly what
    they need.

    > wonder if can have one some other kind elf format, and offset load
    > address to avoid that mem copy.


    I guess you could reduce the load address by sizeof(headers) and add a
    dest == (output + phdr->p_offset) test before the copy.

    Another possibility, which is much more complex, is that the ELF parsing
    could be integrated into the decompressor such that the data is
    decompressed into the correct location directly.

    Ian.

    --
    Ian Campbell

    People who have no faults are terrible; there is no way of taking
    advantage of them.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBH+KRgM0+0qS9rzVkRAvSqAJ9S4A+gBdV4Q3L81u518o e8UHrCVwCfT4fe
    PWSbeCIcOp8/OABj5DEZaNI=
    =OLlf
    -----END PGP SIGNATURE-----


  15. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    Yinghai Lu wrote:
    > so will cost every bzImage extra memory copy? that could be 18M or
    > even more big.


    I wouldn't worry about that. You will typically have several copies of
    the images during the execution of the boot loader.

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

  16. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    On Sun, Apr 6, 2008 at 9:38 AM, H. Peter Anvin wrote:
    > Yinghai Lu wrote:
    >
    > > so will cost every bzImage extra memory copy? that could be 18M or
    > > even more big.
    > >

    >
    > I wouldn't worry about that. You will typically have several copies of the
    > images during the execution of the boot loader.


    i put all drivers needed in kernel.
    1. bootloader copy bzImage (6M) to memory
    2. arch/x86/boot/compressed/head_32.S, will copy bzImage to end of
    buffer to do uncompress on possiton.
    3. parse_elf will copy the vmlinux (the uncompressed, that is some big, 18M)

    I suggest that could have special elf header, and will only have one
    PT_LOAD, and avoid the copy, and just offset start address of
    uncompressed kernel for jump later.

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

  17. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    On Sun, Apr 6, 2008 at 10:25 AM, H. Peter Anvin wrote:
    >
    > Yinghai Lu wrote:
    >
    > > On Sun, Apr 6, 2008 at 9:38 AM, H. Peter Anvin wrote:
    > >
    > > > Yinghai Lu wrote:
    > > >
    > > >
    > > > > so will cost every bzImage extra memory copy? that could be 18M or
    > > > > even more big.
    > > > >
    > > > >
    > > > I wouldn't worry about that. You will typically have several copies of

    > the
    > > > images during the execution of the boot loader.
    > > >

    > >
    > > i put all drivers needed in kernel.
    > > 1. bootloader copy bzImage (6M) to memory
    > > 2. arch/x86/boot/compressed/head_32.S, will copy bzImage to end of
    > > buffer to do uncompress on possiton.
    > > 3. parse_elf will copy the vmlinux (the uncompressed, that is some big,

    > 18M)
    > >
    > > I suggest that could have special elf header, and will only have one
    > > PT_LOAD, and avoid the copy, and just offset start address of
    > > uncompressed kernel for jump later.
    > >

    >
    > Once again, I think you will have a hard time measuring the time
    > difference.


    ok.

    forget about my proposal..

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

  18. Re: [PATCHv3 1/3] x86: use ELF format in compressed images.

    Yinghai Lu wrote:
    > On Sun, Apr 6, 2008 at 9:38 AM, H. Peter Anvin wrote:
    >> Yinghai Lu wrote:
    >>
    >>> so will cost every bzImage extra memory copy? that could be 18M or
    >>> even more big.
    >>>

    >> I wouldn't worry about that. You will typically have several copies of the
    >> images during the execution of the boot loader.

    >
    > i put all drivers needed in kernel.
    > 1. bootloader copy bzImage (6M) to memory
    > 2. arch/x86/boot/compressed/head_32.S, will copy bzImage to end of
    > buffer to do uncompress on possiton.
    > 3. parse_elf will copy the vmlinux (the uncompressed, that is some big, 18M)
    >
    > I suggest that could have special elf header, and will only have one
    > PT_LOAD, and avoid the copy, and just offset start address of
    > uncompressed kernel for jump later.


    Once again, I think you will have a hard time measuring the time difference.

    The start address of the uncompressed kernel is defined at compile time.
    Typically it is set based on alignment constraints in the hardware;
    for x86-32 is is normally 1 MB but for reasonably large hardware 16 MB
    is better (in fact, I have proposed making 16 MB the default.) Recovery
    kernels are frequently compiled with completely different addresses.

    With your proposal, this would no longer be possible to be a
    configurable option, which would be a major loss -- a major loss of
    functionality for a small fraction of time at bootup time (which is
    almost certainly dwarfed by all the other copying and initialization
    that happens at boot time.)

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

+ Reply to Thread