From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xou7S-0005oe-DQ for qemu-devel@nongnu.org; Thu, 13 Nov 2014 08:07:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xou7L-0004Ls-0h for qemu-devel@nongnu.org; Thu, 13 Nov 2014 08:07:26 -0500 Received: from mail-wi0-f178.google.com ([209.85.212.178]:44350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xou7K-0004LL-RR for qemu-devel@nongnu.org; Thu, 13 Nov 2014 08:07:18 -0500 Received: by mail-wi0-f178.google.com with SMTP id bs8so8140924wib.5 for ; Thu, 13 Nov 2014 05:07:15 -0800 (PST) Message-ID: <5464ACC3.5060204@linaro.org> Date: Thu, 13 Nov 2014 14:06:11 +0100 From: Eric Auger MIME-Version: 1.0 References: <5448D400.6010503@linaro.org> <5448E515.80300@suse.de> <5448E5D0.6070701@suse.de> <20141024123839.GD4794@voom> <20141113040233.GJ7291@voom.fritz.box> In-Reply-To: <20141113040233.GJ7291@voom.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] dynamic sysbus instantiation and load_dtb implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson , Alexander Graf Cc: Peter Maydell , Ard Biesheuvel , qemu list , Alex Williamson , Antonios Motakis , Paolo Bonzini , Christoffer Dall On 11/13/2014 05:02 AM, David Gibson wrote: > 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: >>> >>> >>> 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. >>>> >>>> Any particular reason? Surely it's always the same... >>> >>> 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. >>> >>> 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. > > Oh, also, because we potentially have hotplug of VIO devices, it's > *not* necessarily the same every time. > Thanks for your inputs. I eventually proposed an implementation based on machine init done notifier, still using rom_add_blob_fixed. http://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg03812.html By the way, besides Alex, did anyone have time to review modifs in hw/arm/boot.c and overall process to enhance the original device tree? Are those modifications acceptable? Thank you in advance Best Regards Eric