From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NMOC6-0002Pn-6W
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:59:42 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NMOC1-0002Jc-CT
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:59:41 -0500
Received: from [199.232.76.173] (port=38284 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NMOC1-0002JB-5I
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:59:37 -0500
Received: from mx1.redhat.com ([209.132.183.28]:1025)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NMOC0-0004kP-Is
	for qemu-devel@nongnu.org; Sun, 20 Dec 2009 10:59:36 -0500
Message-ID: <4B2E49E5.6050709@redhat.com>
Date: Sun, 20 Dec 2009 17:59:33 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
References: <20091214193541.GA6150@redhat.com> <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>
In-Reply-To: <20091220155101.GB31257@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>, qemu-devel@nongnu.org

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).

-- 
error compiling committee.c: too many arguments to function