RE: [PATCH v3 15/15] vfio: Add struct device to vfio_device
> From: Jason Gunthorpe > Sent: Thursday, September 22, 2022 12:10 AM > > On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote: > > > From: Alex Williamson > > > Sent: Wednesday, September 21, 2022 4:27 AM > > > > > > On Fri, 9 Sep 2022 18:22:47 +0800 > > > Kevin Tian wrote: > > > > > > > From: Yi Liu > > > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > > sysfs path of the parent, indicating the device is bound to a vfio > > > > driver, e.g.: > > > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > > device-oriented uAPI. > > > > > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > > > /proc/devices. > > > > > > What's the risk/reward here, is this just more aesthetically pleasing > > > symmetry vs 'vfio-dev'? The char major number to name association in > > > /proc/devices seems pretty obscure, but what due diligence have we > done > > > to make sure this doesn't break anyone? Thanks, > > > > I'm not sure whether the content of /proc/devices is considered as ABI. > > > > @Jason? > > Ah, I've forgotten why we got here - didn't we have a naming conflict > with the new stuff that is being introduced? No, we don't have. There is no new char dev introduced in this series. Later when device cdev is added a new device major will be allocated for 'vfio-dev'. It's at that time renaming existing 'vfio' to 'vfio-group' is probably clearer, which is what I understood from your earlier suggestion. > > ABI wise it is not a problem unless there is a real user, I'm not > aware of anything scanning /proc, that has been obsoleted by sysfs a > long time ago. > This is a good news.
Re: [PATCH v3 15/15] vfio: Add struct device to vfio_device
On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote: > > From: Alex Williamson > > Sent: Wednesday, September 21, 2022 4:27 AM > > > > On Fri, 9 Sep 2022 18:22:47 +0800 > > Kevin Tian wrote: > > > > > From: Yi Liu > > > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > > sysfs path of the parent, indicating the device is bound to a vfio > > > driver, e.g.: > > > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > > > It is also a preparatory step toward adding cdev for supporting future > > > device-oriented uAPI. > > > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > > /proc/devices. > > > > What's the risk/reward here, is this just more aesthetically pleasing > > symmetry vs 'vfio-dev'? The char major number to name association in > > /proc/devices seems pretty obscure, but what due diligence have we done > > to make sure this doesn't break anyone? Thanks, > > I'm not sure whether the content of /proc/devices is considered as ABI. > > @Jason? Ah, I've forgotten why we got here - didn't we have a naming conflict with the new stuff that is being introduced? ABI wise it is not a problem unless there is a real user, I'm not aware of anything scanning /proc, that has been obsoleted by sysfs a long time ago. Jason
RE: [PATCH v3 15/15] vfio: Add struct device to vfio_device
> From: Alex Williamson > Sent: Wednesday, September 21, 2022 4:27 AM > > On Fri, 9 Sep 2022 18:22:47 +0800 > Kevin Tian wrote: > > > From: Yi Liu > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > sysfs path of the parent, indicating the device is bound to a vfio > > driver, e.g.: > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > It is also a preparatory step toward adding cdev for supporting future > > device-oriented uAPI. > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > /proc/devices. > > What's the risk/reward here, is this just more aesthetically pleasing > symmetry vs 'vfio-dev'? The char major number to name association in > /proc/devices seems pretty obscure, but what due diligence have we done > to make sure this doesn't break anyone? Thanks, > I'm not sure whether the content of /proc/devices is considered as ABI. @Jason? But to be safe I can remove this change in next version. If it's the right thing to do such change after discussion then it can be done in a separate patch after.
Re: [PATCH v3 15/15] vfio: Add struct device to vfio_device
On Fri, 9 Sep 2022 18:22:47 +0800 Kevin Tian wrote: > From: Yi Liu > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > sysfs path of the parent, indicating the device is bound to a vfio > driver, e.g.: > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > It is also a preparatory step toward adding cdev for supporting future > device-oriented uAPI. > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > /proc/devices. What's the risk/reward here, is this just more aesthetically pleasing symmetry vs 'vfio-dev'? The char major number to name association in /proc/devices seems pretty obscure, but what due diligence have we done to make sure this doesn't break anyone? Thanks, Alex
[PATCH v3 15/15] vfio: Add struct device to vfio_device
From: Yi Liu
and replace kref. With it a 'vfio-dev/vfioX' node is created under the
sysfs path of the parent, indicating the device is bound to a vfio
driver, e.g.:
/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
It is also a preparatory step toward adding cdev for supporting future
device-oriented uAPI.
Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
Also take this chance to rename chardev 'vfio' to 'vfio-group' in
/proc/devices.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
.../ABI/testing/sysfs-devices-vfio-dev| 8 +++
MAINTAINERS | 1 +
drivers/vfio/vfio_main.c | 67 +++
include/linux/vfio.h | 6 +-
4 files changed, 67 insertions(+), 15 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-vfio-dev
diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev
b/Documentation/ABI/testing/sysfs-devices-vfio-dev
new file mode 100644
index ..e21424fd9666
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev
@@ -0,0 +1,8 @@
+What: /sys/...//vfio-dev/vfioX/
+Date: September 2022
+Contact:Yi Liu
+Description:
+This directory is created when the device is bound to a
+vfio driver. The layout under this directory matches what
+exists for a standard 'struct device'. 'X' is a unique
+index marking this device in vfio.
diff --git a/MAINTAINERS b/MAINTAINERS
index d30f26e07cd3..02c8f11b1c17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21312,6 +21312,7 @@ R: Cornelia Huck
L: k...@vger.kernel.org
S: Maintained
T: git git://github.com/awilliam/linux-vfio.git
+F: Documentation/ABI/testing/sysfs-devices-vfio-dev
F: Documentation/driver-api/vfio.rst
F: drivers/vfio/
F: include/linux/vfio.h
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 37cbd10f3faf..cd23d35c878c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -49,6 +49,8 @@ static struct vfio {
struct mutexgroup_lock; /* locks group_list */
struct ida group_ida;
dev_t group_devt;
+ struct class*device_class;
+ struct ida device_ida;
} vfio;
struct vfio_iommu_driver {
@@ -485,12 +487,13 @@ static struct vfio_device *vfio_group_get_device(struct
vfio_group *group,
* VFIO driver API
*/
/* Release helper called by vfio_put_device() */
-void vfio_device_release(struct kref *kref)
+static void vfio_device_release(struct device *dev)
{
struct vfio_device *device =
- container_of(kref, struct vfio_device, kref);
+ container_of(dev, struct vfio_device, device);
vfio_release_device_set(device);
+ ida_free(&vfio.device_ida, device->index);
/*
* kvfree() cannot be done here due to a life cycle mess in
@@ -500,7 +503,6 @@ void vfio_device_release(struct kref *kref)
*/
device->ops->release(device);
}
-EXPORT_SYMBOL_GPL(vfio_device_release);
/*
* Alloc and initialize vfio_device so it can be registered to vfio
@@ -548,6 +550,13 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
{
int ret;
+ ret = ida_alloc_max(&vfio.device_ida, MINORMASK, GFP_KERNEL);
+ if (ret < 0) {
+ dev_dbg(dev, "Error to alloc index\n");
+ return ret;
+ }
+
+ device->index = ret;
init_completion(&device->comp);
device->dev = dev;
device->ops = ops;
@@ -558,11 +567,15 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
goto out_uninit;
}
- kref_init(&device->kref);
+ device_initialize(&device->device);
+ device->device.release = vfio_device_release;
+ device->device.class = vfio.device_class;
+ device->device.parent = device->dev;
return 0;
out_uninit:
vfio_release_device_set(device);
+ ida_free(&vfio.device_ida, device->index);
return ret;
}
EXPORT_SYMBOL_GPL(vfio_init_device);
@@ -659,6 +672,7 @@ static int __vfio_register_dev(struct vfio_device *device,
struct vfio_group *group)
{
struct vfio_device *existing_device;
+ int ret;
if (IS_ERR(group))
return PTR_ERR(group);
@@ -675,16 +689,21 @@ static int __vfio_register_dev(struct vfio_device *device,
dev_WARN(device->dev, "Device already exists on group %d\n",
iommu_group_id(group->iommu_group));
vfio_device_put_registration(existing_device);
- if (group->type == VFIO_NO_IOMMU ||
- group->type == VFIO_EMULATED_IOMMU)
