Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2018-01-29 Thread Anatol Pomozov
Hi

On Mon, Jan 15, 2018 at 7:41 AM, Kevin Wolf  wrote:
> Am 13.10.2017 um 01:54 hat Anatol Pomozov geschrieben:
>> Multiboot may load section headers and all sections (even those that are
>> not part of any segment) to target memory.
>>
>> Tested with an ELF application that uses data from strings table
>> section.
>>
>> Signed-off-by: Anatol Pomozov 
>> ---
>>  hw/core/loader.c |   8 +--
>>  hw/i386/multiboot.c  |  83 +---
>>  hw/s390x/ipl.c   |   2 +-
>>  include/hw/elf_ops.h | 107 
>> ++-
>>  include/hw/loader.h  |  11 +++-
>>  tests/multiboot/Makefile |   8 ++-
>>  tests/multiboot/generate_sections_out.py |  33 ++
>>  tests/multiboot/modules.out  |  22 +++
>>  tests/multiboot/run_test.sh  |   6 +-
>>  tests/multiboot/sections.c   |  55 
>>  tests/multiboot/start.S  |   2 +-
>>  11 files changed, 276 insertions(+), 61 deletions(-)
>>  create mode 100755 tests/multiboot/generate_sections_out.py
>>  create mode 100644 tests/multiboot/sections.c
>>
>> diff --git a/hw/core/loader.c b/hw/core/loader.c
>> index 4593061445..a8787f7685 100644
>> --- a/hw/core/loader.c
>> +++ b/hw/core/loader.c
>> @@ -439,7 +439,7 @@ int load_elf_as(const char *filename,
>>  {
>>  return load_elf_ram(filename, translate_fn, translate_opaque,
>>  pentry, lowaddr, highaddr, big_endian, elf_machine,
>> -clear_lsb, data_swab, as, true);
>> +clear_lsb, data_swab, as, true, NULL);
>>  }
>>
>>  /* return < 0 if error, otherwise the number of bytes loaded in memory */
>> @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename,
>>   void *translate_opaque, uint64_t *pentry, uint64_t 
>> *lowaddr,
>>   uint64_t *highaddr, int big_endian, int elf_machine,
>>   int clear_lsb, int data_swab, AddressSpace *as,
>> - bool load_rom)
>> + bool load_rom, SectionsData *sections)
>>  {
>>  int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED;
>>  uint8_t e_ident[EI_NIDENT];
>> @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename,
>>  if (e_ident[EI_CLASS] == ELFCLASS64) {
>>  ret = load_elf64(filename, fd, translate_fn, translate_opaque, 
>> must_swab,
>>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
>> - data_swab, as, load_rom);
>> + data_swab, as, load_rom, sections);
>>  } else {
>>  ret = load_elf32(filename, fd, translate_fn, translate_opaque, 
>> must_swab,
>>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
>> - data_swab, as, load_rom);
>> + data_swab, as, load_rom, sections);
>>  }
>>
>>   fail:
>> diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
>> index 7dacd6d827..841d05160a 100644
>> --- a/hw/i386/multiboot.c
>> +++ b/hw/i386/multiboot.c
>> @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>>  {
>>  int i;
>>  bool is_multiboot = false;
>> -uint32_t flags = 0;
>> +uint32_t flags = 0, bootinfo_flags = 0;
>>  uint32_t mh_entry_addr;
>>  uint32_t mh_load_addr;
>>  uint32_t mb_kernel_size;
>> @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>>  uint8_t *mb_bootinfo_data;
>>  uint32_t cmdline_len;
>>  struct multiboot_header *multiboot_header;
>> +SectionsData sections;
>>
>>  /* Ok, let's see if it is a multiboot image.
>> The header is 12x32bit long, so the latest entry may be 8192 - 48. */
>> @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg,
>>  if (flags & MULTIBOOT_VIDEO_MODE) {
>>  fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
>>  }
>> -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) {
>> -uint64_t elf_entry;
>> -uint64_t elf_low, elf_high;
>> -int kernel_size;
>> -fclose(f);
>>
>> -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
>> -fprintf(stderr, "Cannot load x86-64 image, give a 32bit 
>> one.\n");
>> -exit(1);
>> -}
>
> I'm not sure why you're reversing the condition and moving this branch
> down, but in the code movements the EM_X86_64 check got lost. Please
> keep it, we don't support 64 bit ELFs at the moment. If you want to
> change this, it should be a separate patch.

Ok I moved it to a separate patch.

>
>> -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry,
>> -   _low, _high, 0, EM_NONE,
>> -   0, 0);
>> -if (kernel_size < 0) {
>> -fprintf(stderr, "Error while loading elf 

Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2018-01-15 Thread Kevin Wolf
Am 13.10.2017 um 01:54 hat Anatol Pomozov geschrieben:
> Multiboot may load section headers and all sections (even those that are
> not part of any segment) to target memory.
> 
> Tested with an ELF application that uses data from strings table
> section.
> 
> Signed-off-by: Anatol Pomozov 
> ---
>  hw/core/loader.c |   8 +--
>  hw/i386/multiboot.c  |  83 +---
>  hw/s390x/ipl.c   |   2 +-
>  include/hw/elf_ops.h | 107 
> ++-
>  include/hw/loader.h  |  11 +++-
>  tests/multiboot/Makefile |   8 ++-
>  tests/multiboot/generate_sections_out.py |  33 ++
>  tests/multiboot/modules.out  |  22 +++
>  tests/multiboot/run_test.sh  |   6 +-
>  tests/multiboot/sections.c   |  55 
>  tests/multiboot/start.S  |   2 +-
>  11 files changed, 276 insertions(+), 61 deletions(-)
>  create mode 100755 tests/multiboot/generate_sections_out.py
>  create mode 100644 tests/multiboot/sections.c
> 
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index 4593061445..a8787f7685 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -439,7 +439,7 @@ int load_elf_as(const char *filename,
>  {
>  return load_elf_ram(filename, translate_fn, translate_opaque,
>  pentry, lowaddr, highaddr, big_endian, elf_machine,
> -clear_lsb, data_swab, as, true);
> +clear_lsb, data_swab, as, true, NULL);
>  }
>  
>  /* return < 0 if error, otherwise the number of bytes loaded in memory */
> @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename,
>   void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr,
>   uint64_t *highaddr, int big_endian, int elf_machine,
>   int clear_lsb, int data_swab, AddressSpace *as,
> - bool load_rom)
> + bool load_rom, SectionsData *sections)
>  {
>  int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED;
>  uint8_t e_ident[EI_NIDENT];
> @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename,
>  if (e_ident[EI_CLASS] == ELFCLASS64) {
>  ret = load_elf64(filename, fd, translate_fn, translate_opaque, 
> must_swab,
>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
> - data_swab, as, load_rom);
> + data_swab, as, load_rom, sections);
>  } else {
>  ret = load_elf32(filename, fd, translate_fn, translate_opaque, 
> must_swab,
>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
> - data_swab, as, load_rom);
> + data_swab, as, load_rom, sections);
>  }
>  
>   fail:
> diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
> index 7dacd6d827..841d05160a 100644
> --- a/hw/i386/multiboot.c
> +++ b/hw/i386/multiboot.c
> @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>  {
>  int i;
>  bool is_multiboot = false;
> -uint32_t flags = 0;
> +uint32_t flags = 0, bootinfo_flags = 0;
>  uint32_t mh_entry_addr;
>  uint32_t mh_load_addr;
>  uint32_t mb_kernel_size;
> @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>  uint8_t *mb_bootinfo_data;
>  uint32_t cmdline_len;
>  struct multiboot_header *multiboot_header;
> +SectionsData sections;
>  
>  /* Ok, let's see if it is a multiboot image.
> The header is 12x32bit long, so the latest entry may be 8192 - 48. */
> @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg,
>  if (flags & MULTIBOOT_VIDEO_MODE) {
>  fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
>  }
> -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) {
> -uint64_t elf_entry;
> -uint64_t elf_low, elf_high;
> -int kernel_size;
> -fclose(f);
>  
> -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
> -fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
> -exit(1);
> -}

