Re: VW ELF loader

[Christian Borntraeger]

On 01.02.20 20: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.
> 
> 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.

Yes, we had disk format parsing at the beginning in QEMU and Alex Graf insisted
on using a BIOS code - even if s390 has no bios inside the guest context.
So we put this somewhere at the end of the guest and it seems that it does not
collide with Linux guests. 
In the end we have boot from all kind of disks and network boot. 

Thomas can maybe tell better if this works out good or bad.