Re: VW ELF loader

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

On Mon, Feb 03, 2020 at 10:12:02AM +0100, Paolo Bonzini wrote:
> On 03/02/20 02:28, David Gibson wrote:
> > But "pseries" is different.  We're implementing the PAPR platform,
> > which describes an OS environment that's presented by a combination of
> > a hypervisor and firmware.  The features it specifies *require*
> > collaboration between the firmware and the hypervisor.
> 
> Which features are these?

Too many to list really.  In the whole of PAPR, there are probably
dozens of RTAS calls that require hypervisor privilege at some point
along the way.  We probably don't implement that many of them -
there's a bunch of stuff we've never bothered with because Linux
doesn't care.

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

Well.. yeah.. it is kinda larger than I hoped.

But in comparison *just* the qemu specific parts of SLOF are >4000
lines of Forth.  Overall there's about 20k lines of Forth and 33k
lines of C.  And the number of people who both understand Forth and
have the slightest interest in SLOF is, like.. 2 people?  Maybe 3 if
you count Segher's occasional drive-by rants.

> > 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;
> 
> and of course:
> 
> > 7. "interpret" (executes passed forth expression) does nothing as in this
> > environment grub only uses it for switching cursor off and similar tasks.
> 
> In other words you're not dropping SLOF, you're really dropping
> OpenFirmware completely.

No argument there.  That is absolutely true, and absolutely
intentional.  The idea is to maintain just what we need of the
OS-facing OF interface.

Frankly, while it has some good ideas, I don't think Open Firmware
wasn't that great a concept overall in the 90s[0] - and it has not really
improved with age.

[0] Incidentally I also think EFI's a pretty crappy concept for almost
    exactly the same reasons, but it has the huge advantage of a much
    more actively developed codebase.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]