From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. Date: Thu, 21 Jan 2010 15:39:36 +0100 Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Wright , "Daniel P. Berrange" , Anthony Liguori , qemu-devel@nongnu.org, KVM list To: john cooper Return-path: Received: from va3ehsobe003.messaging.microsoft.com ([216.32.180.13]:43607 "EHLO VA3EHSOBE003.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751800Ab0AUOlq (ORCPT ); Thu, 21 Jan 2010 09:41:46 -0500 In-Reply-To: <4B57AB66.30802@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. May as well be -cpu {foo,bar,baz} since the meaning 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. But ultimately we just > need three unique tags which ideally have some relation > to their associated architectures. The 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 that 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 patch 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 for desktop CPU models) is a burden that the QEMU project does not want to bear. > >> 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=en_US&cmd=displayKC&externalId=1003212 > > > 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 of this patch? Will it go in soon? Then I'd rebase my patch set on top of it. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXyER-0003wZ-L8 for qemu-devel@nongnu.org; Thu, 21 Jan 2010 09:41:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXyEL-0003u3-Pp for qemu-devel@nongnu.org; Thu, 21 Jan 2010 09:41:59 -0500 Received: from [199.232.76.173] (port=40996 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXyEL-0003tx-Il for qemu-devel@nongnu.org; Thu, 21 Jan 2010 09:41:53 -0500 Received: from va3ehsobe003.messaging.microsoft.com ([216.32.180.13]:43608 helo=VA3EHSOBE003.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1NXyEK-0000pN-H1 for qemu-devel@nongnu.org; Thu, 21 Jan 2010 09:41:53 -0500 Message-ID: <4B586728.8040600@amd.com> Date: Thu, 21 Jan 2010 15:39:36 +0100 From: Andre Przywara MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add definitions for current cpu models.. 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> In-Reply-To: <4B57AB66.30802@redhat.com> Content-Type: text/plain; charset="UTF-8"; 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: Chris Wright , qemu-devel@nongnu.org, KVM list 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. May as well be -cpu {foo,bar,baz} since the meaning 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. But ultimately we just > need three unique tags which ideally have some relation > to their associated architectures. The 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 that 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 patch 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 for desktop CPU models) is a burden that the QEMU project does not want to bear. > >> 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=en_US&cmd=displayKC&externalId=1003212 > > > 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 of this patch? Will it go in soon? Then I'd rebase my patch set on top of it. Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712