I'm not sure why you're reversing the condition and moving this branch
down, but in the code movements the EM_X86_64 check got lost. Please
keep it, we don't support 64 bit ELFs at the moment. If you want to
change this, it should be a separate patch.

> -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry,
> -   _low, _high, 0, EM_NONE,
> -   0, 0);
> -if (kernel_size < 0) {
> -fprintf(stderr, "Error while loading elf kernel\n");
> -exit(1);
> -}
> -mh_load_addr = elf_low;
> -mb_kernel_size = elf_high - elf_low;
> -mh_entry_addr = elf_entry;
> -
> -mbs.mb_buf = g_malloc(mb_kernel_size);
> 

Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-11-20 Thread Kevin Wolf
Am 17.11.2017 um 22:33 hat Anatol Pomozov geschrieben:
> On Tue, Oct 31, 2017 at 11:38 AM, Anatol Pomozov
>  wrote:
> > Hi
> >
> > On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolf  wrote:
> >> Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben:
> >>> Hello qemu-devs,
> >>>
> >>> This patchset has been posted a while ago. I would like to move
> >>> forward with it and look at the next task (e.g. multiboot2 support in
> >>> QEMU). Who is the multiboot code maintainer who can help to review
> >>> this patchset and give go/no-go answer?
> >>
> >> I think that's exactly your problem, there is nobody who feels
> >> responsible for Multiboot support. Officially, it is part of the PC/x86
> >> subsystems:
> >
> > In this case I would like to become the official Qemu/Multiboot
> > maintainer. I do development related to x86 osdev and actively use
> > qemu for my projects. I am interested in having a feature-rich and
> > robust Multiboot implementation.
> 
> It is very unfortunate to see lack of interest in improving
> qemu/multiboot functionality. I guess my best option for now is to
> avoid using qemu multiboot implementation and use grub instead.

