From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models..
Date: Tue, 19 Jan 2010 13:39:52 -0600
Message-ID: <4B560A88.9@codemonkey.ws>
References: <4B549016.6090501@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: KVM list <kvm@vger.kernel.org>, qemu-devel@nongnu.org,
	"Przywara, Andre" <Andre.Przywara@amd.com>
To: john cooper <john.cooper@redhat.com>
In-Reply-To: <4B549016.6090501@redhat.com>
Sender: kvm-owner@vger.kernel.org

On 01/18/2010 10:45 AM, john cooper wrote:
> This is a rework of the prior version which adds definitions
> for contemporary processors selected via -cpu<model>, as an
> alternative to the existing use of "-cpu qemu64" augmented
> with a series of feature flags.
>
> The primary motivation was determination of a least common
> denominator within a given processor class to simplify guest
> migration.  It is still possible to modify an arbitrary model
> via additional feature flags however the goal here was to
> make doing so unnecessary in typical usage.  The other
> consideration was providing models names reflective of
> current processors.  Both AMD and Intel have reviewed the
> models in terms of balancing generality of migration vs.
> excessive feature downgrade relative to released silicon.
>
> Concerning the prior version of the patch, the proposed name
> used for a given model drew a fair amount of debate, the
> main concern being use of names as mnemonic as possible to
> the wisest group of users.  Another suggestion was to use
> the vendor name of released silicon corresponding to a least
> common denominator CPU within the class, rational being doing
> so is more definitive of the intended functionality.  However
> something like:
>
>       -cpu "Intel Core 2 Duo P9xxx"
>    

Stick with Xeon naming, it's far less annoying.

> probably isn't all that easy to remember nor type when
> selecting a Penryn class cpu.  So I struck what I believe to
> be a reasonable compromise where the original x86_def_t.name
> was for the most part retained with the x86_def_t.model_id
> capturing the marketing name of the cpu being used as the
> least common denominator for the class.  To make it easier for
> a user to associate a *.name with *.model_id, "-cpu ?" invoked
> rather as "-cpu ??" will append *.model_id to the generated
> table:
>
>          :
>      x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
>      x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
>      x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
>      x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
>      x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
>      x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
>          :
>    

I'm very much against having -cpu Nehalem.  The whole point of this is 
to make things easier for a user and for most of the users I've 
encountered, -cpu Nehalem is just as obscure as -cpu qemu64,-sse3,+vmx,...

Regards,

Anthony Liguori