From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxIyB-0005ar-MU for qemu-devel@nongnu.org; Fri, 03 Aug 2012 10:35:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxIy9-0008Ey-A7 for qemu-devel@nongnu.org; Fri, 03 Aug 2012 10:35:15 -0400 Received: from mail-we0-f173.google.com ([74.125.82.173]:35754) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxIy9-0008Eq-3t for qemu-devel@nongnu.org; Fri, 03 Aug 2012 10:35:13 -0400 Received: by weyz53 with SMTP id z53so467730wey.4 for ; Fri, 03 Aug 2012 07:35:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87wr1gnjhk.fsf@codemonkey.ws> References: <1343873409-8571-1-git-send-email-david@gibson.dropbear.id.au> <1343873409-8571-3-git-send-email-david@gibson.dropbear.id.au> <501AA071.3030406@suse.de> <87vch1i1va.fsf@codemonkey.ws> <501AC915.5080004@suse.de> <87lihx84m4.fsf@codemonkey.ws> <20120803023726.GH12733@truffala.fritz.box> <878vdwm6dt.fsf@codemonkey.ws> <87wr1gnjhk.fsf@codemonkey.ws> Date: Fri, 3 Aug 2012 15:35:11 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 2/2] pseries: Use new hook to correct reset sequence List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Igor Mammedov , agraf@suse.de, qemu-devel@nongnu.org, =?UTF-8?Q?Andreas_F=C3=A4rber?= , David Gibson On 3 August 2012 15:22, Anthony Liguori wrote: > Peter Maydell writes: >> On 3 August 2012 14:50, Anthony Liguori wrote: >>> There ought to be a hierarchy (based on composition) that reset flows >>> through. >> >> I think saying "the reset tree is isomorphic to the composition tree" >> is making the same mistake that qbus did with "the bus tree is >> isomorphic to the composition tree". The stakes are lower for reset >> and we can probably get away with it, but it really isn't how the >> hardware works... > > It flows through the composition tree by default, but can be overridden > at any point. That doesn't let you model situations where reset doesn't start at the root of the tree, though. (eg, reset controller wants to trigger a reset of just the CPUs, or of CPUs + board devices). > So this model should work very well for most types of virtual hardware. > But it doesn't provide for a mechanism to "after all devices are > initialized, build FDT in guest memory, then set the CPU registers to > point to it". > > There's no logical device that has a scope like that that also has the > mechanism to get that type of hook in the reset path. That's why we > need to have the QEMUMachine::reset() hook. Yeah, I see the need, but I wonder if calling it 'reset' is confusing: maybe it should be 'post-reset', 'post-realize' or something? The arm_boot code needs to do set up and run at this point too. The other oddball case for reset is ARM M-profile cores, where the initial PC is read from a vector table at reset rather than being a fixed value. At the moment the mechanism we use for this is deeply hacky: some more generic mechanism for "do this when we come out of reset but before starting to execute" might be useful there. -- PMM