Let's wait until 2.11 is out and we're out of freeze, and then I think
your best bet is to just prepare a pull request that adds you to
MAINTAINERS and applies the patches you created so far.

Peter, does this sound right?

Kevin



Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-11-17 Thread Anatol Pomozov
Hello

On Tue, Oct 31, 2017 at 11:38 AM, Anatol Pomozov
 wrote:
> Hi
>
> On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolf  wrote:
>> Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben:
>>> Hello qemu-devs,
>>>
>>> This patchset has been posted a while ago. I would like to move
>>> forward with it and look at the next task (e.g. multiboot2 support in
>>> QEMU). Who is the multiboot code maintainer who can help to review
>>> this patchset and give go/no-go answer?
>>
>> I think that's exactly your problem, there is nobody who feels
>> responsible for Multiboot support. Officially, it is part of the PC/x86
>> subsystems:
>
> In this case I would like to become the official Qemu/Multiboot
> maintainer. I do development related to x86 osdev and actively use
> qemu for my projects. I am interested in having a feature-rich and
> robust Multiboot implementation.

It is very unfortunate to see lack of interest in improving
qemu/multiboot functionality. I guess my best option for now is to
avoid using qemu multiboot implementation and use grub instead.



Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-10-31 Thread Anatol Pomozov
Hi

On Thu, Oct 19, 2017 at 2:36 AM, Kevin Wolf  wrote:
> Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben:
>> Hello qemu-devs,
>>
>> This patchset has been posted a while ago. I would like to move
>> forward with it and look at the next task (e.g. multiboot2 support in
>> QEMU). Who is the multiboot code maintainer who can help to review
>> this patchset and give go/no-go answer?
>
> I think that's exactly your problem, there is nobody who feels
> responsible for Multiboot support. Officially, it is part of the PC/x86
> subsystems:

