qemu-devel
[Top][All Lists]
Advanced

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

Re: VW ELF loader


From: Paolo Bonzini
Subject: Re: VW ELF loader
Date: Sat, 1 Feb 2020 20:04:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1

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.

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.

Paolo




reply via email to

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