From: David Gibson <david@gibson.dropbear.id.au>
To: Utkarsh Verma <uverma@linux.ibm.com>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Stefano Garzarella <sgarzare@redhat.com>,
th.huth@posteo.eu, nnmlinux@linux.ibm.com, sbhat@linux.ibm.com,
harshpb@linux.ibm.com
Subject: Re: VW ELF loader
Date: Mon, 6 Jul 2026 21:46:19 +1000 [thread overview]
Message-ID: <akuViylBcKiXMbjH@zatzit> (raw)
In-Reply-To: <99254c26-0b41-4efc-b1cd-ad1e19576f32@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
On Mon, Jul 06, 2026 at 02:37:48PM +0530, Utkarsh Verma wrote:
> +Thomas, Narayana, Shiva, Harsh - FYI
>
> Hi Alexey, David and Paolo,
> Reviving this thread as would like to add the disk boot support by loading
> GRUB.
Good luck, but I'm afraid I no longer have any interest in, or time to
commit to looking at ppc qemu stuff.
>
> On 2/1/20 7:09 PM, Alexey Kardashevskiy wrote:
> > Hi!
> >
> > In my effort to "kill SLOF" (the PPC pseries guest firmware), I
> > proceeded to the stage when QEMU needs to load GRUB from the disk. The
> > current workaround is to read it from qcow2, save in a file and then
> > call load_elf(). Not nice.
> >
> > 2 problems with that.
> >
> > 1. when load_elf calls address_space_write() - I need to know where and
> > how much RAM was used to mark this memory "used" for the OF client
> > interface (/memory@0/available FDT property). So I'll need "preload()"
> > hook.
> >
> > 2. (bigger) GRUB comes from PReP partition which is 8MB. load_elf{32|64}
> > consumes filename, not a memory pointer nor a "read_fn" callback - so I
> > thought I need a "read_fn" callback.
> >
> > And then I discovered that load_elf actually maps the passed file. And
> > here I got lost.
> >
> > Why does not load_elf just map the entire file and parse the bits? It
> > still reads chunks with seek+read and then it maps the file in a loop
> > potentially multiple times - is this even correct? Passing "fd" around
> > is weird.
> >
> > Why ROMs are different from "-kernel"?
> >
> > If I want to solve 1 and 2 of my problem, should I just cut-n-paste
> > load_elf and tweak bits rather then add more parameters to already
> > 15-parameters long prototypes?
> > Or I could read GRUB from qcow2 into the memory and change the rest to
> > parse ELF from memory (mapped from a ELF file or read from qcow2)?
> To rectify the mentioned issues, would like to implement a custom ELF loader
> for ppc that can load the elf from the buffer and claim the memory for each
> program header segment.
>
> It was attempted earlier in v6 (Patch 6/6) and v7 (Patch 5/5) , but later
> dropped for reasons unknown to me:
> v6:
> https://lore.kernel.org/qemu-devel/20200203032943.121178-1-aik@ozlabs.ru/
> v7: https://lore.kernel.org/qemu-devel/20200220061622.15064-1-aik@ozlabs.ru/
>
> I believe disk boot is a worthwhile addition to VOF. It would make the
> pseries machine type fully usable without SLOF for the most common case:
> booting from a distro qcow2 image with a PReP partition containing GRUB.
>
> >
> >
> >
> > Thanks,
> >
> > ps. VW == very weird, indeed :)
> >
>
> Regards,
> Utkarsh Verma
>
--
David Gibson (he or they) | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you, not the other way
| around.
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-07-06 11:47 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-01 13:39 VW ELF loader Alexey Kardashevskiy
2020-02-01 19:04 ` Paolo Bonzini
2020-02-02 11:51 ` Alexey Kardashevskiy
2020-02-02 17:38 ` Paolo Bonzini
2020-02-03 1:31 ` David Gibson
2020-02-03 1:28 ` David Gibson
2020-02-03 9:12 ` Paolo Bonzini
2020-02-03 9:50 ` David Gibson
2020-02-03 10:58 ` Alexey Kardashevskiy
2020-02-03 15:08 ` Paolo Bonzini
2020-02-03 22:36 ` Alexey Kardashevskiy
2020-02-03 22:56 ` Paolo Bonzini
2020-02-03 23:19 ` Alexey Kardashevskiy
2020-02-03 23:26 ` Paolo Bonzini
2020-02-04 6:16 ` Thomas Huth
2020-02-04 8:54 ` Cornelia Huck
2020-02-04 9:20 ` Restrictions of libnet (was: Re: VW ELF loader) Thomas Huth
2020-02-04 9:32 ` Thomas Huth
2020-02-04 9:33 ` Michal Suchánek
2020-02-05 5:30 ` David Gibson
2020-02-05 6:24 ` Thomas Huth
2020-02-10 7:55 ` David Gibson
2020-02-10 9:39 ` Michal Suchánek
2020-02-13 3:16 ` David Gibson
2020-02-04 23:18 ` VW ELF loader Alexey Kardashevskiy
2020-02-05 6:06 ` David Gibson
2020-02-05 9:28 ` Cornelia Huck
2020-02-06 4:47 ` David Gibson
2020-02-06 8:27 ` Paolo Bonzini
2020-02-06 23:17 ` Alexey Kardashevskiy
2020-02-06 23:45 ` Paolo Bonzini
2020-02-10 7:30 ` David Gibson
2020-02-10 10:37 ` Peter Maydell
2020-02-10 11:25 ` Paolo Bonzini
2020-02-14 3:23 ` David Gibson
2020-02-10 7:28 ` David Gibson
2020-02-10 11:26 ` Paolo Bonzini
2020-02-14 4:02 ` David Gibson
2020-02-05 5:58 ` David Gibson
2020-02-06 8:29 ` Paolo Bonzini
2020-02-06 23:23 ` Alexey Kardashevskiy
2020-02-06 23:46 ` Paolo Bonzini
2020-02-10 0:31 ` Alexey Kardashevskiy
2020-02-13 1:43 ` Alexey Kardashevskiy
2020-02-13 10:17 ` Paolo Bonzini
2020-02-14 0:01 ` Alexey Kardashevskiy
2020-02-14 2:30 ` David Gibson
2020-02-04 9:40 ` Christian Borntraeger
2026-07-06 9:07 ` Utkarsh Verma
2026-07-06 11:46 ` David Gibson [this message]
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=akuViylBcKiXMbjH@zatzit \
--to=david@gibson.dropbear.id.au \
--cc=aik@ozlabs.ru \
--cc=harshpb@linux.ibm.com \
--cc=nnmlinux@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sbhat@linux.ibm.com \
--cc=sgarzare@redhat.com \
--cc=th.huth@posteo.eu \
--cc=uverma@linux.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.