From mboxrd@z Thu Jan 1 00:00:00 1970 From: john cooper Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Wed, 20 Jan 2010 15:09:19 -0500 Message-ID: <4B5762EF.5020106@redhat.com> References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119221124.GA11920@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "Przywara, Andre" , qemu-devel@nongnu.org, KVM list , john.cooper@redhat.com To: Jamie Lokier , Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8764 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754481Ab0ATUNl (ORCPT ); Wed, 20 Jan 2010 15:13:41 -0500 In-Reply-To: <20100119221124.GA11920@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: Jamie Lokier wrote: > Anthony Liguori wrote: >> On 01/18/2010 10:45 AM, john cooper wrote: >>> 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,... > > When I saw that table just now, I had no idea whether Nehalem is newer > and more advanced than Penryn, or the other way around. I also have > no idea if "Core i7" is newer than "Core 2 Duo" or not. I can appreciate the argument above, however the goal was choosing names with some basis in reality. These were recommended by our contacts within Intel, are used by VmWare to describe their similar cpu models, and arguably have fallen to defacto usage as evidenced by such sources as: http://en.wikipedia.org/wiki/Conroe_(microprocessor) http://en.wikipedia.org/wiki/Penryn_(microprocessor) http://en.wikipedia.org/wiki/Nehalem_(microarchitecture) I suspect whatever we choose of reasonable length as a model tag for "-cpu" some further detail is going to be required. That was the motivation to augment the table as above with an instance of a LCD for that associated class. > I'm not a typical user: I know quite a lot about x86 architecture; > I just haven't kept up to date enough to know the code/model names. > Typical users will know less about them. Understood. One thought I had to further clarify what is going on under the hood was to dump the cpuid flags for each model as part of (or in addition to) the above table. But this seems a bit extreme and kvm itself can modify flags exported from qemu to a guest. -john -- john.cooper@redhat.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXgvt-0002FN-6v for qemu-devel@nongnu.org; Wed, 20 Jan 2010 15:13:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXgvn-00024V-S2 for qemu-devel@nongnu.org; Wed, 20 Jan 2010 15:13:40 -0500 Received: from [199.232.76.173] (port=60145 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXgvn-000243-Nz for qemu-devel@nongnu.org; Wed, 20 Jan 2010 15:13:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41334) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXgvn-0002Ty-6x for qemu-devel@nongnu.org; Wed, 20 Jan 2010 15:13:35 -0500 Message-ID: <4B5762EF.5020106@redhat.com> Date: Wed, 20 Jan 2010 15:09:19 -0500 From: john cooper MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119221124.GA11920@shareable.org> In-Reply-To: <20100119221124.GA11920@shareable.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier , Anthony Liguori Cc: john.cooper@redhat.com, "Przywara, Andre" , qemu-devel@nongnu.org, KVM list Jamie Lokier wrote: > Anthony Liguori wrote: >> On 01/18/2010 10:45 AM, john cooper wrote: >>> 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,... > > When I saw that table just now, I had no idea whether Nehalem is newer > and more advanced than Penryn, or the other way around. I also have > no idea if "Core i7" is newer than "Core 2 Duo" or not. I can appreciate the argument above, however the goal was choosing names with some basis in reality. These were recommended by our contacts within Intel, are used by VmWare to describe their similar cpu models, and arguably have fallen to defacto usage as evidenced by such sources as: http://en.wikipedia.org/wiki/Conroe_(microprocessor) http://en.wikipedia.org/wiki/Penryn_(microprocessor) http://en.wikipedia.org/wiki/Nehalem_(microarchitecture) I suspect whatever we choose of reasonable length as a model tag for "-cpu" some further detail is going to be required. That was the motivation to augment the table as above with an instance of a LCD for that associated class. > I'm not a typical user: I know quite a lot about x86 architecture; > I just haven't kept up to date enough to know the code/model names. > Typical users will know less about them. Understood. One thought I had to further clarify what is going on under the hood was to dump the cpuid flags for each model as part of (or in addition to) the above table. But this seems a bit extreme and kvm itself can modify flags exported from qemu to a guest. -john -- john.cooper@redhat.com