From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSrL9-0002jy-E8 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:19:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSrL4-0002ho-MQ for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:19:46 -0500 Received: from [199.232.76.173] (port=43545 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSrL4-0002hi-E8 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:19:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2001) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSrL3-0003UM-PR for qemu-devel@nongnu.org; Thu, 07 Jan 2010 07:19:42 -0500 Message-ID: <4B45D170.7050000@redhat.com> Date: Thu, 07 Jan 2010 14:20:00 +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> <4B45AC18.8040003@redhat.com> <4B45C7EB.1010501@codemonkey.ws> <4B45C90C.1000507@redhat.com> <4B45CCCE.1010208@redhat.com> In-Reply-To: <4B45CCCE.1010208@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 02:00 PM, Avi Kivity wrote: > On 01/07/2010 01:44 PM, Dor Laor wrote: >>> So if you had a 2.6.18 kernel and a 2.6.33 kernel, it may be necessary >>> to say: >>> >>> (2.6.33) qemu -cpu Nehalem,-syscall >>> (2.6.18) qemu -cpu Nehalem >> >> >> Or let qemu do it automatically for you. > > qemu on 2.6.33 doesn't know that you're running qemu on 2.6.18 on > another node. > We can live with it, either have qemu realize the kernel version out of another existing feature or query uname. Alternatively, the matching libvirt package can be the one adding or removing it in the right distribution.