From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40865 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PaPJz-0003Jr-5M for qemu-devel@nongnu.org; Wed, 05 Jan 2011 04:06:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PaPJx-0008CK-Sp for qemu-devel@nongnu.org; Wed, 05 Jan 2011 04:06:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PaPJx-0008C8-Kn for qemu-devel@nongnu.org; Wed, 05 Jan 2011 04:06:17 -0500 Message-ID: <4D243481.2070005@redhat.com> Date: Wed, 05 Jan 2011 11:06:09 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add VMX cpuid feature to qemu64 References: <20110104150631.GA24238@fermat.math.technion.ac.il> <8153A341-349B-4A89-A737-DCF5187FFE23@suse.de> <20110104213907.GA6364@fermat.math.technion.ac.il> <50D01580-FB08-459A-84B9-7C8AA8190AFD@suse.de> <20110105081737.GA23681@fermat.math.technion.ac.il> <4D242C81.5000604@redhat.com> <20110105085047.GA24818@fermat.math.technion.ac.il> In-Reply-To: <20110105085047.GA24818@fermat.math.technion.ac.il> 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: Nadav Har'El Cc: Alexander Graf , qemu-devel@nongnu.org On 01/05/2011 10:50 AM, Nadav Har'El wrote: > On Wed, Jan 05, 2011, Avi Kivity wrote about "Re: [Qemu-devel] [PATCH] Add VMX cpuid feature to qemu64": > > The intent of kvm64/qemu64 is to provide some feature stability, so that > > when you run a guest with those cpu types, you get something expected. > > So adding to them isn't a good idea. > > > > I think we'd be fine with -cpu host and -cpu qemu64,+vmx enabling vmx > > support. > > Thanks. While this is ugly, I can certainly live with that (I've been telling > people to use "-cpu host" to run nested VMX, until you asked me why I don't > send a patch for qemu to fix that ;-)). Sorry about the confusion. > Though I wonder why there shouldn't be some sort of "default" CPU type which > just provides the maximum number of supported features, without attempting > to provide stable features. If someone wants a specific stable CPU he can > always use "-cpu core2duo" or even "-cpu qemu64", but shouldn't the default > (when KVM is enabled) be to just provide all the features that KVM can provide? That's -cpu host. People have been talking that it should be the default, and to a certain extent I agree. But changing defaults is dangerous business, it can break setups that rely on them. > Anyway, what is your opinion on which should be the default in KVM - qemu64 > or kvm64? If it's qemu64, does it make sense (as far as KVM is concerned) > that it lists the SVM capability, but not the VMX capability? IMO the emphasis on defaults is misplaced. Most people run virtual machines via a management tool, and we should focus on making it easy for management tool maintainers to do the right thing, by documenting our APIs and recommendations in the QEMU Management Tool Writer Guide. -- error compiling committee.c: too many arguments to function