In this case I would like to become the official Qemu/Multiboot
maintainer. I do development related to x86 osdev and actively use
qemu for my projects. I am interested in having a feature-rich and
robust Multiboot implementation. In mid term I see several tasks for
me:
 - finish and merge my cleanup + MULTIBOOT_INFO_ELF_SHDR patch series
 - add Multiboot2 support
 - (optional) look at MIPS support for Multiboot. I do not have/use
MIPS but it is beneficial to add multiplatform support to Multiboot
 - reviewing incoming patches


A bit about me. My name is Anatol Pomozov and at my spare time I
participate at several open sources projects. I am an Arch developer
since 2013 where I maintain a bunch of packages (including Arch qemu
package [1]). I have ~40 patches in the Linux kernel tree, where the
biggest contribution is a driver for audio codec NAU8825. I
contributed a lot of small patches to numerous projects (compilers,
toolchains, ...)

[1] https://www.archlinux.org/packages/extra/i686/qemu/



Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-10-19 Thread Kevin Wolf
Am 18.10.2017 um 19:22 hat Anatol Pomozov geschrieben:
> Hello qemu-devs,
> 
> This patchset has been posted a while ago. I would like to move
> forward with it and look at the next task (e.g. multiboot2 support in
> QEMU). Who is the multiboot code maintainer who can help to review
> this patchset and give go/no-go answer?

I think that's exactly your problem, there is nobody who feels
responsible for Multiboot support. Officially, it is part of the PC/x86
subsystems:

$ scripts/get_maintainer.pl -f hw/i386/multiboot.c
"Michael S. Tsirkin"  (supporter:PC)
Paolo Bonzini  (maintainer:X86)
Richard Henderson  (maintainer:X86)
Eduardo Habkost  (maintainer:X86)
qemu-devel@nongnu.org (open list:All patches CC here)

I'm not sure if any of them know much about Multiboot. Myself, I am
personally interested in having Multiboot support, which is why I've
even commented on your patches, but I'm not the maintainer.

The last few Multiboot patches seem to have been merged by Paolo.

Kevin



