Re: RFC: KVM _CREATE_DEVICE considered harmful?

[Christian Borntraeger <borntraeger@de.ibm.com>]

dropping valgrind devel since its subscribers only...

On 16/10/13 15:06, Paolo Bonzini wrote:
> Il 16/10/2013 14:59, Christian Borntraeger ha scritto:
>>
>> Now, newer KVMs have the ability to create subdevices of a KVM guest (e.g. an in kernel
>> kvm interrupt controller) with the following ioctl:
>>
>> #define KVM_CREATE_DEVICE         _IOWR(KVMIO,  0xe0, struct kvm_create_device)
>>
>> qemu can then work on these devices with the ioctls 
>>
>> /* ioctls for fds returned by KVM_CREATE_DEVICE */
>> #define KVM_SET_DEVICE_ATTR       _IOW(KVMIO,  0xe1, struct kvm_device_attr)
>> #define KVM_GET_DEVICE_ATTR       _IOW(KVMIO,  0xe2, struct kvm_device_attr)
>> #define KVM_HAS_DEVICE_ATTR       _IOW(KVMIO,  0xe3, struct kvm_device_attr)
>>
>> struct kvm_device_attr {
>>         __u32   flags;          /* no flags currently defined */
>>         __u32   group;          /* device-defined */
>>         __u64   attr;           /* group-defined */
>>         __u64   addr;           /* userspace address of attr data */
>> };
> 
> Would it work to simply add an "__u64 size;" field to kvm_device_attr,
> that is filled on exit by KVM_GET/HAS_DEVICE_ADDR, and filled on entry
> to KVM_SET_DEVICE_ADDR?

That would work, but it would change the ioctl number of KVM_*_DEVICE_ADDR,
due to the changed size of struct kvm_device_attr. We would then need compat
 handlers in the kernel.

If we could encode it in the existing interface the impact would be smaller.
e.g. 

#define ATTR_ATTR_MASK 0xffffffffULL
#define ATTR_LEN_MASK 0xffffffff00000000ULL


    switch (attr->attr) {
---> 
    switch (attr->attr & ATTR_ATTR_MASK) {

Then we could keep the device model abstraction.

Just thinking here..better proposals are welcome

Christian