From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swfpt-0002Fi-Iy for qemu-devel@nongnu.org; Wed, 01 Aug 2012 16:48:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swfps-0007nY-5A for qemu-devel@nongnu.org; Wed, 01 Aug 2012 16:48:05 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:48459) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swfpr-0007nU-Ur for qemu-devel@nongnu.org; Wed, 01 Aug 2012 16:48:04 -0400 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Aug 2012 14:47:44 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id AF3951FF0021 for ; Wed, 1 Aug 2012 20:47:10 +0000 (WET) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q71Kl67I093066 for ; Wed, 1 Aug 2012 14:47:06 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q71Kl5Ra016012 for ; Wed, 1 Aug 2012 14:47:06 -0600 From: Anthony Liguori In-Reply-To: <50198EA3.9070109@suse.de> References: <1343049748-11539-1-git-send-email-imammedo@redhat.com> <87zk6elisw.fsf@codemonkey.ws> <50195034.9050201@suse.de> <874nom8o5q.fsf@codemonkey.ws> <50198508.10303@suse.de> <87pq7acrdf.fsf@codemonkey.ws> <50198EA3.9070109@suse.de> Date: Wed, 01 Aug 2012 15:47:00 -0500 Message-ID: <8739467323.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/2 v3] target-i386: refactor reset handling and move it into cpu.c List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: peter.maydell@linaro.org, ehabkost@redhat.com, gleb@redhat.com, jan.kiszka@siemens.com, mtosatti@redhat.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, blauwirbel@gmail.com, avi@redhat.com, pbonzini@redhat.com, Igor Mammedov Andreas F=C3=A4rber writes: > Am 01.08.2012 22:02, schrieb Anthony Liguori: >> Devices do one of two things today: >>=20 >> 1) register a reset callback >>=20 >> 2) implement a reset method that is invoked through it's parent bus >>=20 >> Since I don't expect CPUs to exist on a bus, it's not immediately clear >> to me that (1) isn't going to be what we do for quite some time. > > Err, I thought devices implement a function assigned to a > DeviceClass::reset, no? That would be (2) on your list and we've been > working on ripping out (1) for devices, on sPAPR for instance. > (2) is what we already have with CPUClass::reset. Something has to call DeviceClass::reset. That's done through a BusState. Whenever a bus is created, a qemu_register_reset() call is made to invoke the reset method on any device that's part of the bus. So just implementing DeviceClass::reset doesn't automatically mean the reset function will be called. In the short term, I think we'll need to still register a reset handler. > The only remaining issue is that the CPUClass::reset callback is not > automatically called on machine/bus reset yet. > > And what I was saying is that moving the code is NOT an improvement. It > is NO functional change and it is NOT a prerequisite for any change on > the list today. So it is not needed for the to be released 1.2. > > A very low hanging fruit for 1.2 would be to register a SINGLE central > reset callback that iterates through the globally available CPU list and > calls ->reset on each! Then we can drop the reset callbacks in most > machines rather than moving old code around. Relying on the CPU list for this isn't very QOM-like. A better approach would be to make all CPUs appear in a container and then have the reset propagate through container. Reset is a complicated beast. While we model a single reset line today, this isn't technically correct. I believe the distinction between reset types start to matter with PCI-e actually. I do think any reduction in what's happening in machine is a net win. Even if we refactor this later, having the machine code do less and devices do more is an improvement. Regards, Anthony Liguori > > Regards, > Andreas > >>=20 >> Regards, >>=20 >> Anthony Liguori >>=20 >>> >>> 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=BCrnberg >>=20 > > > --=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= =BCrnberg