Re: [RFC 0/5] Making KVM_GET_ONE_REG/KVM_SET_ONE_REG generic.

[Avi Kivity <avi@redhat.com>]

On 09/04/2012 04:59 PM, Alexander Graf wrote:
>> 
>> Not is you pack the pointer in a __u64, which is what we do to preserve
>> padding.  Then it is only s390 which needs extra love.
> 
> I doubt that anyone wants to run 31-bit user space on an s390x system. In fact, I wouldn't be surprised if exactly that case is broken already.

Arnd sent patches to fix it long ago.  Of course, something else may be
broken.

> 
>> 
>>>>> I don't think that is what makes the API hard
>>>>> to use.
>>>> 
>>>> What is it then?  I forgot what the original complaints/complainers were.
>>> 
>>> I have no idea, since I didn't hear the complaints.  But any non-fixed
>>> size array has issues in C; there's not much we can do about it.
>>> 
>>> x86 manages this fine for msrs, and I didn't have a problem using it for
>>> my test programs.  That's the limit of my experience, however.
>> 
>> Another option is to use the size parameter from the ioctl.  It just
>> sits there doing nothing.
> 
> It would require quite a bunch of changes throughout the stack. Even in user space, like strace...

I'm sure strace could cope.

I once had a proposal for extensible ioctl using the size parameter.
You want to extend an ioctl, the kernel zero-extends the input struct
for you, and truncates it on the way back.


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