From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NMkrg-0004z5-3t for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:12:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NMkrb-0004vx-8r for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:12:07 -0500 Received: from [199.232.76.173] (port=36816 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NMkrb-0004vs-5T for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:12:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22293) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NMkra-0001uY-Qr for qemu-devel@nongnu.org; Mon, 21 Dec 2009 11:12:03 -0500 Message-ID: <4B2F9E4F.1060907@redhat.com> Date: Mon, 21 Dec 2009 18:11:59 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <4B269D99.8080404@codemonkey.ws> <4B2DF334.6030208@redhat.com> <20091220155101.GB31257@redhat.com> <4B2E49E5.6050709@redhat.com> <20091220165612.GC31257@redhat.com> <20091220171822.GD31257@redhat.com> <4B2F581A.7030206@redhat.com> <20091221111856.GA6309@redhat.com> <0B948C77-7A15-4321-BA7C-059AA5FC3019@suse.de> <20091221113852.GB6309@redhat.com> <7AE7527C-B437-4807-8F26-515452C789AD@suse.de> <4B2F64A1.9050905@redhat.com> <4B2F7BF2.5090206@cisco.com> In-Reply-To: <4B2F7BF2.5090206@cisco.com> 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: "David S. Ahern" Cc: "Michael S.Tsirkin" , Alexander Graf , Gleb Natapov , qemu-devel@nongnu.org On 12/21/2009 03:45 PM, David S. Ahern wrote: > On 12/21/2009 05:05 AM, Avi Kivity wrote: > >> On 12/21/2009 01:45 PM, Alexander Graf wrote: >> >>> Well, we have two groups: >>> >>> 1) Casual user w/o management app >>> 2) Enterprise user w/ management app >>> >>> So I clearly belong to the first group. >>> >>> >> 3) Developer/power user who knows what he's about. >> >> You could simply add -cpu qemu64 for those guests that care about it. >> >> > 4) embedded virtualization where the use of a management app provides > little to no added benefit and everything has to be > "automated" (ie., no user). > > My point is there are other use cases besides data center deployments > (aka enterprise) and workstation (casual/power user). There are use > cases where virtualization is just yet another tool to achieve a product. > If there is no user, then a management app exists. It may be as simple as execing qemu from initrd, but there is still something that is not a user that can set the correct parameters. It is up to the author of this one-line management app to decide what the correct parameters are (-cpu host or some other cpu baseline that allows VM portability, if needed). -- error compiling committee.c: too many arguments to function