From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx0Hu-000315-03 for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:38:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx0Hs-00009x-Vm for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:38:21 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59595 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx0Hs-00009p-LM for qemu-devel@nongnu.org; Thu, 02 Aug 2012 14:38:20 -0400 Message-ID: <501AC915.5080004@suse.de> Date: Thu, 02 Aug 2012 20:38:13 +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> In-Reply-To: <87vch1i1va.fsf@codemonkey.ws> 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: Anthony Liguori Cc: agraf@suse.de, Igor Mammedov , qemu-devel@nongnu.org, David Gibson Am 02.08.2012 20:29, schrieb Anthony Liguori: > Andreas F=C3=A4rber writes: >=20 >> Anthony was favoring moving reset code out of machines and expressed >> dislike for looping through CPUs, which my above patch took into >> account. The ordering issue between CPU and devices is still unsolved = there. >> >> Some on-list comments from Anthony would be nice, since we are moving >> into opposing directions here - having the sPAPR machine be more in >> control vs. moving code away from the PC machine into target-i386 CPU >> and/or common CPU code. >=20 > I already commented on the first patch because I had a feeling you'd > post something like this ;-) I was not cc'ed. :( > Regarding reset: >=20 > 1) Devices should implement DeviceState::reset() >=20 > 2) If a device doesn't implement ::reset(), it should call > qemu_register_reset() >=20 > 3) Reset should propagate through the device model, starting with the > top-level machine which is logically what's plugged into the wall and > is the source of power in the first place. So you changed your opinion over night? I wanted to keep the reset callbacks in the machine. You applied a patch breaking that pattern and argued you wanted to move reset code *out* of the machine. Now you say the machine should *propagate* reset. Sorry, that's unlogical to me... If the machine should propagate reset then the disputed i386 patch is doing The Wrong Thing. If reset code should vanish from machine code AFAP then this patch is doing The Wrong Thing. No? Regards, 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