Re: VW ELF loader

[David Gibson]

On Mon, Feb 03, 2020 at 04:08:54PM +0100, 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?  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.

Well, not usually.  Petitboot parses grub configuration itself, which
means that generally from the OS / installer point of view it looks
like grub, even though it's not from the actual bootstrapping point of
view.

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

So, as actual OF implementations go, SLOF is already pretty minimal
(hence "Slim Line Open Firmware").  If there's no Forth, it's really
not OF any more, just something mimicing some of OF's interfaces.

But the difficulty of SLOF isn't really its bigness or slowness in any
case (the slowness is just an additional irritation).  The two big
issues are 1) that it's written in an obscure language and 2)
synchronizing its state with things that require host side
involvement.

Rewriting a minimal guest side not-OF would partly address (1) (but
there's still the logistical pain of having to build and insert it),
and wouldn't address (2) at all.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

signature.asc
Description: PGP signature