From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57753) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwgPo-0000iN-9i for qemu-devel@nongnu.org; Wed, 01 Aug 2012 17:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwgPn-0000O3-39 for qemu-devel@nongnu.org; Wed, 01 Aug 2012 17:25:12 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51362 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwgPm-0000Np-P6 for qemu-devel@nongnu.org; Wed, 01 Aug 2012 17:25:11 -0400 Message-ID: <50199EB0.4040602@suse.de> Date: Wed, 01 Aug 2012 23:25:04 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 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> <8739467323.fsf@codemonkey.ws> In-Reply-To: <8739467323.fsf@codemonkey.ws> 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: Anthony Liguori 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 Am 01.08.2012 22:47, schrieb Anthony Liguori: > Andreas F=C3=A4rber writes: >=20 >> Am 01.08.2012 22:02, schrieb Anthony Liguori: >>> Devices do one of two things today: >>> >>> 1) register a reset callback >>> >>> 2) implement a reset method that is invoked through it's parent bus >>> >>> Since I don't expect CPUs to exist on a bus, it's not immediately cle= ar >>> 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. >=20 > 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. >=20 > So just implementing DeviceClass::reset doesn't automatically mean the > reset function will be called. In the short term, I think we'll need t= o > still register a reset handler. >=20 >> 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. I= t >> 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 a= nd >> calls ->reset on each! Then we can drop the reset callbacks in most >> machines rather than moving old code around. >=20 > Relying on the CPU list for this isn't very QOM-like. A better approac= h > would be to make all CPUs appear in a container and then have the reset > propagate through container. That doesn't work since our CPU modelling was going to be machine/SoC specific. For x86, agreement seemed to be /machine/cpu[n]. For ARM, Peter requested path/to/SoC/cortex/cpu[n]. I have just posted (and tested on x86_64) a really trivial patch that avoids walking the CPU list, reuses existing infrastructure and lets us drop the reset registration from target-i386, too. More reset callback registrations can then be dropped as follow-ups from other machines. Whether we walk a list or not, my point is to reduce redundancy. If it's in one central location we can easily exchange the implementation. And I do believe that calling my QOM method is very QOM-like rather than besmearing my nice new CPUClass::reset concept by unnecessarily introducing ugly old-style callbacks to my shiny QOM realize code. :) Regards, Andreas >=20 > Reset is a complicated beast. While we model a single reset line today= , > this isn't technically correct. I believe the distinction between rese= t > types start to matter with PCI-e actually. >=20 > 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. >=20 > Regards, >=20 > Anthony Liguori >=20 >> >> Regards, >> Andreas >> >>> >>> Regards, >>> >>> Anthony Liguori >>> >>>> >>>> Regards, >>>> Andreas >>>> >>>> --=20 >>>> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, German= y >>>> GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG = N=C3=BCrnberg >>> >> >> >> --=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=BC= rnberg