From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwhCq-0003P1-AM for qemu-devel@nongnu.org; Wed, 01 Aug 2012 18:15:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwhCo-0006G3-RA for qemu-devel@nongnu.org; Wed, 01 Aug 2012 18:15:52 -0400 Received: from cantor2.suse.de ([195.135.220.15]:53785 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwhCo-0006Fm-Hd for qemu-devel@nongnu.org; Wed, 01 Aug 2012 18:15:50 -0400 Message-ID: <5019AA8C.6090400@suse.de> Date: Thu, 02 Aug 2012 00:15:40 +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> <50199EB0.4040602@suse.de> In-Reply-To: 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: Peter Maydell Cc: Anthony Liguori , 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 23:43, schrieb Peter Maydell: > On 1 August 2012 22:25, Andreas F=C3=A4rber wrote: >> Am 01.08.2012 22:47, schrieb Anthony Liguori: >>> Relying on the CPU list for this isn't very QOM-like. A better appro= ach >>> would be to make all CPUs appear in a container and then have the res= et >>> 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]. >=20 > I don't think I got that specific (and I definitely wouldn't have > suggested using 'cortex' outside the context of a product name like tha= t). http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg02470.html Context was Exynos and it was /cortex-a9/core[n] to be exact; I had suggested to place them onto the SoC directly, you wanted to refine that. My point here is that the container is not just for the CPUs. And if we go ahead with /machine for x86 then for the time being that is not a device and as an Object does not have a reset mechanism that could trigger the CPUs' reset. I am leaning towards that a SoC should be a DeviceState but am unclear whether a SoC should have a central reset callback triggering the CPUs' reset. Doesn't sound like real hardware behavior to me. > I do think that there should be a container with the 4 (or whatever) CP= Us, > 4 timers, GIC, etc, similarly to the way the hardware is a selfcontaine= d > unit. (And that unit would then sit in a container with the other devic= es > that live in the SoC). I don't think that's hugely different from how > an x86 model would look. >=20 > (The phrasing I tend to use is "one cpu with 4 cores", but if QEMU > in general is going to call a single cpu core a "cpu" that's fine. > We do need a term for the thing with all the cores, though...) We had that discussion too and Anthony had some aggressive refactoring ideas CPU -> core -> thread, but I see that in the pretty distant future still. We haven't even managed to get a single data field into CPUState yet, which would be a prerequisite for splitting it up - my series until today conflicting with Igor's APIC refactoring. (Still working on making at least a baby step into that direction for 1.2!) >>> Reset is a complicated beast. While we model a single reset line tod= ay, >>> this isn't technically correct. I believe the distinction between re= set >>> types start to matter with PCI-e actually. >=20 > We already have one system (exynos) that would like to model a > difference between system hard reset and warm reset of some kind. >=20 > But really unless we want to bite the bullet and actually > model reset properly (ie as a set of Pins wired up by the machine > model, with no particular magic behaviour) it's always going to be > a 'this kind of works and isn't too ugly to deal with' compromise, > and I don't have very strong feelings about exactly how we > compromise. Well, we can easily add more callback hooks to CPUClass and/or change the implementation of my central cpu_reset(). A clear advantage over the old decentral cpu_[state_]reset(). :-) 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