From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSnZN-0007QN-T7 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 03:18:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSnZJ-0007Jn-7P for qemu-devel@nongnu.org; Thu, 07 Jan 2010 03:18:13 -0500 Received: from [199.232.76.173] (port=50408 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSnZJ-0007Jd-4L for qemu-devel@nongnu.org; Thu, 07 Jan 2010 03:18:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9328) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSnZI-00049S-OA for qemu-devel@nongnu.org; Thu, 07 Jan 2010 03:18:09 -0500 Message-ID: <4B4598BC.4000206@redhat.com> Date: Thu, 07 Jan 2010 10:18:04 +0200 From: Avi Kivity 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> In-Reply-To: <4B459550.6000202@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: kvm-devel , Gleb Natapov , "Michael S. Tsirkin" , John Cooper , Alexander Graf , qemu-devel@nongnu.org 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. > > There are two main motivations behind the above approach: > 1. Sound guest cpu definition. > Using a predefined model should automatically set all the relevant > vendor/stepping/cpuid flags/cache sizes/etc. > We just can let every management application deal with it. It breaks > guest OS/apps. For instance there are MSI support in windows guest > relay on the stepping. > > 2. Simplifying end user and mgmt tools. > qemu/kvm have the best knowledge about these low levels. If we push > it up in the stack, eventually it reaches the user. The end user, > not a 'qemu-devel user' which is actually far better from the > average user. > > This means that such users will have to know what is popcount and > whether or not to limit migration on one host by adding sse4.2 or > not. > > 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. -- error compiling committee.c: too many arguments to function