[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSe

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 27/27] Add SLOF-based partition firmware for pSeries machine, allowing more boot options
Date: Mon, 28 Mar 2011 11:03:23 +0200

On 28.03.2011, at 03:19, David Gibson wrote:

> On Fri, Mar 25, 2011 at 01:29:17PM -0500, Anthony Liguori wrote:
>> On 03/24/2011 10:21 PM, David Gibson wrote:
>>> Currently, the emulated pSeries machine requires the use of the
>>> -kernel parameter in order to explicitly load a guest kernel.  This
>>> means booting from the virtual disk, cdrom or network is not possible.
>>> This patch addresses this limitation by inserting a within-partition
>>> firmware image (derived from the "SLOF" free Open Firmware project).
>>> If -kernel is not specified, qemu will now load the SLOF image, which
>>> has access to the qemu boot device list through the device tree, and
>>> can boot from any of the usual virtual devices.
>>> In order to support the new firmware, an extension to the emulated
>>> machine/hypervisor is necessary.  Unlike Linux, which expects
>>> multi-CPU entry to be handled kexec() style, the SLOF firmware expects
>>> only one CPU to be active at entry, and to use a hypervisor RTAS
>>> method to enable the other CPUs one by one.
>>> This patch also implements this 'start-cpu' method, so that SLOF can
>>> start the secondary CPUs and marshal them into the kexec() holding
>>> pattern ready for entry into the guest OS.  Linux should, and in the
>>> future might directly use the start-cpu method to enable initially
>>> disabled CPUs, but for now it does require kexec() entry.
>>> Signed-off-by: Benjamin Herrenschmidt<address@hidden>
>>> Signed-off-by: Paul Mackerras<address@hidden>
>>> Signed-off-by: David Gibson<address@hidden>
>> We should pull in SLOF via a git submodule.  That ensures we ship
>> the source code along with the binary.
> Um, ok.  Do I need to do anything about this?

I'm also not sure this is too important. Most of our firmware blobs come from 
svn repos which can't be submoduled. And as long as we don't have a consistent 
policy about it, we can just as well stick with the README file.


reply via email to

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