qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] Add VMX cpuid feature to qemu64
Date: Wed, 05 Jan 2011 11:06:09 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]