Il 27/05/2013 16:26, Alexey Kardashevskiy ha scritto:
> On 05/27/2013 08:23 PM, Paolo Bonzini wrote:
>> Il 25/05/2013 04:45, David Gibson ha scritto:
>>>>> + case KVM_CREATE_SPAPR_TCE_IOMMU: {
>>>>> + struct kvm_create_spapr_tce_iommu create_tce_iommu;
>>>>> + struct kvm *kvm = filp->private_data;
>>>>> +
>>>>> + r = -EFAULT;
>>>>> + if (copy_from_user(&create_tce_iommu, argp,
>>>>> + sizeof(create_tce_iommu)))
>>>>> + goto out;
>>>>> + r = kvm_vm_ioctl_create_spapr_tce_iommu(kvm,
>>>>> &create_tce_iommu);
>>>>> + goto out;
>>>>> + }
>>
>> Would it make sense to make this the only interface for creating TCEs?
>> That is, pass both a window_size and an IOMMU group id (or e.g. -1 for
>> no hardware IOMMU usage), and have a single ioctl for both cases?
>> There's some duplicated code between kvm_vm_ioctl_create_spapr_tce and
>> kvm_vm_ioctl_create_spapr_tce_iommu.
>
> Just few bits. Is there really much sense in making one function from those
> two? I tried, looked a bit messy.
Cannot really tell without the userspace bits. But ioctl proliferation
is what the device and one_reg APIs were supposed to avoid...
>> KVM_CREATE_SPAPR_TCE could stay for backwards-compatibility, or you
>> could just use a new capability and drop the old ioctl.
>
> The old capability+ioctl already exist for quite a while and few QEMU
> versions supporting it were released so we do not want just drop it. So
> then what is the benefit of having a new interface with support of both types?
>
>> I'm not sure
>> whether you're already considering the ABI to be stable for kvmppc.
>
> Is any bit of KVM using it? Cannot see from Documentation/ABI.
I mean the userspace ABI (ioctls).
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
