From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NMivL-0006pI-OR
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 09:07:47 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NMivG-0006nm-OY
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 09:07:46 -0500
Received: from [199.232.76.173] (port=35437 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NMivG-0006nj-Ju
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 09:07:42 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148]:27405)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16)
	(Exim 4.60) (envelope-from <daahern@cisco.com>) id 1NMivF-00051M-Qp
	for qemu-devel@nongnu.org; Mon, 21 Dec 2009 09:07:42 -0500
Message-ID: <4B2F8114.50200@cisco.com>
Date: Mon, 21 Dec 2009 07:07:16 -0700
From: "David S. Ahern" <daahern@cisco.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
References: <20091220165612.GC31257@redhat.com>
	<C9DA6F14-719C-49C2-A9B5-C74A64603026@suse.de>
	<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>
	<20091221135114.GA7956@redhat.com>
In-Reply-To: <20091221135114.GA7956@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
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: qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>, Gleb Natapov <gleb@redhat.com>, Alexander Graf <agraf@suse.de>


On 12/21/2009 06:51 AM, Michael S. Tsirkin wrote:
> On Mon, Dec 21, 2009 at 06:45:22AM -0700, 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.
>>
>> David
> 
> Yes, but unless someone runs qemu directly, default value for any flag
> does not matter much.
> 

That's what I was getting at - "direct" invocation of qemu in an
automated sense without a libvirt layer. Defaults that do the right
thing on the host would be nice, with tweaking from the defaults only if
something extra is wanted.

David