Re: [Qemu-devel] [PATCH] turn firmware image filename into a machine option

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2013-10-02 at 00:23 +1000, Alexey Kardashevskiy wrote:

> SLOF is what is loaded from the very beginning, it configures PCI, cooks
> the device tree and boots the guest system (directly or via yaboot/grub,
> from disk, network or ram). Normal firmware, as usual. It knows all the
> details about the machine so the guest system (linux) does not need to know
> details about PCI host bus adapter or anything like this.
> 
> RTAS is an agent which always lives in RAM when the guest system (linux,
> aix) is up and running.

> It is a light-weight version of SLOF which is left
> in RAM by SLOF and can do board/machine specific tasks such as PCI config
> space access or PCI hotplug

Not exactly ... on traditional IBM firmware, RTAS is some kind of
spin-off of OFW that remains functional at runtime. On jx2x SLOF, it's a
piece of C/asm that operates as standalone code within the context of
the OS. Under qemu, however, RTAS is provided by qemu and is just a 5
instruction trampoline around a hypercall, the actual RTAS functions are
provided by qemu.

As such, we *could* get rid of the RTAS blob from qemu and just put
knowledge about that 5 instructions trampoline in SLOF itself with the
ability to instanciate it.

>  - something what SLOF already knows about and
> something what the guest does not want to know about in details. This came
> from IBM pHyp (traditional server PPC64 hypervisor) and it is quite a big
> firmware. In the case of KVM, it is very small stub which simply passes
> requests to QEMU which does the rest. But it is still a separate binary
> image even in the current QEMU.
> 
> May be some day it will become bigger as from time to time the community
> wants things to be done in a certain way which would mean extending rtas,
> however we (powerpc-server folks) want to hope it won't happen ever :)

Creating a full fledged RTAS is a massive non-sense. I don't understand
what's going on with the qemu community and why people don't seem to
understand what a trainwreck it is to create more layers of undebuggable
firmware blobs and extra project dependencies...

Having that stuff in qemu (and partially in the kernel even) makes
things a lot easier to maintain and debug.

Ben.
 
> Adding Ben in copy, he might have something to add.
> 
>