Re: [Qemu-devel] [PATCH] Add VMX cpuid feature to qemu64

[Avi Kivity <avi@redhat.com>]

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