On 09.03.2010, at 13:56, Avi Kivity wrote:
> On 03/08/2010 08:03 PM, Alexander Graf wrote:
>> Some times we don't want all capabilities to be available to all
>> our vcpus. One example for that is the OSI interface, implemented
>> in the next patch.
>>
>> In order to have a generic mechanism in how to enable capabilities
>> individually, this patch introduces a new ioctl that can be used
>> for this purpose. That way features we don't want in all guests or
>> userspace configurations can just not be enabled and we're good.
>>
>>
>> diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt
>> index d170cb4..6a19ab6 100644
>> --- a/Documentation/kvm/api.txt
>> +++ b/Documentation/kvm/api.txt
>> @@ -749,6 +749,21 @@ Writes debug registers into the vcpu.
>> See KVM_GET_DEBUGREGS for the data structure. The flags field is unused
>> yet and must be cleared on entry.
>>
>> +4.34 KVM_ENABLE_CAP
>> +
>> +Capability: basic
>>
>
> Capability: basic means that the feature was present in 2.6.22. Otherwise you need to specify the KVM_CAP_ that presents this feature.
>
>> +Architectures: all
>>
>>
>
> But it's implemented for ppc only (other arches will get ENOTTY).
That was the whole idea behind it. if it fails it fails. Nothing we can do about it. If it succeeds - great.
>
>> +Not all extensions are enabled by default. Using this ioctl the application
>> +can enable an extension, making it available to the guest.
>> +
>> +On systems that do not support this ioctl, it always fails. On systems that
>> +do support it, it only works for extensions that are supported for enablement.
>> +As of writing this the only enablement enabled extenion is KVM_CAP_PPC_OSI.
>>
>
> That needs to be documented. It also needs to be discoverable separately - we can have a kernel with KVM_ENABLE_CAP but without KVM_CAP_PPC_OSI.
>
> btw, KVM_CAP_PPC_OSI conflicts with the KVM_CAP_ namespace. Please choose another namespace.
Well I figured it'd be slick to have capabilities get enabled or disabled. That's the whole idea behind making it generic. If I wanted a specific interface I'd go in and create an ioctl ENABLE_OSI_INTERFACE.
But this way the detection if a capability exists can be done using the existing CAP detection. It can then be enabled using ENABLE_CAP.
> Need to document the structure fields.
>
>>
>> /*
>> @@ -696,6 +705,8 @@ struct kvm_clock_data {
>> /* Available with KVM_CAP_DEBUGREGS */
>> #define KVM_GET_DEBUGREGS _IOR(KVMIO, 0xa1, struct kvm_debugregs)
>> #define KVM_SET_DEBUGREGS _IOW(KVMIO, 0xa2, struct kvm_debugregs)
>> +/* No need for CAP, because then it just always fails */
>> +#define KVM_ENABLE_CAP _IOW(KVMIO, 0xa3, struct kvm_enable_cap)
>>
> The CAPs are needed so you can discover what you have without running guests.
The whole point of this extension was to make CAPs not always enabled, but make them possibly enable on demand.
Alex--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
