All of lore.kernel.org
 help / color / mirror / Atom feed
From: Utkarsh Verma <uverma@linux.ibm.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>,
	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 14:37:48 +0530	[thread overview]
Message-ID: <99254c26-0b41-4efc-b1cd-ad1e19576f32@linux.ibm.com> (raw)
In-Reply-To: <f881c2e7-be92-9695-6e19-2dd88cbc63c1@ozlabs.ru>

+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.

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



  parent reply	other threads:[~2026-07-06 12:53 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 [this message]
2026-07-06 11:46   ` David Gibson

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=99254c26-0b41-4efc-b1cd-ad1e19576f32@linux.ibm.com \
    --to=uverma@linux.ibm.com \
    --cc=aik@ozlabs.ru \
    --cc=david@gibson.dropbear.id.au \
    --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 \
    /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.