Re: [PATCH 13/15] KVM: Add support for enabling capabilities per-vcpu

[Avi Kivity <avi@redhat.com>]

On 03/09/2010 03:01 PM, Alexander Graf wrote:
> 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.
>    

If KVM_CAP_ENABLE_CAP is present, it means the KVM_ENABLE_CAP ioctl will 
not return ENOTTY (it may return EINVAL if wrong values are present).

ENOTTY means not implemented.  'Architectures: all' means implemented.

>>> +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.
>    

Ah, I see.  Well, that makes sense.  Please document it.

> 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.
>    

Okay, I agree.

-- 
error compiling committee.c: too many arguments to function