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