From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSWP9-00047i-0y for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:58:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSWP4-00043y-AH for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:58:30 -0500 Received: from [199.232.76.173] (port=42198 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSWP4-00043r-2G for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:58:26 -0500 Received: from mx20.gnu.org ([199.232.41.8]:15524) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSWP3-0003jV-I5 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:58:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSWOo-0001AI-8F for qemu-devel@nongnu.org; Wed, 06 Jan 2010 08:58:10 -0500 Message-ID: <4B4496E9.2030201@redhat.com> Date: Wed, 06 Jan 2010 15:58:01 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <20091220172341.GB21163@redhat.com> <2162E312-0110-42E1-A391-D75A6F013554@suse.de> <20091220173702.GC21163@redhat.com> <4B2E660F.1050703@codemonkey.ws> <20091221074355.GU4490@redhat.com> <4B2F31B1.6040403@redhat.com> <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> In-Reply-To: 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: Alexander Graf Cc: Gleb Natapov , "Michael S. Tsirkin" , John Cooper , dlaor@redhat.com, qemu-devel@nongnu.org On 01/06/2010 03:55 PM, Alexander Graf wrote: > >> Well, we can freeze qemu64 if we wish. That's still not 100% accurate since kvm can remove features from qemu64. >> >> -cpu none,+flags,vendor=foo,cache=bar,ad=nauseum? >> > I'd rather add a "kvm" cpu and leave the qemu64 one to qemu tcg features. > We can probably default -enable-kvm to -cpu host, as long as we explain very carefully that if users wish to preserve cpu features across upgrades, they can't depend on the default. -- error compiling committee.c: too many arguments to function