Re: [Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-10-18 Thread Anatol Pomozov
Hello qemu-devs,

This patchset has been posted a while ago. I would like to move
forward with it and look at the next task (e.g. multiboot2 support in
QEMU). Who is the multiboot code maintainer who can help to review
this patchset and give go/no-go answer?

On Thu, Oct 12, 2017 at 4:54 PM, Anatol Pomozov
 wrote:
> Multiboot may load section headers and all sections (even those that are
> not part of any segment) to target memory.
>
> Tested with an ELF application that uses data from strings table
> section.
>
> Signed-off-by: Anatol Pomozov 
> ---
>  hw/core/loader.c |   8 +--
>  hw/i386/multiboot.c  |  83 +---
>  hw/s390x/ipl.c   |   2 +-
>  include/hw/elf_ops.h | 107 
> ++-
>  include/hw/loader.h  |  11 +++-
>  tests/multiboot/Makefile |   8 ++-
>  tests/multiboot/generate_sections_out.py |  33 ++
>  tests/multiboot/modules.out  |  22 +++
>  tests/multiboot/run_test.sh  |   6 +-
>  tests/multiboot/sections.c   |  55 
>  tests/multiboot/start.S  |   2 +-
>  11 files changed, 276 insertions(+), 61 deletions(-)
>  create mode 100755 tests/multiboot/generate_sections_out.py
>  create mode 100644 tests/multiboot/sections.c
>
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index 4593061445..a8787f7685 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -439,7 +439,7 @@ int load_elf_as(const char *filename,
>  {
>  return load_elf_ram(filename, translate_fn, translate_opaque,
>  pentry, lowaddr, highaddr, big_endian, elf_machine,
> -clear_lsb, data_swab, as, true);
> +clear_lsb, data_swab, as, true, NULL);
>  }
>
>  /* return < 0 if error, otherwise the number of bytes loaded in memory */
> @@ -448,7 +448,7 @@ int load_elf_ram(const char *filename,
>   void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr,
>   uint64_t *highaddr, int big_endian, int elf_machine,
>   int clear_lsb, int data_swab, AddressSpace *as,
> - bool load_rom)
> + bool load_rom, SectionsData *sections)
>  {
>  int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED;
>  uint8_t e_ident[EI_NIDENT];
> @@ -488,11 +488,11 @@ int load_elf_ram(const char *filename,
>  if (e_ident[EI_CLASS] == ELFCLASS64) {
>  ret = load_elf64(filename, fd, translate_fn, translate_opaque, 
> must_swab,
>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
> - data_swab, as, load_rom);
> + data_swab, as, load_rom, sections);
>  } else {
>  ret = load_elf32(filename, fd, translate_fn, translate_opaque, 
> must_swab,
>   pentry, lowaddr, highaddr, elf_machine, clear_lsb,
> - data_swab, as, load_rom);
> + data_swab, as, load_rom, sections);
>  }
>
>   fail:
> diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
> index 7dacd6d827..841d05160a 100644
> --- a/hw/i386/multiboot.c
> +++ b/hw/i386/multiboot.c
> @@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>  {
>  int i;
>  bool is_multiboot = false;
> -uint32_t flags = 0;
> +uint32_t flags = 0, bootinfo_flags = 0;
>  uint32_t mh_entry_addr;
>  uint32_t mh_load_addr;
>  uint32_t mb_kernel_size;
> @@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg,
>  uint8_t *mb_bootinfo_data;
>  uint32_t cmdline_len;
>  struct multiboot_header *multiboot_header;
> +SectionsData sections;
>
>  /* Ok, let's see if it is a multiboot image.
> The header is 12x32bit long, so the latest entry may be 8192 - 48. */
> @@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg,
>  if (flags & MULTIBOOT_VIDEO_MODE) {
>  fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
>  }
> -if (!(flags & MULTIBOOT_AOUT_KLUDGE)) {
> -uint64_t elf_entry;
> -uint64_t elf_low, elf_high;
> -int kernel_size;
> -fclose(f);
>
> -if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
> -fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
> -exit(1);
> -}
> -
> -kernel_size = load_elf(kernel_filename, NULL, NULL, _entry,
> -   _low, _high, 0, EM_NONE,
> -   0, 0);
> -if (kernel_size < 0) {
> -fprintf(stderr, "Error while loading elf kernel\n");
> -exit(1);
> -}
> -mh_load_addr = elf_low;
> -mb_kernel_size = elf_high - elf_low;
> -mh_entry_addr = elf_entry;
> -
> -mbs.mb_buf = 

[Qemu-devel] [PATCH 3/4] multiboot: load elf sections and section headers

2017-10-12 Thread Anatol Pomozov
Multiboot may load section headers and all sections (even those that are
not part of any segment) to target memory.

Tested with an ELF application that uses data from strings table
section.

Signed-off-by: Anatol Pomozov 
---
 hw/core/loader.c |   8 +--
 hw/i386/multiboot.c  |  83 +---
 hw/s390x/ipl.c   |   2 +-
 include/hw/elf_ops.h | 107 ++-
 include/hw/loader.h  |  11 +++-
 tests/multiboot/Makefile |   8 ++-
 tests/multiboot/generate_sections_out.py |  33 ++
 tests/multiboot/modules.out  |  22 +++
 tests/multiboot/run_test.sh  |   6 +-
 tests/multiboot/sections.c   |  55 
 tests/multiboot/start.S  |   2 +-
 11 files changed, 276 insertions(+), 61 deletions(-)
 create mode 100755 tests/multiboot/generate_sections_out.py
 create mode 100644 tests/multiboot/sections.c

diff --git a/hw/core/loader.c b/hw/core/loader.c
index 4593061445..a8787f7685 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -439,7 +439,7 @@ int load_elf_as(const char *filename,
 {
 return load_elf_ram(filename, translate_fn, translate_opaque,
 pentry, lowaddr, highaddr, big_endian, elf_machine,
-clear_lsb, data_swab, as, true);
+clear_lsb, data_swab, as, true, NULL);
 }
 
 /* return < 0 if error, otherwise the number of bytes loaded in memory */
@@ -448,7 +448,7 @@ int load_elf_ram(const char *filename,
  void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr,
  uint64_t *highaddr, int big_endian, int elf_machine,
  int clear_lsb, int data_swab, AddressSpace *as,
- bool load_rom)
+ bool load_rom, SectionsData *sections)
 {
 int fd, data_order, target_data_order, must_swab, ret = ELF_LOAD_FAILED;
 uint8_t e_ident[EI_NIDENT];
@@ -488,11 +488,11 @@ int load_elf_ram(const char *filename,
 if (e_ident[EI_CLASS] == ELFCLASS64) {
 ret = load_elf64(filename, fd, translate_fn, translate_opaque, 
must_swab,
  pentry, lowaddr, highaddr, elf_machine, clear_lsb,
- data_swab, as, load_rom);
+ data_swab, as, load_rom, sections);
 } else {
 ret = load_elf32(filename, fd, translate_fn, translate_opaque, 
must_swab,
  pentry, lowaddr, highaddr, elf_machine, clear_lsb,
- data_swab, as, load_rom);
+ data_swab, as, load_rom, sections);
 }
 
  fail:
