From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1kYT-0005ZN-Pj for qemu-devel@nongnu.org; Tue, 23 Jul 2013 17:55:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1kYQ-0001hU-SM for qemu-devel@nongnu.org; Tue, 23 Jul 2013 17:55:37 -0400 Date: Tue, 23 Jul 2013 16:55:21 -0500 From: Scott Wood References: <1374506897-41089-1-git-send-email-agraf@suse.de> <1374608328.15592.36@snotra> <7EA7921E-AF13-4485-94E5-B4068CEDAA9E@suse.de> <1374614344.15592.38@snotra> In-Reply-To: (from agraf@suse.de on Tue Jul 23 16:44:02 2013) Message-ID: <1374616521.15592.39@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] PPC: E500: Generate device tree on reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org list:PowerPC" , qemu-devel Developers On 07/23/2013 04:44:02 PM, Alexander Graf wrote: >=20 >=20 > Am 23.07.2013 um 23:19 schrieb Scott Wood : >=20 > > On 07/23/2013 04:15:59 PM, Alexander Graf wrote: > >> On 23.07.2013, at 21:38, Scott Wood wrote: > >> > On 07/22/2013 10:28:17 AM, Alexander Graf wrote: > >> >> Today we generate the device tree once on machine =20 > initialization and then > >> >> store the finalized blob in memory to reload it on reset. > >> >> This is bad for 2 reasons. First we potentially waste a bunch =20 > of RAM for no > >> >> good reason, as we have all information required to regenerate =20 > the device > >> >> tree available anyways. > >> >> The second reason is even more important. On machine init when =20 > we generate > >> >> the device tree for the first time, we don't have all of the =20 > devices fully > >> >> initialized yet. But the device tree needs to potentially walk =20 > devices to > >> >> put information about them into the device tree. > >> > > >> > If you can't produce the entire device tree at init time, how =20 > can you calculate its size with a dry run? > >> > > >> > Device trees are generally pretty small; couldn't we just set a =20 > maximum size and allocate that much space? > >> It's what we do, unless we load it from the disk. In that case we =20 > take the fdt size from disk. > > > > So why do we need the dry run stuff? >=20 > Because dumpdtb otherwise generates a halfway complete dtb on the =20 > first dry pass as device realization is yet incomplete :). What I mean is why have a first pass at all? -Scott=