From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMP7a-0002eE-6L for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:59:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMP7U-0002dR-C8 for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:59:04 -0500 Received: from [199.232.76.173] (port=49796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMP7U-0002dO-6g for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:59:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57948) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMP7T-0000Rr-NO for qemu-devel@nongnu.org; Sun, 20 Dec 2009 11:59:00 -0500 Date: Sun, 20 Dec 2009 18:56:12 +0200 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm Message-ID: <20091220165612.GC31257@redhat.com> References: <4B269596.1050103@codemonkey.ws> <20091214194432.GC6150@redhat.com> <4B2698A9.9090107@codemonkey.ws> <20091214200002.GA27769@redhat.com> <4B2699BB.1090302@codemonkey.ws> <20091214201049.GD6150@redhat.com> <4B269D99.8080404@codemonkey.ws> <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B2E49E5.6050709@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Gleb Natapov , qemu-devel@nongnu.org On Sun, Dec 20, 2009 at 05:59:33PM +0200, Avi Kivity wrote: > On 12/20/2009 05:51 PM, Michael S. Tsirkin wrote: >> >>> Maybe we should make -cpu host the default. That will give the best >>> performance for casual users, more testing for newer features, and will >>> force management apps to treat migration much more seriously. The >>> downside is that casual users upgrading their machines might experience >>> issues with Windows. Feature compatibility is not just about migration. >>> >> This seems very aggressive. Can't we whitelist features that we know >> about? Further, doesn't KVM already do this? >> >> > > It does, but without -cpuid host you're stuck with qemu64 (kvm.ko > doesn't add features userspace didn't request). Hmm, then, shouldn't either kvm or qemu mask features that we do not emulate well enough to make windows not crash? > -- > error compiling committee.c: too many arguments to function