From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Date: Thu, 07 Jan 2010 14:17:49 +0200 Message-ID: <4B45D0ED.1040508@redhat.com> 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> <4B45CC99.5070907@redhat.com> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-devel , Gleb Natapov , "Michael S. Tsirkin" , John Cooper , Alexander Graf , qemu-devel@nongnu.org To: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:40431 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750838Ab0AGMRc (ORCPT ); Thu, 7 Jan 2010 07:17:32 -0500 In-Reply-To: <4B45CC99.5070907@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 01/07/2010 01:59 PM, Avi Kivity wrote: > 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. We can start with the older one, and once it get's that important add the newer ones. Until that happens users can either use -host or have nehalem,+sse4_2,+newFeature > >> >> 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. It still management role to compute least common denominator for live migration sets. btw: for nx disabled bios, we should just ignore it from product. Qemu direct users should add ,-nx > >> 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. > Of course. Just don't let management control stepping automatically, it should only be made for very advanced users and only manually.