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

[Alexander Graf <agraf@suse.de>]

Avi Kivity wrote:
> On 03/08/2010 04:10 PM, Alexander Graf wrote:
>>
>>> 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?
>>    
>
> Exactly, we do so in several places.  Can be useful if, for example,
> some new capability comes with a resource count value.
>
> What's this thing anyway?  like cpuid bits for x86?

What thing? This ioctl or the OSI call?

The ioctl is a way to enable a feature on a per-vcpu basis. MOL overlays
the syscall interface with a hypercall interface, so a normal OS syscall
magically becomes a hypercall when magic constants get passed in r3 and r4.

Because for obvious reasons we don't want to enable that when not using
MOL, I figured I'd go in and have userspace decide if it wants to get a
hypercall exit or not. Qemu couldn't really do anything with it after
all. And while at it, I figured let's better make the interface generic.


Alex