From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atSsR-0003bU-Dx for qemu-devel@nongnu.org; Fri, 22 Apr 2016 00:39:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atSsP-0007IB-3u for qemu-devel@nongnu.org; Fri, 22 Apr 2016 00:39:35 -0400 Date: Fri, 22 Apr 2016 14:22:37 +1000 From: David Gibson Message-ID: <20160422042237.GC15176@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> <20160421055227.GA15176@voom.fritz.box> <57186D20.9060002@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TYecfFk8j8mZq+dy" Content-Disposition: inline In-Reply-To: <57186D20.9060002@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: qemu-devel@nongnu.org, qemu-ppc@nongnu.org, agraf@suse.de, crosthwaite.peter@gmail.com --TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 21, 2016 at 04:03:12PM +1000, Alexey Kardashevskiy wrote: > On 04/21/2016 03:52 PM, David Gibson wrote: > >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. > >> > >> > >>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. >=20 >=20 > Ok. >=20 > >>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 > I meant timeframe :) Like "2.7 release" or so. Well.. it'd be nice to do this before the 2.7 release, but it really depends how much time I have to do this cleanup stuff. --=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 --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXGacMAAoJEGw4ysog2bOSxsYQAJLk5YNu4nF3yqFmtZzmoigA uJyKkXQUu+DuaX+RVHXv7kb24+Dn34An4HrGiEZZf7nRwYPk2dx1N4R1kmiDSxUB q9wynrHvw0Ry5QjTougIFK5HLdmUSDcXIhLw+G8PbupzJaEVgCNyZRlWHTy1pEn/ xZ7YGlo2YkOZkTUF65yBo7fyDgAbgu+cFWqGKxzH/8DcK8jQxVAz2LLmjj/dA6qQ p+IktLLFlMLGPWYmom9qm7wivk5xEm9uThegdjiS16BlN/3gyIBGocg/eYCjHh7Q dgitg1FbNgOQySQhSvLTcka3k3dCoHQ4K1LTiDtiouKzn44EkwULdpidfUazDPC1 i3uR+IiZnww3Rqba67Xwwy/qY1Q8V59zBO/E1S0qZNJKv/LrvI0VLBEgPijlcbMF ZlrXkyEr/VjxvR4NtrX6h2K5hR+TO0aKyJzIu1Kp1V30fdgRq4G2x4+0xBK5MZjR EsEwCtzE3XMlC6Cpi0UvgomnHu4nFrVUZBtFNPbQkKMPdTb9uZw8dzLLjOx5FN2C zEpFp4qyhEf3chqsuKKdYUPFHMpAldWZ4eNui/sVgEXvXA8qrbbV4T0hsKzNMgWu e9FYtScFpeLGBvlP+3yQb49UJ+B8xK0Jg3nhb1dMLFQAfpON+A4OVXCeLKTLtVqj 9w3hgqz6QvZAtfrAibzO =Pepf -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--