qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Mark Langsdorf" <mark.langsdorf@calxeda.com>,
	"Paul Brook" <paul@codesourcery.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Fabien Chouteau" <chouteau@adacore.com>,
	"Alexander Graf" <agraf@suse.de>,
	"Blue Swirl" <blauwirbel@gmail.com>,
	"Michael Walle" <michael@walle.cc>,
	"Hervé Poussineau" <hpoussin@reactos.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Anthony Liguori" <anthony@codemonkey.ws>,
	qemu-ppc <qemu-ppc@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Aurelien Jarno" <aurelien@aurel32.net>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH] turn firmware image filename into a machine option
Date: Wed, 02 Oct 2013 11:18:59 +1000	[thread overview]
Message-ID: <524B7483.1070501@ozlabs.ru> (raw)
In-Reply-To: <1380662605.645.32.camel@pasglop>

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	other threads:[~2013-10-02  1:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-01  9:39 [Qemu-devel] [PATCH] turn firmware image filename into a machine option Gerd Hoffmann
2013-10-01 10:55 ` Peter Maydell
2013-10-01 11:22   ` Gerd Hoffmann
2013-10-01 11:32     ` Peter Maydell
2013-10-01 12:16       ` Gerd Hoffmann
2013-10-01 12:20         ` Andreas Färber
2013-10-01 13:41           ` Gerd Hoffmann
2013-10-01 13:46             ` Andreas Färber
2013-10-01 14:23               ` Alexey Kardashevskiy
2013-10-01 14:40                 ` Gerd Hoffmann
2013-10-01 14:45                   ` Alexander Graf
2013-10-01 21:23                 ` Benjamin Herrenschmidt
2013-10-02  1:18                   ` Alexey Kardashevskiy [this message]
2013-10-01 13:00         ` Peter Maydell
2013-10-01 14:57           ` Paolo Bonzini
2013-10-01 15:05           ` Gerd Hoffmann
2013-10-01 15:12             ` Peter Maydell
2013-10-01 15:28               ` Paolo Bonzini
2013-10-01 15:42                 ` Anthony Liguori
     [not found] ` <524AB29F.3030906@suse.de>
2013-10-01 13:32   ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=524B7483.1070501@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=aurelien@aurel32.net \
    --cc=benh@kernel.crashing.org \
    --cc=blauwirbel@gmail.com \
    --cc=chouteau@adacore.com \
    --cc=hpoussin@reactos.org \
    --cc=kraxel@redhat.com \
    --cc=mark.langsdorf@calxeda.com \
    --cc=michael@walle.cc \
    --cc=paul@codesourcery.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).