From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NY1Wp-0003OQ-5P for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:13:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NY1Wj-0003EH-UT for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:13:10 -0500 Received: from [199.232.76.173] (port=56856 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NY1Wj-0003E1-Om for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:13:05 -0500 Received: from mail2.shareable.org ([80.68.89.115]:51125) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NY1Wj-0003SP-Ef for qemu-devel@nongnu.org; Thu, 21 Jan 2010 13:13:05 -0500 Date: Thu, 21 Jan 2010 18:13:00 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Message-ID: <20100121181300.GC28467@shareable.org> References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119221124.GA11920@shareable.org> <4B5762EF.5020106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5762EF.5020106@redhat.com> 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 john cooper wrote: > 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) (Aside: I can confirm they haven't fallen into de facto usage anywhere in my vicinity :-) I wonder if the contact within Intel are living in a bit of a bubble where these names are more familiar than the outside world.) I think we can all agree that there is no point looking for a familiar -cpu naming scheme because there aren't any familiar and meaningful names these days. > used by VmWare to describe their similar cpu models If the same names are being used, I see some merit in qemu's list matching VMware's cpu models *exactly* (in capabilities, not id strings), to aid migration from VMware. Is that feasible? Do they match already? > 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. Here's another idea. It would be nice if qemu could tell the user which of the built-in -cpu choices is the most featureful subset of their own host. With -cpu host implemented, finding that is probably quite easy. Users with multiple hosts will get a better feel for what the -cpu names mean that way, probably better than any documentation would give them, because they probably have not much idea what CPU families they have anyway. (cat /proc/cpuinfo doesn't clarify, as I found). And it would give a simple, effective, quick indication of what they must choose if they want an VM image that runs on more than one of their hosts without a management tool. -- Jamie