qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 06/12] vfio/pci: Introduce vfio_[attach/detach]_device


From: Eric Auger
Subject: Re: [PATCH v2 06/12] vfio/pci: Introduce vfio_[attach/detach]_device
Date: Wed, 27 Sep 2023 12:02:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0


On 9/27/23 11:58, Duan, Zhenzhong wrote:
>
>> -----Original Message-----
>> From: Eric Auger <eric.auger@redhat.com>
>> Sent: Wednesday, September 27, 2023 3:36 PM
>> Subject: Re: [PATCH v2 06/12] vfio/pci: Introduce vfio_[attach/detach]_device
>>
>> Hi Zhenzhong,
>>
>> On 9/26/23 13:32, Zhenzhong Duan wrote:
>>> From: Eric Auger <eric.auger@redhat.com>
>>>
>>> We want the VFIO devices to be able to use two different
>>> IOMMU backends, the legacy VFIO one and the new iommufd one.
>>>
>>> Introduce vfio_[attach/detach]_device which aim at hiding the
>>> underlying IOMMU backend (IOCTLs, datatypes, ...).
>>>
>>> Once vfio_attach_device completes, the device is attached
>>> to a security context and its fd can be used. Conversely
>>> When vfio_detach_device completes, the device has been
>>> detached from the security context.
>>>
>>> At the moment only the implementation based on the legacy
>>> container/group exists. Let's use it from the vfio-pci device.
>>> Subsequent patches will handle other devices.
>> you may add: no functional change intended
> Will do.
>
>>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>> Signed-off-by: Yi Liu <yi.l.liu@intel.com>
>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>> ---
>>>  include/hw/vfio/vfio-common.h |  3 ++
>>>  hw/vfio/common.c              | 68 +++++++++++++++++++++++++++++++++++
>>>  hw/vfio/pci.c                 | 50 +++-----------------------
>>>  hw/vfio/trace-events          |  2 +-
>>>  4 files changed, 77 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>>> index c4e7c3b4a7..12fbfbc37d 100644
>>> --- a/include/hw/vfio/vfio-common.h
>>> +++ b/include/hw/vfio/vfio-common.h
>>> @@ -225,6 +225,9 @@ void vfio_put_group(VFIOGroup *group);
>>>  struct vfio_device_info *vfio_get_device_info(int fd);
>>>  int vfio_get_device(VFIOGroup *group, const char *name,
>>>                      VFIODevice *vbasedev, Error **errp);
>>> +int vfio_attach_device(char *name, VFIODevice *vbasedev,
>>> +                       AddressSpace *as, Error **errp);
>>> +void vfio_detach_device(VFIODevice *vbasedev);
>>>
>>>  int vfio_kvm_device_add_fd(int fd, Error **errp);
>>>  int vfio_kvm_device_del_fd(int fd, Error **errp);
>>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>>> index 959b1362bb..7f3798b152 100644
>>> --- a/hw/vfio/common.c
>>> +++ b/hw/vfio/common.c
>>> @@ -2611,3 +2611,71 @@ int vfio_eeh_as_op(AddressSpace *as, uint32_t op)
>>>      }
>>>      return vfio_eeh_container_op(container, op);
>>>  }
>>> +
>>> +static int vfio_device_groupid(VFIODevice *vbasedev, Error **errp)
>>> +{
>>> +    char *tmp, group_path[PATH_MAX], *group_name;
>>> +    int ret, groupid;
>>> +    ssize_t len;
>>> +
>>> +    tmp = g_strdup_printf("%s/iommu_group", vbasedev->sysfsdev);
>>> +    len = readlink(tmp, group_path, sizeof(group_path));
>>> +    g_free(tmp);
>>> +
>>> +    if (len <= 0 || len >= sizeof(group_path)) {
>>> +        ret = len < 0 ? -errno : -ENAMETOOLONG;
>>> +        error_setg_errno(errp, -ret, "no iommu_group found");
>>> +        return ret;
>>> +    }
>>> +
>>> +    group_path[len] = 0;
>>> +
>>> +    group_name = basename(group_path);
>>> +    if (sscanf(group_name, "%d", &groupid) != 1) {
>>> +        error_setg_errno(errp, errno, "failed to read %s", group_path);
>>> +        return -errno;
>>> +    }
>>> +    return groupid;
>>> +}
>>> +
>>> +int vfio_attach_device(char *name, VFIODevice *vbasedev,
>>> +                       AddressSpace *as, Error **errp)
>>> +{
>>> +    int groupid = vfio_device_groupid(vbasedev, errp);
>>> +    VFIODevice *vbasedev_iter;
>>> +    VFIOGroup *group;
>>> +    int ret;
>>> +
>>> +    if (groupid < 0) {
>>> +        return groupid;
>>> +    }
>>> +
>>> +    trace_vfio_attach_device(vbasedev->name, groupid);
>> hum looking at that again, I was confused by the fact we passed the name
>> arg in
>>
>> vfio_attach_device() whereas vbasedev->name was already filled. Looking at 
>> pci
>> vfio_realize()
>> both are sometimes different
>>
>>    if (!qemu_uuid_is_null(&vdev->vf_token)) {
>>        qemu_uuid_unparse(&vdev->vf_token, uuid);
>>        name = g_strdup_printf("%s vf_token=%s", vbasedev->name, uuid);
>>    } else {
>>        name = g_strdup(vbasedev->name);
>>    }
>> This may be worth a doc comment.
> Yes, agree this is confusing. Just want to ask about the doc comment?
> Should I create a vfio doc or just a small comment on call site of 
> vfio_attach_device()?
I meant a comment associated to this vfio_attach_device helper
indicating what is the purpose/semantic of name versus vbasedev->name

See my last comment on the ccw conversion which is even more confusing now to 
me :-(

Eric

>
> Thanks
> Zhenzhong




reply via email to

[Prev in Thread] Current Thread [Next in Thread]