From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXJvp-0001wU-1E for qemu-devel@nongnu.org; Tue, 19 Jan 2010 14:40:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXJvh-0001mY-0R for qemu-devel@nongnu.org; Tue, 19 Jan 2010 14:40:01 -0500 Received: from [199.232.76.173] (port=38861 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXJvg-0001mE-KF for qemu-devel@nongnu.org; Tue, 19 Jan 2010 14:39:56 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:58215) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXJvg-0002EX-8Y for qemu-devel@nongnu.org; Tue, 19 Jan 2010 14:39:56 -0500 Received: by qyk32 with SMTP id 32so860916qyk.4 for ; Tue, 19 Jan 2010 11:39:55 -0800 (PST) Message-ID: <4B560A88.9@codemonkey.ws> Date: Tue, 19 Jan 2010 13:39:52 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. References: <4B549016.6090501@redhat.com> In-Reply-To: <4B549016.6090501@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: john cooper Cc: "Przywara, Andre" , qemu-devel@nongnu.org, KVM list 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, 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