From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a64a4-0007V7-EI for qemu-devel@nongnu.org; Mon, 07 Dec 2015 17:48:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a64a1-0003uK-37 for qemu-devel@nongnu.org; Mon, 07 Dec 2015 17:48:28 -0500 Received: from e06smtp07.uk.ibm.com ([195.75.94.103]:55257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a64a0-0003st-QZ for qemu-devel@nongnu.org; Mon, 07 Dec 2015 17:48:25 -0500 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 Dec 2015 22:48:20 -0000 References: <1447201710-10229-1-git-send-email-benh@kernel.crashing.org> <564290E1.3090205@redhat.com> <1447203387.31884.126.camel@kernel.crashing.org> <5642B59E.2070101@ozlabs.ru> <1447213139.31884.136.camel@kernel.crashing.org> <5642BEF9.90406@ozlabs.ru> <1447215397.31884.140.camel@kernel.crashing.org> <5642C6F0.9040200@ozlabs.ru> <56582EAF.40103@suse.de> <1448697599.3172.1.camel@kernel.crashing.org> <565C925F.60306@fr.ibm.com> <87bna3dp8g.fsf@linux.vnet.ibm.com> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: <56660CAE.8050706@fr.ibm.com> Date: Mon, 7 Dec 2015 23:48:14 +0100 MIME-Version: 1.0 In-Reply-To: <87bna3dp8g.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 00/77] ppc: Add "native" POWER8 platform List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stewart Smith , Benjamin Herrenschmidt , Alexander Graf , Alexey Kardashevskiy , Eric Blake , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org On 12/07/2015 02:25 AM, Stewart Smith wrote: > Cédric Le Goater writes: >> On 11/28/2015 08:59 AM, Benjamin Herrenschmidt wrote: >>> On Fri, 2015-11-27 at 11:21 +0100, Alexander Graf wrote: >>>> >>>> How does real hardware store petitboot? If it's flash, you could pass it >>>> in using -pflash and thus model things even more closely and allow users >>>> to just take the ROM image as is. >>> >>> It is a flash image, we could use an Open Power machine flash image "as-is" >>> provided we taught qemu to extract skiboot (aka OPAL) from it. >> >> Couldn't we add an offset argument to load_image_targphys() or make that >> an extra routine ? If so, we could then load directly from an openpower >> pnor file. >> >> I gave it a quick (and dirty) try and a powernv guest runs fine up to >> petitboot with just : >> >> qemu-system-ppc64 -m 2G -M powernv -bios ~/work/open-power/images/palmetto.pnor -nographic -nodefaults -serial stdio >> >> The pnor file is compiled from github. The patch is below (without the dirty >> cut and paste I did in loader.c). The offset for the PAYLOAD and BOOTKERNEL >> partitions are hard coded but I guess we don't need to read the flash partition >> table in qemu, not yet. > > One downside to this is that if we don't fall back to being able to load > skiboot.lid it becomes more annoying to boot a gcov enabled skiboot as > typical PNOR layout only gives 1MB for skiboot, and gcov builds bloat > that a *lot*. I guess that what we can imagine having a bigger partition for skiboot in the case of gcov ? This will require a custom pnor build. Might be too complex. Or we could use a -pflash option to load the pnor and an optional -bios for skiboot if we want a custom one. > We probably don't want NVRAM writes going back to a single system wide > PNOR image too, so while using pnor file is great for simulating what > hardware does, may not work as the solution for long term model. we can use a memory backend to start with, which is also much simpler than having to handle the block backend like the cfi pflash is doing. a guest could use its own private pnor if a block backend is needed. C.