From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSr1Y-0003PV-KG for qemu-devel@nongnu.org; Thu, 07 Jan 2010 06:59:32 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSr1S-0003Mu-Sg for qemu-devel@nongnu.org; Thu, 07 Jan 2010 06:59:30 -0500 Received: from [199.232.76.173] (port=41364 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSr1S-0003Mj-Lu for qemu-devel@nongnu.org; Thu, 07 Jan 2010 06:59:26 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39071) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSr1S-0005Do-3w for qemu-devel@nongnu.org; Thu, 07 Jan 2010 06:59:26 -0500 Message-ID: <4B45CC99.5070907@redhat.com> Date: Thu, 07 Jan 2010 13:59:21 +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> <4B4598BC.4000206@redhat.com> <4B45A536.1070300@redhat.com> <4B45A851.5000401@redhat.com> <4B45AC18.8040003@redhat.com> In-Reply-To: <4B45AC18.8040003@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 11:40 AM, Dor Laor wrote: >> 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. > There are several processors belonging to the Nehalem family and each have different features. > > What's not simple about the above 4 options? If a qemu/kvm/processor combo doesn't support a feature (say, nx) we have to remove it from the migration pool even if the Nehalem processor class says it's included. Or else not admit that combination into the migration pool in the first place. > What's a better alternative (that insures users understand it and use > it and guest msi and even skype application is happy about it)? > Have management scan new nodes and classify them. -- error compiling committee.c: too many arguments to function