From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TinbN-0008JG-Kc for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:48:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TinbH-0003Kn-Kx for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:48:01 -0500 Received: from cantor2.suse.de ([195.135.220.15]:39758 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TinbH-0003Kc-Am for qemu-devel@nongnu.org; Wed, 12 Dec 2012 09:47:55 -0500 Message-ID: <50C89915.7060600@suse.de> Date: Wed, 12 Dec 2012 15:47:49 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1355180372-6525-1-git-send-email-afaerber@suse.de> <1355180372-6525-3-git-send-email-afaerber@suse.de> <20121212124529.GB3236@otherpad.lan.raisama.net> In-Reply-To: <20121212124529.GB3236@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC qom-cpu v2 2/2] target-i386: Turn Haswell into subclass of SandyBridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: blauwirbel@gmail.com, imammedo@redhat.com, qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini Am 12.12.2012 13:45, schrieb Eduardo Habkost: > On Mon, Dec 10, 2012 at 11:59:32PM +0100, Andreas F=E4rber wrote: >> ehabkost: "When adding the Haswell CPU model, I intended to make it >> a superset of the features present on the SandyBridge model" >> >> Inherit from SandyBridge to keep only the delta for Haswell. >=20 > Most CPUs have a superset of the features of their predecessors. Are yo= u > simply using SandyBridge->Haswell as an example, or you think their > relationship is special somehow? >=20 > I believe we don't want to make externally-visible class inheritance, > but probably just reuse constans or init functions internally. A Haswel= l > CPU is not a type of SandyBridge CPU, it just happens to contain a > superset of the features present in SandyBridge. >=20 > I mean: Haswell also has a superset of features of 486, but we don't > want to make the hierarchy look like the following, do we? I don't see why we would want to use a #define-based inheritence as suggested for the PPRO when we have QOM. QOM inheritence reduces lines of code significantly compared to just taking the values from elsewhere. For the Haswell you said what I quoted, for the other models I said I need your or someone's help to verify whether a hierarchy such as below is semantically right or just a coincidence. I was at least considering an abstract intel-/amd-*-cpu to avoid repeating the three value assignments over and over. At this time I believe the parents of a type are not (yet) exposed via QMP, just the "type" string property. Andreas > - X86CPU > -> X86IntelCPU > -> 486 > -> pentium > -> pentium2 > -> pentium3 > -> Conroe > -> Penryn > -> Nehalem > -> Westmere > -> SandyBridge > -> Haswell --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg