From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwtRP-0007Jx-Iq for qemu-devel@nongnu.org; Thu, 02 Aug 2012 07:19:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwtRL-0004rV-FY for qemu-devel@nongnu.org; Thu, 02 Aug 2012 07:19:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwtRL-0004rM-7O for qemu-devel@nongnu.org; Thu, 02 Aug 2012 07:19:39 -0400 Message-ID: <501A6243.4020800@redhat.com> Date: Thu, 02 Aug 2012 13:19:31 +0200 From: Igor Mammedov 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; format=flowed 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 , "Eduardo Habkost (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, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 08/01/2012 11:43 PM, Peter Maydell wrote: > 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]. > > 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). > 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. > > (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...) IMHO: CPU in qemu currently is more like a logical CPU. And x86 target might need a container for them as well if we are ever to=20 model CPU hotplug at socket level. It could be useful for NUMA modelling=20 as well. > >>> 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. > > We already have one system (exynos) that would like to model a > difference between system hard reset and warm reset of some kind. > > 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. > > -- PMM >