From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSoqt-0006LH-QJ for qemu-devel@nongnu.org; Thu, 07 Jan 2010 04:40:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSoqn-0006Ed-OO for qemu-devel@nongnu.org; Thu, 07 Jan 2010 04:40:22 -0500 Received: from [199.232.76.173] (port=42920 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSoqn-0006EN-D8 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 04:40:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59962) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSoqm-00011i-Rr for qemu-devel@nongnu.org; Thu, 07 Jan 2010 04:40:17 -0500 Message-ID: <4B45AC18.8040003@redhat.com> Date: Thu, 07 Jan 2010 11:40:40 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B30EFDF.4060202@codemonkey.ws> <4B31F1BA.10005@redhat.com> <4B43D4E2.9050102@codemonkey.ws> <4B4402B1.1030605@redhat.com> <4B448F36.8030605@codemonkey.ws> <4B449467.4070606@redhat.com> <4B4494FC.1080907@codemonkey.ws> <4B449608.7040102@redhat.com> <4B4496E9.2030201@redhat.com> <20100106142231.GF2248@redhat.com> <4B449EE7.4050401@redhat.com> <4B44A2C6.4050504@redhat.com> <4B44A965.9040300@codemonkey.ws> <4B459550.6000202@redhat.com> <4B4598BC.4000206@redhat.com> <4B45A536.1070300@redhat.com> <4B45A851.5000401@redhat.com> In-Reply-To: <4B45A851.5000401@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: kvm-devel , Gleb Natapov , "Michael S. Tsirkin" , John Cooper , Alexander Graf , qemu-devel@nongnu.org On 01/07/2010 11:24 AM, Avi Kivity wrote: > On 01/07/2010 11:11 AM, Dor Laor wrote: >> On 01/07/2010 10:18 AM, Avi Kivity wrote: >>> On 01/07/2010 10:03 AM, Dor Laor wrote: >>>> >>>> We can debate about the exact name/model to represent the Nehalem >>>> family, I don't have an issue with that and actually Intel and Amd >>>> should define it. >>> >>> AMD and Intel already defined their names (in cat /proc/cpuinfo). They >>> don't define families, the whole idea is to segment the market. >> >> The idea here is to minimize the number of models we should have the >> following range for Intel for example: >> pentium3 - merom - penry - Nehalem - host - kvm/qemu64 >> So we're supplying wide range of cpus, p3 for maximum flexibility and >> migration, nehalem for performance and migration, host for maximum >> performance and qemu/kvm64 for custom maid. > > There's no such thing as Nehalem. Intel were ok with it. Again, you can name is corei7 or xeon34234234234, I don't care, the principle remains the same. > >>>> >>>> This is exactly what vmware are doing: >>>> - Intel CPUs : >>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1991 >>>> >>>> >>>> - AMD CPUs : >>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1992 >>>> >>>> >>> >>> They don't have to deal with different qemu and kvm versions. >>> >> >> Both our customers - the end users. It's not their problem. >> IMO what's missing today is a safe and sound cpu emulation that is >> simply and friendly to represent. qemu64,+popcount is not simple for >> the end user. There is no reason to through it on higher level mgmt. > > There's no simple solution except to restrict features to what was > available on the first processors. What's not simple about the above 4 options? What's a better alternative (that insures users understand it and use it and guest msi and even skype application is happy about it)?