Re: VW ELF loader

[Paolo Bonzini]

On 03/02/20 11:58, Alexey Kardashevskiy wrote:
>>> So really, the question isn't whether we implement things in firmware
>>> or in qemu.  It's whether we implement the firmware functionality as
>>> guest cpu code, which needs to be coded to work with a limited
>>> environment, built with a special toolchain, then emulated with TCG.
>>> Or, do we just implement it in normal C code, with a full C library,
>>> and existing device and backend abstractions inside qemu.
>>
>> ... which is adding almost 2000 lines of new code to the host despite
>> the following limitations:
>>
>>> 4. no networking in OF CI at all;
>>> 5. no vga;
>>> 6. no disk partitions in CI, i.e. no commas to select a partition -
>>> this relies on a bootloader accessing the disk as a whole;
> 
> This is not going to be a lot really, especially supporting partitions -
> the code is practically there already as I needed it to find GRUB, and
> GRUB does the rest asking very little from the firmware to work.

What partition formats would have to be supported?  But honestly I'm
more worried about the networking part.

> btw what is the common way of netbooting in x86? NIC ROM or GRUB (but
> this would be a disk anyway)? Can we consider having a precompiled GRUB
> image somewhere in pc-bios/ to use for netboot? Or Uboot would do (it is
> already in pc-bios/, no?), I suppose?

GRUB netboot support is almost never used.  There are three cases:

- QEMU BIOS: the NIC ROM contain iPXE, which is both the driver code and
the boot loader (which chains into GRUB).

- Bare metal BIOS: same, but the boot loader is minimal so most of the
time iPXE is loaded via TFTP and reuses the NIC ROM's driver code.

- UEFI: the NIC ROM contains driver code only and the firmware does the
rest.

>> In other words you're not dropping SLOF, you're really dropping
>> OpenFirmware completely.
> 
> What is the exact benefit of having OpenFirmware's "interpret"?

None, besides being able to play space invaders written in Forth.  I'm
not against dropping most OpenFirmware capabilities, I'm against adding
a limited (or broken depending on what you're trying to do) version that
runs in the host.

Yes, SLOF is big and slow.  petitboot is not petit at all either, and
has the disadvantage that you have to find a way to run GRUB afterwards.
 But would a similarly minimal OF implementation (no network, almost no
interpret so no Forth, device tree built entirely in the host, etc.) be
just as big and slow?

Paolo