On Sat, Apr 17, 2010 at 09:58:26PM +0300, Avi Kivity wrote:
On 04/15/2010 09:37 PM, Glauber Costa wrote:Right now, we don't have any mechanism to disable, say, kvmclock cpuid bit
Since we're changing the msrs kvmclock uses, we have to communicateHm. We need to update userspace anyway, since we don't like turning
that to the guest, through cpuid. We can add a new KVM_CAP to the
hypervisor, and then patch userspace to recognize it.
And if we ever add a new cpuid bit in the future, we have to do that again,
which create some complexity and delay in feature adoption.
Instead, what I'm proposing in this patch is a new capability, called
KVM_CAP_X86_CPUID_FEATURE_LIST, that returns the current feature list
currently supported by the hypervisor. If we ever want to add or remove
some feature, we only need to tweak into the HV, leaving userspace untouched.
features on unconditionally (it breaks live migration into an older
kernel).
at userspace.
But let's suppose we have: What's the difference between disabling
it in the way it is now, and disabling it with the method I am proposing?
All this ioctl say is: "Those are the current supported stuff in this HV".
It does not mandate userspace to expose all of this to the guest. It just saves
us from the job of creating yet another CAP for every bit we plan on including.
If we want to be conservative, we can keep everything but the things we know
already disabled, in userspace.