Avi Kivity wrote:
> On 03/08/2010 03:56 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>
>>> On 03/08/2010 03:51 PM, Alexander Graf wrote:
>>>
>>>> Avi Kivity wrote:
>>>>
>>>>
>>>>> On 03/05/2010 06:50 PM, Alexander Graf wrote:
>>>>>
>>>>>
>>>>>> }
>>>>>> diff --git a/include/linux/kvm.h b/include/linux/kvm.h
>>>>>> index ce28767..c7ed3cb 100644
>>>>>> --- a/include/linux/kvm.h
>>>>>> +++ b/include/linux/kvm.h
>>>>>> @@ -400,6 +400,12 @@ struct kvm_ioeventfd {
>>>>>> __u8 pad[36];
>>>>>> };
>>>>>>
>>>>>> +/* for KVM_ENABLE_CAP */
>>>>>> +struct kvm_enable_cap {
>>>>>> + /* in */
>>>>>> + __u32 cap;
>>>>>>
>>>>>>
>>>>>>
>>>>> Reserve space here. Add a flags field and check it for zeros.
>>>>>
>>>>>
>>>> Flags? How about something like
>>>>
>>>> u64 args[4]
>>>>
>>>> That way the capability enabling code could decide what to do with the
>>>> arguments. We don't always only need flags I suppose?.
>>>>
>>>>
>>> If you interpret these as bit flags anyway, that would be redundant.
>>>
>>>
>> I think I just don't understand what you're trying to say with "flags".
>> For the OSI enabling we don't need any flags. For later additions we
>> don't know what we'll need.
>>
>
> When we have reserved fields which are later used for something new,
> the kernel needs a way to know if the reserved fields are known or not
> by userspace. One way to do this is to assume a value of zero means
> the field is unknown to usespace so ignore it. Another is to require
> userspace to set a bit in an already-known flags field, and only act
> on the new field if its bit was set. This has the advantage that the
> old kernel checks for unknown flags and errors out, improving forwards
> and backwards compatibility.
>
> I thought ->cap was already a bit field, so this isn't necessary, but
> if it isn't, then a flags field is helpful.
-> cap is the capability number. So you want something like:
struct kvm_enable_cap {
__u32 cap;
__u32 flags;
__u64 args[4];
__u8 pad[64];
};
And then check for flags == 0 in the ioctl handler? Flags could later on
define if the padding changed to a different position, adding new fields
in between args and pad?
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
