From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53492) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiqvj-0008Ds-36 for qemu-devel@nongnu.org; Wed, 12 Dec 2012 13:21:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tiqvc-000549-93 for qemu-devel@nongnu.org; Wed, 12 Dec 2012 13:21:15 -0500 Received: from cantor2.suse.de ([195.135.220.15]:50483 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiqvb-00053y-Vf for qemu-devel@nongnu.org; Wed, 12 Dec 2012 13:21:08 -0500 Message-ID: <50C8CB0F.3080407@suse.de> Date: Wed, 12 Dec 2012 19:21:03 +0100 From: Alexander Graf 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> <50C8BF07.5050304@suse.de> In-Reply-To: <50C8BF07.5050304@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Eduardo Habkost , qemu-devel@nongnu.org, blauwirbel@gmail.com, Paul Brook , Anthony Liguori , Paolo Bonzini , imammedo@redhat.com On 12/12/2012 06:29 PM, Andreas F=E4rber wrote: > 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= it >>>>> 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 Has= well >>>> 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 line= s >>> of code significantly compared to just taking the values from elsewhe= re. >> The reuse doesn't need to be #define-based (although maybe a >> #define-based approach would work too), it could be function-call-base= d. >> >>> 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 bel= ow >>> is semantically right or just a coincidence. I was at least consideri= ng >>> an abstract intel-/amd-*-cpu to avoid repeating the three value >>> assignments over and over. >> 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. >> >>> At this time I believe the parents of a type are not (yet) exposed vi= a >>> QMP, just the "type" string property. >> 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. Considering that x86 is very straight forward in its CPU definitions, I=20 think we can easily make this a flat model based on CPUID features + a=20 few variables. If you really want to model something, I would rather say 386 -> 386SX -> 386DX opteron-G3 -> phenom-9550 -> phenom-9560 Any inheritance above that level sounds excessive to me. Alex > 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