From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiq82-0005HM-El for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:30:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tiq7w-0006UH-Bf for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:29:54 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48382 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiq7w-0006U9-22 for qemu-devel@nongnu.org; Wed, 12 Dec 2012 12:29:48 -0500 Message-ID: <50C8BF07.5050304@suse.de> Date: Wed, 12 Dec 2012 18:29:43 +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> <50C89915.7060600@suse.de> <20121212150513.GE3236@otherpad.lan.raisama.net> In-Reply-To: <20121212150513.GE3236@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: qemu-devel@nongnu.org, Alexander Graf , blauwirbel@gmail.com, Paul Brook , Anthony Liguori , Paolo Bonzini , imammedo@redhat.com Am 12.12.2012 16:05, schrieb Eduardo Habkost: > On Wed, Dec 12, 2012 at 03:47:49PM +0100, Andreas F=E4rber wrote: >> 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 i= t >>>> a superset of the features present on the SandyBridge model" >>>> >>>> Inherit from SandyBridge to keep only the delta for Haswell. >>> >>> Most CPUs have a superset of the features of their predecessors. Are = you >>> simply using SandyBridge->Haswell as an example, or you think their >>> relationship is special somehow? >>> >>> I believe we don't want to make externally-visible class inheritance, >>> but probably just reuse constans or init functions internally. A Hasw= ell >>> CPU is not a type of SandyBridge CPU, it just happens to contain a >>> superset of the features present in SandyBridge. >>> >>> 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 elsewher= e. >=20 > The reuse doesn't need to be #define-based (although maybe a > #define-based approach would work too), it could be function-call-based= . >=20 >> >> 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 belo= w >> is semantically right or just a coincidence. I was at least considerin= g >> an abstract intel-/amd-*-cpu to avoid repeating the three value >> assignments over and over. >=20 > Creating X86IntelCPU and X86AMDCPU classes make sense to me, because > Haswell is a kind of Intel CPu. Making Haswell a subclass of 486 (like > below) wouldn't. >=20 >> >> At this time I believe the parents of a type are not (yet) exposed via >> QMP, just the "type" string property. >=20 > Even if they are not exposed externally, it's a confusing usage of > inheritance for me. I mean: a Haswell CPU is not a type of 486 CPU, it'= s > simply a different kind of CPU that happens to have a superset of the > 486 features. I concur with your is-a argument. My patch took a pragmatic approach. I'd like to wait for some more review comments on how to share code between models then - I remember Paul, Anthony and Alex discussing the x86 models a while back on IRC, CC'ing. (Summary: reading CPU models from config files has been dropped, we only have built-in models left - now how to design name-class mappings below X86CPU) 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