From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LSDVt-0004wc-7D
	for qemu-devel@nongnu.org; Wed, 28 Jan 2009 11:43:41 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LSDVr-0004w5-PD
	for qemu-devel@nongnu.org; Wed, 28 Jan 2009 11:43:40 -0500
Received: from [199.232.76.173] (port=38433 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LSDVq-0004vv-ST
	for qemu-devel@nongnu.org; Wed, 28 Jan 2009 11:43:38 -0500
Received: from mail2.shareable.org ([80.68.89.115]:53510)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1LSDVp-0008Fn-SV
	for qemu-devel@nongnu.org; Wed, 28 Jan 2009 11:43:38 -0500
Date: Wed, 28 Jan 2009 16:43:33 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [PATCH 2/2] Add phenom CPU descriptor
Message-ID: <20090128164333.GB14860@shareable.org>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Laurent Vivier <Laurent.Vivier@bull.net>

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.

That's an excellent idea.  The CPU list is a bit of historical
documentation of real CPU capabilities among other things, and not all
easy to verify, so having it be correct, and then QEMU masking things
out, sounds good to me.

-- Jamie