From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSpKo-0005Er-JX for qemu-devel@nongnu.org; Fri, 30 Jan 2009 04:06:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSpKn-0005EP-Hu for qemu-devel@nongnu.org; Fri, 30 Jan 2009 04:06:45 -0500 Received: from [199.232.76.173] (port=43810 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSpKn-0005EM-Dy for qemu-devel@nongnu.org; Fri, 30 Jan 2009 04:06:45 -0500 Received: from mx2.redhat.com ([66.187.237.31]:41046) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSpKm-0000wr-W0 for qemu-devel@nongnu.org; Fri, 30 Jan 2009 04:06:45 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0U96d6R011588 for ; Fri, 30 Jan 2009 04:06:41 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0U96dQn028056 for ; Fri, 30 Jan 2009 04:06:40 -0500 Received: from localhost (vpn-10-40.str.redhat.com [10.32.10.40]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0U96bTg015666 for ; Fri, 30 Jan 2009 04:06:39 -0500 Date: Fri, 30 Jan 2009 14:36:52 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor Message-ID: <20090130090652.GA25998@amit-x200.pnq.redhat.com> References: <1233059726-8566-1-git-send-email-agraf@suse.de> <497F5C93.9080609@codemonkey.ws> <200901272239.36183.paul@codesourcery.com> <200901272256.41247.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901272256.41247.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On (Tue) Jan 27 2009 [22:56:40], Paul Brook wrote: > > > Although this is a bit different. We aren't actually emulating a > > > phenom. We're just taking what we have and calling it a phenom. I > > > suspect there's going to be a desire to call whatever we emulate > > > arbitrary things. > > > > I don't think we're likely to want the big list of cpus anyway. > > Argh. I got that completely wrong.I mean we *are* likely to want a big list of > cpus anyway. If done properly it should be fairly easy to maintain. > e.g. instead of missing out unimplemented feature flags in each cpu, add them > all, then have qemu mask out the ones it doesn't implement. What I'm thinking of is moving all the CPU definitions out from helper.c into $(PREFIX)/usr/share/qemu/cpu-defs/... with one file holding one definition, like $ cat core2duo.def model= 15 family = 16 stepping = 11 level = 10 . . . Adding a new def then just becomes a matter of submitting a text file for inclusion and doesn't need any recompilation. Also, there are many details not captured in a CPU def, like the cache sizes and types. They're hard-coded for all the CPUs in the cpuid helper function. So we could have those values too incorporated in the CPU def file an fall back to the defaults when not available. When we do get some kind of a machine FDT, we can specify the cpu type by either pointing to one of these files or by constructing a new CPU type by specifying individual values. Amit