Re: VW ELF loader

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 04/02/2020 02:08, Paolo Bonzini wrote:
> 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? 

MBR, GPT, is there anything else? "Support" is limited to converting a
number after command to [start, size] couple. I am not going for file
systems.

> But honestly I'm
> more worried about the networking part.

Fair enough.

>> 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. 

Huh. We use yaboot here in Ozlabs for netbooting quite a lot.

> 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.

Well, we never really had this luxury of NIC ROM, there were a couple of
NICs with fcode which never really worked in SLOF.

Oh well, this is probably the time to look into netbooting then.


>>> 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.)

The device tree is almost completely built in QEMU these days anyway,
twice during normal boot.

> be just as big and slow?

I doubt. We will be getting rid of unnecessary drivers, bus scanning
code (SCSI, PCI), device tree synchronization.


-- 
Alexey