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
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
