[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VW ELF loader

From: Alexey Kardashevskiy
Subject: Re: VW ELF loader
Date: Sun, 2 Feb 2020 22:51:27 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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()"

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]