From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi17K-0003n8-23 for qemu-devel@nongnu.org; Sat, 25 Oct 2014 09:10:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xi17B-0002dN-SD for qemu-devel@nongnu.org; Sat, 25 Oct 2014 09:10:49 -0400 Received: from ozlabs.org ([103.22.144.67]:59899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi17B-0002ce-HX for qemu-devel@nongnu.org; Sat, 25 Oct 2014 09:10:41 -0400 Date: Fri, 24 Oct 2014 14:38:39 +0200 From: David Gibson Message-ID: <20141024123839.GD4794@voom> References: <5448D400.6010503@linaro.org> <5448E515.80300@suse.de> <5448E5D0.6070701@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/unnNtmY43mpUSKx" Content-Disposition: inline In-Reply-To: <5448E5D0.6070701@suse.de> Subject: Re: [Qemu-devel] dynamic sysbus instantiation and load_dtb implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , Ard Biesheuvel , Eric Auger , qemu list , Alex Williamson , Paolo Bonzini , Antonios Motakis , Christoffer Dall --/unnNtmY43mpUSKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 23, 2014 at 01:26:08PM +0200, Alexander Graf wrote: >=20 >=20 > On 23.10.14 13:24, Peter Maydell wrote: > > On 23 October 2014 12:23, Alexander Graf wrote: > >> On 23.10.14 12:19, Ard Biesheuvel wrote: > >>> The reason for this change was that, before, the DTB would only be > >>> generated once, and after a reset, the machine would go through the > >>> kernel boot protocol as before but the DTB pointer would point to > >>> garbage. Any idea how ppc deals with this? Do they recreate the device > >>> tree after each reset? > >> > >> Yes, we regenerate the device tree on each reset. > >=20 > > Any particular reason? Surely it's always the same... >=20 > We have the code in place anyway, it's not a performance critical code > path and putting it into a rom would be a waste of RAM, as it'd keep yet > another copy of something we can easily regenerate. >=20 > It's a matter of personal preference I guess. The "pseries" machine actually uses an odd hybrid. We create a "template" device tree with the common portions during early init. That's stored permanently, but is not guest visible. At reset time we augment the template with information which could very from one boot to another, then copy it into RAM for the SLOF firmware to read. It's not particularly efficient, but really, who cares. It's once per resent, and we're generally talking at most a few dozen kiB of device tree. --=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 --/unnNtmY43mpUSKx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUSkhPAAoJEGw4ysog2bOSS0QP/26Rp8lk2bftjX/eyvOHx0TB Lt4wvYiLhNagMNrZns1d+gqgf5oeDLv4OzPdMvdl7jebK+gTaLgV5+0NSXvQKo0D j2hzvsYB4PVfXfKOhopKICFsqFrZ26+az0I+UskD8j1P8SKHwoaMpJQpdVuGp6/b RwHEPE7PM2oW/1TBA/SKl3XctXAUIuOEVm7uhDQcw/XpO6sX0LqCNTk1PsRxrkNY NOUM5ZvhVUkPWZpSQS/5CLkC9Ly7N9JFun2gznyItfIA7HJfMLwtKuJB8TUKjtZ9 Z3bBD6MEPkCfffluJqPh4O+RQDfESZE+1/XVsRZ104RdHtXj715524V1awS9MYcW UY5NOy1AIvL8ws58vMb98SHYONlG2PK6ujbaLRjTP25AA9NTwNTLjoGdVL7u5bR8 y5gQXyRxiQIO37AMwh4Y/0JtKceS6AxyU+T13U+rsHcZcfj1D4CfpAsYigKvNB8e VleLe+IJJGUoX9b3Kx+vBfYV1VAKAZd0iDajiyTN6tOKlLbrRbYd8mPO1mUGBmYE vrb4atpHn1lbsKTv7iHPk29NhBEALrnI66xTAcdyeE7An48z5t6E5RVisNV/0yOP jdhczDiOd8Hi+3g/9/AwZisaz7HAv5Axis8U2aQ5EIJgpTgYPpJkCaWI9LUsbG7a ypLFAtX9zg4CEZKm3nB5 =Kf/L -----END PGP SIGNATURE----- --/unnNtmY43mpUSKx--