[Intel-gfx] [PATCH v2 12/14] vfio: Add cdev for vfio_device
Joao Martins
joao.m.martins at oracle.com
Fri Feb 10 11:31:54 UTC 2023
Hey Yi,
On 06/02/2023 09:05, Yi Liu wrote:
> This allows user to directly open a vfio device w/o using the legacy
> container/group interface, as a prerequisite for supporting new iommu
> features like nested translation.
>
> The device fd opened in this manner doesn't have the capability to access
> the device as the fops open() doesn't open the device until the successful
> BIND_IOMMUFD which be added in next patch.
>
> With this patch, devices registered to vfio core have both group and device
> interface created.
>
> - group interface : /dev/vfio/$groupID
> - device interface: /dev/vfio/devices/vfioX (X is the minor number and
> is unique across devices)
>
> Given a vfio device the user can identify the matching vfioX by checking
> the sysfs path of the device. Take PCI device (0000:6a:01.0) for example,
> /sys/bus/pci/devices/0000\:6a\:01.0/vfio-dev/vfio0/dev contains the
> major:minor of the matching vfioX.
>
> Userspace then opens the /dev/vfio/devices/vfioX and checks with fstat
> that the major:minor matches.
>
> The vfio_device cdev logic in this patch:
> *) __vfio_register_dev() path ends up doing cdev_device_add() for each
> vfio_device;
> *) vfio_unregister_group_dev() path does cdev_device_del();
>
> Signed-off-by: Yi Liu <yi.l.liu at intel.com>
> Signed-off-by: Joao Martins <joao.m.martins at oracle.com>
Feel free to drop my SoB. The code I added/moved at the time was very very tiny
in the middle of rebasing various series ... solely to unblock folks that were
also testing when IOMMUFD going out of RFC. But they don't justify a second
author SoB (thanks regardless!)
Joao
More information about the Intel-gfx
mailing list