From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzHot-0008VS-Lp for qemu-devel@nongnu.org; Wed, 26 Oct 2016 02:36:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzHop-0000kc-Ll for qemu-devel@nongnu.org; Wed, 26 Oct 2016 02:36:15 -0400 References: <1476823604-15403-1-git-send-email-thuth@redhat.com> <20161019021650.GC11140@umbus.fritz.box> <317ca528-643a-42be-0a5a-e5c25bb2dec6@redhat.com> <20161024120450.GH11052@umbus.fritz.box> <70f1e5d4-fb16-ff4e-0eba-42004de90a46@redhat.com> <20161026000347.GK11052@umbus.fritz.box> From: Thomas Huth Message-ID: Date: Wed, 26 Oct 2016 08:35:58 +0200 MIME-Version: 1.0 In-Reply-To: <20161026000347.GK11052@umbus.fritz.box> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="au8lfr3aemDI8uu11AMPL4G7t4fB4N1f5" Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 0/5] nvram: Refactor OpenBIOS NVRAM code to support -prom-env on pseries, too List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: "qemu-devel@nongnu.org" , "qemu-ppc@nongnu.org" , Bharata B Rao , Artyom Tarasenko This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --au8lfr3aemDI8uu11AMPL4G7t4fB4N1f5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 26.10.2016 02:03, David Gibson wrote: > On Tue, Oct 25, 2016 at 02:22:08PM +0200, Thomas Huth wrote: >> On 24.10.2016 14:04, David Gibson wrote: >>> On Mon, Oct 24, 2016 at 12:36:05PM +0200, Thomas Huth wrote: >>>> On 24.10.2016 12:22, Bharata B Rao wrote: >>>>> >>>>> On Wed, Oct 19, 2016 at 7:46 AM, David Gibson >>>>> > = wrote: >>>>> >>>>> On Tue, Oct 18, 2016 at 10:46:39PM +0200, Thomas Huth wrote: >>>>> > The OpenBIOS NVRAM set-up is based on the layout defined in t= he CHRP >>>>> > (Common Hardware Reference Platform) specification. This is t= he same >>>>> > layout that is also used by the PAPR specification and thus b= y the >>>>> SLOF >>>>> > firmware of the pseries machine. By refactoring the NVRAM cod= e from >>>>> > mac_nvram.c, we can use the same functions for setting up the= NVRAM >>>>> > for both, OpenBIOS and SLOF. This way we can support the "-pr= om-env" >>>>> > parameter of QEMU for SLOF, too, which is very useful to infl= uence >>>>> > the firmware boot process. >>>>> > >>>>> > Thomas Huth (5): >>>>> > nvram: Introduce helper functions for CHRP "system" and "fr= ee space" >>>>> > partitions >>>>> > sparc: Use the new common NVRAM functions for system and fr= ee space >>>>> > partition >>>>> > spapr_nvram: Pre-initialize the NVRAM to support the -prom-= env >>>>> > parameter >>>>> > nvram: Move the remaining CHRP NVRAM related code to chrp_n= vram.[ch] >>>>> > nvram: Rename openbios_firmware_abi.h into sun_nvram.h >>>>> > >>>>> > hw/nvram/Makefile.objs | 1 + >>>>> > hw/nvram/chrp_nvram.c | 85 >>>>> ++++++++++++++++++++++ >>>>> > hw/nvram/mac_nvram.c | 49 +++-= --------- >>>>> > hw/nvram/spapr_nvram.c | 6 ++ >>>>> > hw/sparc/sun4m.c | 35 ++--= ----- >>>>> > hw/sparc64/sun4u.c | 35 ++--= ----- >>>>> > include/hw/nvram/chrp_nvram.h | 54 >>>>> ++++++++++++++ >>>>> > .../nvram/{openbios_firmware_abi.h =3D> sun_nvram.h} | 47 +-= ---------- >>>>> > tests/postcopy-test.c | 8 +- >>>>> > 9 files changed, 179 insertions(+), 141 deletions(-) >>>>> > create mode 100644 hw/nvram/chrp_nvram.c >>>>> > create mode 100644 include/hw/nvram/chrp_nvram.h >>>>> > rename include/hw/nvram/{openbios_firmware_abi.h =3D> sun_nv= ram.h} >>>>> (50%) >>>>> >>>>> Series, >>>>> >>>>> Reviewed-by: David Gibson >>>> > >>>>> >>>>> I've put it into ppc-for-2.8 tentatively. However I'd like to = get an >>>>> Acked-by from Mark for the Sparc bits before I send my next pul= l >>>>> request. >>>>> >>>>> >>>>> I observe an early boot failure in SLOF with a commit from this pat= chset >>>>> on ppc-for-2.8 branch. >>>>> >>>>> 4e1257ed41bce16baa8a010 - spapr_nvram: Pre-initialize the NVRAM to >>>>> support the -prom-env parameter >>>>> >>>>> SLOF **************************************************************= ******** >>>>> QEMU Starting >>>>> Build Date =3D Oct 19 2016 09:58:38 >>>>> FW Version =3D git-efd65f49929d7db7 >>>>> Press "s" to enter Open Firmware. >>>>> >>>>> Populating /vdevice methods >>>>> Populating /vdevice/vty@71000000 >>>>> Populating /vdevice/nvram@71000001 >>>>> Populating /vdevice/v-scsi@71000002 >>>>> SCSI: Looking for devices >>>>> 8200000000000000 CD-ROM : "QEMU QEMU CD-ROM 2.= 5+" >>>>> Populating /pci@800000020000000 >>>>> 00 1000 (D) : 1033 0194 serial bus [ usb-xh= ci ] >>>>> 00 0800 (D) : 1af4 1001 virtio [ block ] >>>>> 00 0000 (D) : 1af4 1000 virtio [ net ] >>>>> Scanning USB >>>>> XHCI: Initializing >>>>> Using default console: /vdevice/vty@71000000 >>>>> =20 >>>>> Welcome to Open Firmware >>>>> >>>>> Copyright (c) 2004, 2011 IBM Corporation All rights reserved. >>>>> This program and the accompanying materials are made available >>>>> under the terms of the BSD License available at >>>>> http://www.opensource.org/licenses/bsd-license.php >>>>> >>>>> >>>>> Trying to load: from: /pci@800000020000000/scsi@1 ... Successful= ly loaded >>>>> error: out of memory. >>>>> out of memory >>>>> Aborted. Press any key to exit. >>>> >>>> Yuck. Confirmed. Sorry for the inconvenience. Seems like SLOF does n= ot >>>> create the properties in the /options device tree node anymore in th= is case. >>>> >>>> David, could you please unqueue the "spapr_nvram: Pre-initialize the= >>>> NVRAM to support the -prom-env parameter" patch from the ppc-for-2.8= >>>> branch until I figure out a fix for this problem? Thanks! >>> >>> Done. >> >> FYI, SLOF patch to fix this issue is on the way: >> https://patchwork.ozlabs.org/patch/686426/ >=20 > Ok. So it was a matter of this change exposing a bug in SLOF, rather > than being buggy of itself? Yes. SLOF should always keep the /options device tree node populated and up to date, no matter whether a variable is available in the NVRAM partition or not. (Well, not sure, but it could maybe also have exposed a bug in grub2 since that simply does not seem to work if the variable "real-mode?" is not there ... but grub2 seems to work fine if it's there, no matter if I use -prom-env "real-mode?=3Dfalse" or -prom-env "real-mode?=3Dtrue" ...) Anyway, I think it might also be better to change this QEMU patch here a little bit, so that the NVRAM only gets pre-initialized if the user specified a "-prom-env" parameter. That means, for the normal use-case, the behavior will stay the same, and we do not have to pull in another SLOF update to fix this issue. I'll rework my patch and post a new version when it's ready. Thomas --au8lfr3aemDI8uu11AMPL4G7t4fB4N1f5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJYEE7VAAoJEC7Z13T+cC21FjIQAJI9a2NO0irJpaSzDpmESk0D rJcHJzDtvxW3/QVyBf/RuReyJ7H9fQuVV2R3KbiWrWY8iuuOJhZnk0ybMLo6lNem VSmyEaIBJdwMJKKHEjMkAI5fB9F6B6Q6pgGmbDSfsOGzwPvVEGuIYWNqM6vAMp9J eq6zMBReR8jVT0jgbwKxVqqlGWkFenf5Z6fvO7sHygk0bq3eTLf5UCxmjl2ePEds wBhg0TZEdBD2AiOjsBwT7tROtXtG/ty8CwdUm8I8rMPVX70kFjuNg/PPyMKo35Iv kJITGhY6eWuFcZUIUUI6x5ToGUI9qoOEnSEgKHLzBdqqLchPReX+ye1w5DqYDR7v 9BYyL7WAr8OCv3rEWypC8+MSEQZF2n2Ol8N2u5HY1CdZT5pvSBeR+Qa4rPUuIjGQ RWjtiQr8MEx7t6xxMsURSsDMHfZR0VSb0hsOpvofB7wB625dVbq9qhHVcDm3TrBg 1zU7AhPUKMg1+/maeLkRpJqokEI3+LDeh9+/E3IzzCYqrX2o7ghEEfqpxIPnrvr1 fgsodMznp8HD6RKGdnxmHrLN0SekF3CvEn3vp745Rl+9w51xXBkQFRi7Ow4ZmDX4 /2VPuw2sjCQUGG8kBkTafaqa5B894XoW5mA5N9W6cfOhszGfM2EG75sLM/swy8Qs NI+PV0nA37qmD8B6ip4G =o17d -----END PGP SIGNATURE----- --au8lfr3aemDI8uu11AMPL4G7t4fB4N1f5--