From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47188)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1VR1DD-0006D8-98
	for qemu-devel@nongnu.org; Tue, 01 Oct 2013 10:46:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1VR1D6-0003xb-01
	for qemu-devel@nongnu.org; Tue, 01 Oct 2013 10:46:07 -0400
Message-ID: <524AE023.4090106@suse.de>
Date: Tue, 01 Oct 2013 16:45:55 +0200
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
References: <1380620399-9907-1-git-send-email-kraxel@redhat.com>
	<CAFEAcA9bkaVsW+6-TMNniw2ECS12cXckU5aokxt=jBQCTgHKMQ@mail.gmail.com>
	<1380626523.5280.27.camel@nilsson.home.kraxel.org>
	<CAFEAcA8xvePFPoxKwdqBFOf4LjfMF4_P68NmuVCGmu3S+qQO9Q@mail.gmail.com>
	<1380629771.5280.40.camel@nilsson.home.kraxel.org>
	<524ABE1A.1090700@suse.de>
	<1380634912.5280.49.camel@nilsson.home.kraxel.org>
	<524AD24C.1020709@suse.de> <524ADAE1.2030802@ozlabs.ru>
	<1380638423.5280.53.camel@nilsson.home.kraxel.org>
In-Reply-To: <1380638423.5280.53.camel@nilsson.home.kraxel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] turn firmware image filename into a
	machine option
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, Mark Langsdorf <mark.langsdorf@calxeda.com>, Alexey Kardashevskiy <aik@ozlabs.ru>, QEMU Developers <qemu-devel@nongnu.org>, Fabien Chouteau <chouteau@adacore.com>, Blue Swirl <blauwirbel@gmail.com>, Michael Walle <michael@walle.cc>, =?UTF-8?B?SGVydsOpIFBvdXNzaW5lYXU=?= <hpoussin@reactos.org>, Paul Brook <paul@codesourcery.com>, Anthony Liguori <anthony@codemonkey.ws>, qemu-ppc <qemu-ppc@nongnu.org>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>, Aurelien Jarno <aurelien@aurel32.net>, Richard Henderson <rth@twiddle.net>

On 10/01/2013 04:40 PM, Gerd Hoffmann wrote:
>    Hi,
>
>> 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.
> So pretty much like seabios on x86.
>
>> 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 - 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.
> How that does get loaded?  Is it there at machine init?  Or does SLOF
> load RTAS from somewhere?

It gets loaded to a fixed address similar to the device tree. But 
there's no reason that couldn't be changed to on demand loading or even 
an integrated RTAS blob inside of SLOF.


Alex