qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [PATCH] turn firmware image filename into a machine option
Date: Wed, 02 Oct 2013 11:18:59 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0

On 10/02/2013 07:23 AM, Benjamin Herrenschmidt wrote:
> 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.


You misunderstood, the intention was to ignore the fact of existing of RTAS
(yet another firmware) and behave as there is only one firmware and we
probably should shut up and let people do changes which will make RTAS
extention or existense mostly impossible :)


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


-- 
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]