From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1at7ev-0004nz-No for qemu-devel@nongnu.org; Thu, 21 Apr 2016 02:00:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1at7eu-00051O-9g for qemu-devel@nongnu.org; Thu, 21 Apr 2016 02:00:13 -0400 Date: Thu, 21 Apr 2016 15:52:27 +1000 From: David Gibson Message-ID: <20160421055227.GA15176@voom.fritz.box> References: <1461119601-4936-1-git-send-email-david@gibson.dropbear.id.au> <1461119601-4936-8-git-send-email-david@gibson.dropbear.id.au> <571861C8.3060702@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <571861C8.3060702@ozlabs.ru> Subject: Re: [Qemu-devel] [RFC for-2.7 07/11] pseries: Move adding of fdt reserve map entries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: agraf@suse.de, crosthwaite.peter@gmail.com, qemu-ppc@nongnu.org, qemu-devel@nongnu.org --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2016 at 03:14:48PM +1000, Alexey Kardashevskiy wrote: > On 04/20/2016 12:33 PM, David Gibson wrote: > >The flattened device tree passed to pseries guests contains a list of > >reserved memory areas. Currently we construct this list early in > >spapr_build_fdt() as we sequentially write out the fdt. > > > >This will be inconvenient for upcoming cleanups, so this patch moves > >the reserve map changes to the end of fdt construction. This changes > >fdt_add_reservemap_entry() calls - which work when writing the fdt > >sequentially to fdt_add_mem_rsv() calls used when altering the fdt in > >random access mode. >=20 >=20 > Looks to me like the real reason for this move is that new qdt_setprop_xxx > API does not support memory reserve map yet. Will it, when? Right, and it's not clear that it even should include reserve map stuff. The reserve map isn't really part of the device tree, it's just included in the fdt blob for historical and implementation reasons. So I'd prefer to avoid managing a list of reserve entries in qdt - instead I was thinking of just having a list of reserves passed straight into qdt_flatten(). In the meantime, I'd prefer to defer that design decision. > In general, when > do you plan to get rid of _FDT()? Once I've got rid of all the calls to libfdt functions that need error catching. >=20 > Anyway, >=20 > Reviewed-by: Alexey Kardashevskiy >=20 >=20 >=20 > > > >Signed-off-by: David Gibson > >--- > > hw/ppc/spapr.c | 17 +++++++++-------- > > 1 file changed, 9 insertions(+), 8 deletions(-) > > > >diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c > >index 5356f4d..aef44a2 100644 > >--- a/hw/ppc/spapr.c > >+++ b/hw/ppc/spapr.c > >@@ -733,14 +733,6 @@ static void *spapr_build_fdt(sPAPRMachineState *spa= pr, > > fdt =3D g_malloc0(FDT_MAX_SIZE); > > _FDT((fdt_create(fdt, FDT_MAX_SIZE))); > > > >- if (spapr->kernel_size) { > >- _FDT((fdt_add_reservemap_entry(fdt, KERNEL_LOAD_ADDR, > >- spapr->kernel_size))); > >- } > >- if (spapr->initrd_size) { > >- _FDT((fdt_add_reservemap_entry(fdt, spapr->initrd_base, > >- spapr->initrd_size))); > >- } > > _FDT((fdt_finish_reservemap(fdt))); > > > > /* Root node */ > >@@ -976,6 +968,15 @@ static void *spapr_build_fdt(sPAPRMachineState *spa= pr, > > } > > > > g_free(bootlist); > >+ > >+ /* Build memory reserve map */ > >+ if (spapr->kernel_size) { > >+ _FDT((fdt_add_mem_rsv(fdt, KERNEL_LOAD_ADDR, spapr->kernel_size= ))); > >+ } > >+ if (spapr->initrd_size) { > >+ _FDT((fdt_add_mem_rsv(fdt, spapr->initrd_base, spapr->initrd_si= ze))); > >+ } > >+ > > return fdt; > > } > > > > >=20 >=20 --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXGGqaAAoJEGw4ysog2bOSY3kQAM1CClRUHHfWO/WVxbW5uIme Jv6N4sUUDSG3oFWd8oIu2G7mDUAEcf/MJfrm2BD9pnY+HASPabMaizOoP6UCFg+e 0NvFCHxvB8QLWnbMZevsB/A0hTIP44Uu4nK1Sbm4FwzwRnFAQeFGX4yLAacdcAyI uppzGCErVkNk7EYZ4o+Fd8A4eU1rqnMHaIOJKaod+JnLq4M/tYwg8SLTZJs2aTIX Z0IlBSSt/r1VmuyFgptso5t5xgdu+/c4fDf8tKoh8FOoHnAIlAMD+QAjQXRT+Qwp 8JPdzpc2hMe8SrVsEKjXFYTGoel9+/6lbHDh1uP9JSSNbOYhe/p7znKVbbxzCSRo jNQ38T92A5KySYMupAs4d2AUrbkk008ZzYkYQuVuCRVNv87sMgIxCGxWdmLGJOqJ unDRV1RVsphvVl1QnKho05pZEk8UbDO6zKUO0rplk3jA1tQ9Jl6rBIiIY0rcJT6r 3/3Lp68J/FAo0XKEjmvkx/cGssQbpMDcU9MPzJk+zDbUptKBZyEkqIsu+bRq3aHH wK2IOvkPsMKKu5EONC1F+SP80SQwMC004D59c9pEu6fyE3Coc3mwkUxcn2emLgDX Uxk/GDMtN6O8aXdHXGxk3BMMBQRi56OkCHgioX37uvhBIKKDD4p06M3+FRL/cIS0 3jjRa7HBtNiB1CIWvxur =5lhL -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--