From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1kNK-00011t-UC for qemu-devel@nongnu.org; Tue, 23 Jul 2013 17:44:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1kNJ-00060Z-Ou for qemu-devel@nongnu.org; Tue, 23 Jul 2013 17:44:06 -0400 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> Mime-Version: 1.0 (1.0) In-Reply-To: <1374614344.15592.38@snotra> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: From: Alexander Graf Date: Tue, 23 Jul 2013 23:44:02 +0200 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: Scott Wood Cc: "qemu-ppc@nongnu.org list:PowerPC" , qemu-devel Developers Am 23.07.2013 um 23:19 schrieb Scott Wood : > 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 initialization and t= hen >> >> store the finalized blob in memory to reload it on reset. >> >> This is bad for 2 reasons. First we potentially waste a bunch of RAM f= or no >> >> good reason, as we have all information required to regenerate the dev= ice >> >> tree available anyways. >> >> The second reason is even more important. On machine init when we gene= rate >> >> the device tree for the first time, we don't have all of the devices f= ully >> >> initialized yet. But the device tree needs to potentially walk devices= to >> >> put information about them into the device tree. >> > >> > If you can't produce the entire device tree at init time, how can you c= alculate its size with a dry run? >> > >> > Device trees are generally pretty small; couldn't we just set a maximum= size and allocate that much space? >> It's what we do, unless we load it from the disk. In that case we take th= e fdt size from disk. >=20 > So why do we need the dry run stuff? Because dumpdtb otherwise generates a halfway complete dtb on the first dry p= ass as device realization is yet incomplete :). Alex >=20 > -SCott