From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoleX-0007Lr-0K for qemu-devel@nongnu.org; Wed, 12 Nov 2014 23:05:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoleT-00036Y-3i for qemu-devel@nongnu.org; Wed, 12 Nov 2014 23:05:00 -0500 Received: from ozlabs.org ([103.22.144.67]:50771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoleS-00036P-PM for qemu-devel@nongnu.org; Wed, 12 Nov 2014 23:04:57 -0500 Date: Thu, 13 Nov 2014 15:02:33 +1100 From: David Gibson Message-ID: <20141113040233.GJ7291@voom.fritz.box> References: <5448D400.6010503@linaro.org> <5448E515.80300@suse.de> <5448E5D0.6070701@suse.de> <20141024123839.GD4794@voom> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="q5r20fdKX+PFtYHw" Content-Disposition: inline In-Reply-To: <20141024123839.GD4794@voom> 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 , Eric Auger , Ard Biesheuvel , qemu list , Alex Williamson , Antonios Motakis , Paolo Bonzini , Christoffer Dall --q5r20fdKX+PFtYHw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 24, 2014 at 02:38:39PM +0200, David Gibson wrote: > 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 dev= ice > > >>> 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. >=20 > 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. >=20 > 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. >=20 > 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. Oh, also, because we potentially have hotplug of VIO devices, it's *not* necessarily the same every time. --=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 --q5r20fdKX+PFtYHw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUZC1ZAAoJEGw4ysog2bOS9McQAOQLv9muSjLwTwpMVtArJhlc 2K8mdsGYHdh7giW/0kRPnkAs1EPG1herDKTU4CIb+oijv1lEjHHjpnPBN8VrKFfh 0ZQ1JGDzQUXW94m/B7PpSWdcmzaJ5swSVz1hKfZQgZHJIJt1RbsxQFCeHjvt+h8D IGKttfcxzEYSk1/IuSg44IJSjCdsoY3J8UWCVVBYWo/V/mQSFBp/zXXNcWptoWtF /6kTDN+Fo1kL64lZXdYwDtIR/miiXzeRIu0XPe56JygX+C+0jWUzadi5MHturP92 T1xwGCJSm30yJ3nltp0cdU31Sr9JnZ2ET0oOCWx6CsZo3gPjKA8aOBMjqkVYXqmk u0twYNNWOik/Pa/ya2F2r9nAiPiukvhqgteH8EXpx3V6JH9GpoXj6CnRj92+k/MN 9vQo7tegsocg7OwbJz+O1st46PT4a29u04D6Z150xDrxyZwakjfCtfUZDphnpx68 QxKJE/IygAsORUaVdhRPyUxMVaxrIewrntSoT+362e7OWmxz8zq3mVEe4mxPUB+0 Q3dPuVag9oghokUqMhdJBNxeDWFFRxXqHKF+GXOMUUdQPaNjGDA1gL5olTBjsHKB HMQLkwcE1sgAU0ICecyWosGO3Bp+ZqmnMfHdBOc/i8d1+BZLVveRSdUtLN/atjBe 4So3HQ0MJshfD5OaYOAZ =wcps -----END PGP SIGNATURE----- --q5r20fdKX+PFtYHw--