diff --git a/hw/i386/multiboot.c b/hw/i386/multiboot.c
index 7dacd6d827..841d05160a 100644
--- a/hw/i386/multiboot.c
+++ b/hw/i386/multiboot.c
@@ -125,7 +125,7 @@ int load_multiboot(FWCfgState *fw_cfg,
 {
 int i;
 bool is_multiboot = false;
-uint32_t flags = 0;
+uint32_t flags = 0, bootinfo_flags = 0;
 uint32_t mh_entry_addr;
 uint32_t mh_load_addr;
 uint32_t mb_kernel_size;
@@ -134,6 +134,7 @@ int load_multiboot(FWCfgState *fw_cfg,
 uint8_t *mb_bootinfo_data;
 uint32_t cmdline_len;
 struct multiboot_header *multiboot_header;
+SectionsData sections;
 
 /* Ok, let's see if it is a multiboot image.
The header is 12x32bit long, so the latest entry may be 8192 - 48. */
@@ -161,37 +162,8 @@ int load_multiboot(FWCfgState *fw_cfg,
 if (flags & MULTIBOOT_VIDEO_MODE) {
 fprintf(stderr, "qemu: multiboot knows VBE. we don't.\n");
 }
-if (!(flags & MULTIBOOT_AOUT_KLUDGE)) {
-uint64_t elf_entry;
-uint64_t elf_low, elf_high;
-int kernel_size;
-fclose(f);
 
-if (((struct elf64_hdr*)header)->e_machine == EM_X86_64) {
-fprintf(stderr, "Cannot load x86-64 image, give a 32bit one.\n");
-exit(1);
-}
-
-kernel_size = load_elf(kernel_filename, NULL, NULL, _entry,
-   _low, _high, 0, EM_NONE,
-   0, 0);
-if (kernel_size < 0) {
-fprintf(stderr, "Error while loading elf kernel\n");
-exit(1);
-}
-mh_load_addr = elf_low;
-mb_kernel_size = elf_high - elf_low;
-mh_entry_addr = elf_entry;
-
-mbs.mb_buf = g_malloc(mb_kernel_size);
-if (rom_copy(mbs.mb_buf, mh_load_addr, mb_kernel_size) != 
mb_kernel_size) {
-fprintf(stderr, "Error while fetching elf kernel from rom\n");
-exit(1);
-}
-
-mb_debug("qemu: loading multiboot-elf kernel (%#x bytes) with entry 
%#zx\n",
-  mb_kernel_size, (size_t)mh_entry_addr);
-} else {
+if (flags & MULTIBOOT_AOUT_KLUDGE) {
 /* Valid if mh_flags sets MULTIBOOT_AOUT_KLUDGE. */
 uint32_t mh_header_addr = ldl_p(_header->header_addr);