qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anatol Pomozov <anatol.pomozov@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>,
	Eduardo Habkost <ehabkost@redhat.com>,
	qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] How to make ELF headers/symbol sections available for multiboot?
Date: Mon, 11 Sep 2017 11:48:40 -0700	[thread overview]
Message-ID: <CAOMFOmWWi_dEnneYQo2+d2V=uM0ne00OnYJEzFpyDRes_bvRfQ@mail.gmail.com> (raw)
In-Reply-To: <CAOMFOmWcYxQU7Vf4h+6Q3pxmin5sWH+gNHUFVWGPaMye14Y1ng@mail.gmail.com>

Hello

I have these changes ready now
http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg03265.html
It added ELF parser functionality as discussed above. Are there any
open questions? What is the best way to proceed forward with these
patches?

I also have interest in adding Multiboot2 support to qemu. But before
going with it I would like to finish working on my current patchset.

On Thu, Aug 17, 2017 at 1:54 PM, Anatol Pomozov
<anatol.pomozov@gmail.com> wrote:
> Hi
>
> On Tue, Aug 8, 2017 at 8:04 AM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 04.08.2017 um 06:53 hat Anatol Pomozov geschrieben:
>>> Hi Kevin
>>>
>>> Thanks for the information.
>>>
>>> So I sounds like we do want multiboot to load all sections regardless
>>> of its segments info. To achieve it we need to read sections headers
>>> and load all section that were not loaded yet.
>>>
>>> I have a working implementation here
>>> https://github.com/anatol/qemu/commit/26773cf4f1f30b2d0d3fd89cce024f8e9c5603c5
>>> Tested it with my multiboot OS image. The target iterates over all
>>> sections and prints their names/address. The output result is the same
>>> for QEMU and for VmWare+GRUB.
>>>
>>> Let me know if this idea looks good so I can send this patch to qemu maillist.
>>
>> I'm not sure if I'll find the time to review this in detail, but I'll
>> just give it a quick look.
>>
>> You seem to attempt to add support for 64 bit ELF binaries. The
>> Multiboot standard doesn't explicitly say that this is forbidden, but
>> everything in it expects 32 bit binaries and I don't think GRUB (as the
>> reference implementation for Multiboot) accepts 64 bit ELFs either. The
>> boot state is 32 bit protected mode in any case. So unless I'm mistaken
>> on GRUB's behaviour, I'd rather not support 64 bit ELFs.
>
> Grub actually does support ELF64 loading with multiboot. Here is the
> GRUB code that implements it
> https://github.com/coreos/grub/blob/master/grub-core/loader/multiboot.c#L210
>
> It would be great if QEMU behaved similar way.
>
> Actually I've been using qemu with ELF64 multiboot for a while and it
> works great.
>
>>
>> You shouldn't look at ELF headers at all if MULTIBOOT_AOUT_KLUDGE is
>> given. In this case, the kernel image is to be treated as a flat binary
>> and section headers can't be expected. I think your code breaks non-ELF
>> kernels.
>
> Ok, will revert this part back.
>
>>
>> As for loading the section headers, duplicating ELF parser code may be
>> functionally correct, but probably not the best way to implement things.
>> As I wrote in an earlier email, load_elf() already parses all the
>> information that you need. You really just need to store it somewhere,
>> which would probably just mean adding a new parameter to load_elf() and
>> the parser could then store a copy of the data there if it's non-NULL.
>
> Loading section headers is actually a small part of my change. It also:
>   - calculates memory needed to load all sections into memory
>   - allocates memory
>   - loads sections
>
> This "load all sections into memory" functionality is very multiboot
> specific. But if you think if load_elf() is better place for it then I
> can look at moving it to load_elf().

  reply	other threads:[~2017-09-11 18:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28 21:28 [Qemu-devel] How to make ELF headers/symbol sections available for multiboot? Anatol Pomozov
2017-07-30 21:42 ` Eduardo Habkost
2017-07-31  6:25   ` Alexander Graf
2017-07-31 11:27   ` Kevin Wolf
2017-07-31 17:21   ` Anatol Pomozov
2017-07-31 18:20     ` Richard Henderson
2017-08-02 22:00       ` Anatol Pomozov
2017-08-02 22:45         ` Richard Henderson
2017-08-03  8:39         ` Kevin Wolf
2017-08-04  4:53           ` Anatol Pomozov
2017-08-08 15:04             ` Kevin Wolf
2017-08-17 20:54               ` Anatol Pomozov
2017-09-11 18:48                 ` Anatol Pomozov [this message]
2017-09-11 18:49                 ` Anatol Pomozov
2017-08-01 14:06     ` Kevin Wolf
2017-07-31  8:50 ` Peter Maydell
2017-07-31 13:04   ` Richard Henderson

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='CAOMFOmWWi_dEnneYQo2+d2V=uM0ne00OnYJEzFpyDRes_bvRfQ@mail.gmail.com' \
    --to=anatol.pomozov@gmail.com \
    --cc=agraf@suse.de \
    --cc=ehabkost@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).