From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NY0VH-0002vg-L3 for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:07:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NY0VD-0002qe-O0 for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:07:31 -0500 Received: from [199.232.76.173] (port=38763 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NY0VD-0002qG-F9 for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:07:27 -0500 Received: from mail-pz0-f186.google.com ([209.85.222.186]:46784) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NY0VC-0002Cy-Vo for qemu-devel@nongnu.org; Thu, 21 Jan 2010 12:07:27 -0500 Received: by pzk16 with SMTP id 16so120766pzk.18 for ; Thu, 21 Jan 2010 09:07:25 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4B586728.8040600@amd.com> References: <4B549016.6090501@redhat.com> <4B560A88.9@codemonkey.ws> <20100119200349.GG3204@sequoia.sous-sol.org> <4B563144.9030803@codemonkey.ws> <4B576311.3030906@redhat.com> <20100120202634.GA20754@redhat.com> <20100121002509.GM3204@sequoia.sous-sol.org> <4B57AB66.30802@redhat.com> <4B586728.8040600@amd.com> From: Blue Swirl Date: Thu, 21 Jan 2010 17:06:59 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: john cooper , Chris Wright , qemu-devel@nongnu.org, KVM list On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara wr= ote: > john cooper wrote: >> >> Chris Wright wrote: >>> >>> * Daniel P. Berrange (berrange@redhat.com) wrote: >>>> >>>> To be honest all possible naming schemes for '-cpu ' are just as >>>> unfriendly as each other. The only user friendly option is '-cpu host'= . >>>> IMHO, we should just pick a concise naming scheme & document it. Given >>>> they are all equally unfriendly, the one that has consistency with >>>> vmware >>>> naming seems like a mild winner. >>> >>> Heh, I completely agree, and was just saying the same thing to John >>> earlier today. =C2=A0May as well be -cpu {foo,bar,baz} since the meanin= g for >>> those command line options must be well-documented in the man page. >> >> I can appreciate the concern of wanting to get this >> as "correct" as possible. =C2=A0But ultimately we just >> need three unique tags which ideally have some relation >> to their associated architectures. =C2=A0The diatribes >> available from /proc/cpuinfo while generally accurate >> don't really offer any more of a clue to the model >> group, and in their unmodified form are rather unwieldy >> as command line flags. > > I agree. I'd underline that this patch is for migration purposes only, so > you don't want to specify an exact CPU, but more like a class of CPUs. If > you look into the available CPUID features in each CPU, you will find tha= t > there are only a few groups, with currently three for each vendor being a > good guess. > /proc/cpuinfo just prints out marketing names, which have only a mild > relationship to a feature-related technical CPU model. Maybe we can use a > generation approach like the AMD Opteron ones for Intel, too. > These G1/G2/G3 names are just arbitrary and have no roots within AMD. > > I think that an exact CPU model specification is out of scope for this pa= tch > and maybe even for QEMU. One could create a database with CPU names and > associated CPUID flags and provide an external tool to generate a QEMU > command line out of this. Keeping this database up-to-date (especially fo= r > desktop CPU models) is a burden that the QEMU project does not want to be= ar. > >> >>> This is from an EVC kb article[1]: >> >> Here is a pointer to a more detailed version: >> >> >> http://kb.vmware.com/selfservice/microsites/search.do?language=3Den_US&c= md=3DdisplayKC&externalId=3D1003212 >> >> >> We probably should also add an option to dump out the >> full set of qemu-side cpuid flags for the benefit of >> users and upper level tools. > > You mean like this one? > http://lists.gnu.org/archive/html/qemu-devel/2009-09/msg01228.html > Resending this patch set is on my plan for next week. What is the state o= f > this patch? Will it go in soon? Then I'd rebase my patch set on top of it= . FYI, a similar CPU flag mechanism has been implemented for Sparc and x86, unifying these would be cool.