From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SysKW-0006bW-81 for qemu-devel@nongnu.org; Tue, 07 Aug 2012 18:32:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SysKU-0005MG-Vb for qemu-devel@nongnu.org; Tue, 07 Aug 2012 18:32:48 -0400 Received: from cantor2.suse.de ([195.135.220.15]:58451 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SysKU-0005Kv-M4 for qemu-devel@nongnu.org; Tue, 07 Aug 2012 18:32:46 -0400 Message-ID: <50219787.2000407@suse.de> Date: Wed, 08 Aug 2012 00:32:39 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 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> <501BE7CE.4080200@suse.de> <1344376938.2698.27.camel@pasglop> In-Reply-To: <1344376938.2698.27.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Benjamin Herrenschmidt Cc: Igor Mammedov , David Gibson , agraf@suse.de, Anthony Liguori , qemu-devel@nongnu.org Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt: > On Fri, 2012-08-03 at 17:01 +0200, Andreas F=C3=A4rber wrote: >> >> I have posted a suggestion where CPU reset is triggered by "the >> machine >> as an abstract concept" (needs a bit of tweaking still, but the >> general >> idea is there). >> Based on that, shouldn't it be rather easy to add a Notifier similar >> to >> "machine init done" that lets individual machines do post-reset setup? >> I.e. not have QEMUMachine trigger and control the reset. >> >=20 > Note that we really want pre and post reset vs the device reset. >=20 > That's why the machine should be the one in charge. The top level of th= e > reset sequencing is -not- the CPU, it's the machine. All machines (or > SoCs) have some kind of reset controller and provide facilities for > resetting individual devices, busses, processor cores.... the global > "system" reset (when it exists) itself might have interesting ordering > or sequencing requirements. >=20 > Now, to fix our immediate problem on ppc for 1.2 the hook proposed by > Anthony for which David sent a patch does the job just fine, it allows > us to clean out all our iommu tables before the device-reset, meaning > that in-flights DMA cannot overwrite the various "files" (SLOF image > etc.... that are auto-loaded via reset handlers implicitely created by > load_image_targphys), and we can then do some post-initializations as > well to get things ready for a restart (rebuild the device-tree, etc...= ) That's all good, except for embedded machines without such implicit reset handling. It does contradict the "a machine is just a config file, setting up QOM objects" concept, but I was not the one to push that! :) What I was thinking about however were those mentioned individual cores being reset using cpu_reset(). If we want to piggy-back some machine-specific register initialization for individual CPUStates then QEMUMachine::reset is not going to be enough because it only gets triggered for complete system reset. My suggestion was thus to just call cpu_reset() in your QEMUMachine::reset and have cpu_reset() take care of its initialization wherever called from. Any of these solutions are easy to implement for 1.2 if agreement is reached what people want. What I am missing from Anthony's side is some communication to machine maintainers on the course to adopt before applying random patches. Right now x86 and ppc are moving into opposite directions and arm, mips, etc. maintainers may not even be aware of ongoing changes, and there's a pending uc32 machine that should be reviewed in this light. Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg