Re: VW ELF loader

[Alexey Kardashevskiy]

On 02/02/2020 06:04, Paolo Bonzini wrote:
> On 01/02/20 14:39, Alexey Kardashevskiy wrote:
> > 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.
>
> QEMU must not load GRUB from disk, that's the firmware's task.  If you
> want to kill SLOF, you can rewrite it, but loading the kernel GRUB from
> disk within QEMU is a bad idea: the next feature you'll be requested to
> implement will be network boot, and there's no way to do that in QEMU.

What is exactly the problem with netboot? I can hook up the OF's "net" to a backend (as I do for serial console and 
blockdev, in boot order) and GRUB will do the rest which is tftp/dhcp/ip (SLOF does just this and nothing more). If GRUB 
does not do this on POWER - I can fix this.

Or alternatively it is possible with my patchset to load petitboot (kernel + intramdisk, the default way of booting 
POWER8/9 baremetal systems) and that thing can do whole lot of things, we can consider it as a replacement for ROMs from 
devices (or I misunderstood what kind of netboot you meant).

> You should be able to reuse quite a lot of code from both
> pc-bios/s390-ccw (for virtio drivers) and kvm-unit-tests (for device
> tree parsing).  You'd have to write the glue code for PCI hypercalls,
> and adapt virtio.c for virtio-pci instead of virtio-ccw.

The reason for killing SLOF is to keep one device tree for the entire boot process including 
ibm,client-architecture-support with possible (and annoying) configuration reboots. Having another firware won't help 
with that.

Also the OF1275 client interface is the way for the client to get net/block device without need to have drivers, I'd 
like to do just this and skip the middle man (QEMU device and guest driver in firmware/bootloader).

I'll post another RFC tomorrow to give a better idea.


--
Alexey