| Message ID | 20230213151348.56451-1-yi.l.liu@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add vfio_device cdev for iommufd support | expand |
On Mon, 13 Feb 2023 07:13:33 -0800 Yi Liu <yi.l.liu@intel.com> wrote: > Existing VFIO provides group-centric user APIs for userspace. Userspace > opens the /dev/vfio/$group_id first before getting device fd and hence > getting access to device. This is not the desired model for iommufd. Per > the conclusion of community discussion[1], iommufd provides device-centric > kAPIs and requires its consumer (like VFIO) to be device-centric user > APIs. Such user APIs are used to associate device with iommufd and also > the I/O address spaces managed by the iommufd. > > This series first introduces a per device file structure to be prepared > for further enhancement and refactors the kvm-vfio code to be prepared > for accepting device file from userspace. Then refactors the vfio to be > able to handle iommufd binding. This refactor includes the mechanism of > blocking device access before iommufd bind, making vfio_device_open() be > exclusive between the group path and the cdev path. Eventually, adds the > cdev support for vfio device, and makes group infrastructure optional as > it is not needed when vfio device cdev is compiled. > > This is also a prerequisite for iommu nesting for vfio device[2]. > > The complete code can be found in below branch, simple test done with the > legacy group path and the cdev path. Draft QEMU branch can be found at[3] > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) Even using your branch[1], it seems like this has not been tested except with cdev support enabled: /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function ‘vfio_device_add’: /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: ‘struct vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? 253 | ret = cdev_device_add(&device->cdev, &device->device); | ^~~~ | dev /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function ‘vfio_device_del’: /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: ‘struct vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? 262 | cdev_device_del(&device->cdev, &device->device); | ^~~~ | dev Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much sense to me, it seems entirely redundant to VFIO_GROUP. I think it's too late for v6.3 already, but given this needs at least one more spin, let's set expectations of this being v6.4 material. Thanks, Alex [1] 98491da60ae1 cover-letter: Add vfio_device cdev for iommufd support
On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > I think it's too late for v6.3 already, but given this needs at least > one more spin, let's set expectations of this being v6.4 material. Thanks, Please let's continue to try to get this finished during the merge window, all the other series depend on it. We can manage it with a shared branch again.. Thanks, Jason
> From: Alex Williamson <alex.williamson@redhat.com> > Sent: Tuesday, February 14, 2023 3:47 AM > > On Mon, 13 Feb 2023 07:13:33 -0800 > Yi Liu <yi.l.liu@intel.com> wrote: > > > Existing VFIO provides group-centric user APIs for userspace. Userspace > > opens the /dev/vfio/$group_id first before getting device fd and hence > > getting access to device. This is not the desired model for iommufd. Per > > the conclusion of community discussion[1], iommufd provides device- > centric > > kAPIs and requires its consumer (like VFIO) to be device-centric user > > APIs. Such user APIs are used to associate device with iommufd and also > > the I/O address spaces managed by the iommufd. > > > > This series first introduces a per device file structure to be prepared > > for further enhancement and refactors the kvm-vfio code to be prepared > > for accepting device file from userspace. Then refactors the vfio to be > > able to handle iommufd binding. This refactor includes the mechanism of > > blocking device access before iommufd bind, making vfio_device_open() > be > > exclusive between the group path and the cdev path. Eventually, adds the > > cdev support for vfio device, and makes group infrastructure optional as > > it is not needed when vfio device cdev is compiled. > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > The complete code can be found in below branch, simple test done with > the > > legacy group path and the cdev path. Draft QEMU branch can be found > at[3] > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > Even using your branch[1], it seems like this has not been tested > except with cdev support enabled: > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > ‘vfio_device_add’: > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: ‘struct > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > 253 | ret = cdev_device_add(&device->cdev, &device->device); > | ^~~~ > | dev > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > ‘vfio_device_del’: > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: ‘struct > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > 262 | cdev_device_del(&device->cdev, &device->device); > | ^~~~ > | dev Sorry for it. It is due to the cdev definition is under "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for readability, it would be better to always define cdev in vfio_device, and keep the using of cdev in code. How about your taste? > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > sense to me, it seems entirely redundant to VFIO_GROUP. The intention is to make the group code compiling match existing case. Currently, if VFIO is configured, group code is by default compiled. So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option for user. User needs to explicitly config VFIO_GROUP if VFIO_DEVICE_CDEV==y. If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or not, the group code shall be compiled. Regards, Yi Liu
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Tuesday, February 14, 2023 7:22 AM > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > I think it's too late for v6.3 already, but given this needs at least > > one more spin, let's set expectations of this being v6.4 material. Thanks, > > Please let's continue to try to get this finished during the merge > window, all the other series depend on it. We can manage it with a > shared branch again.. > Sure. I've updated the below branch to address Kevin's latest remarks. Fixed the compiling failure reported by Alex as well. https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 Regards, Yi Liu
On Tue, 14 Feb 2023 01:55:17 +0000 "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > From: Alex Williamson <alex.williamson@redhat.com> > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > On Mon, 13 Feb 2023 07:13:33 -0800 > > Yi Liu <yi.l.liu@intel.com> wrote: > > > > > Existing VFIO provides group-centric user APIs for userspace. Userspace > > > opens the /dev/vfio/$group_id first before getting device fd and hence > > > getting access to device. This is not the desired model for iommufd. Per > > > the conclusion of community discussion[1], iommufd provides device- > > centric > > > kAPIs and requires its consumer (like VFIO) to be device-centric user > > > APIs. Such user APIs are used to associate device with iommufd and also > > > the I/O address spaces managed by the iommufd. > > > > > > This series first introduces a per device file structure to be prepared > > > for further enhancement and refactors the kvm-vfio code to be prepared > > > for accepting device file from userspace. Then refactors the vfio to be > > > able to handle iommufd binding. This refactor includes the mechanism of > > > blocking device access before iommufd bind, making vfio_device_open() > > be > > > exclusive between the group path and the cdev path. Eventually, adds the > > > cdev support for vfio device, and makes group infrastructure optional as > > > it is not needed when vfio device cdev is compiled. > > > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > > > The complete code can be found in below branch, simple test done with > > the > > > legacy group path and the cdev path. Draft QEMU branch can be found > > at[3] > > > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > Even using your branch[1], it seems like this has not been tested > > except with cdev support enabled: > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > ‘vfio_device_add’: > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: ‘struct > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > 253 | ret = cdev_device_add(&device->cdev, &device->device); > > | ^~~~ > > | dev > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > ‘vfio_device_del’: > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: ‘struct > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > 262 | cdev_device_del(&device->cdev, &device->device); > > | ^~~~ > > | dev > > Sorry for it. It is due to the cdev definition is under > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > readability, it would be better to always define cdev in vfio_device, > and keep the using of cdev in code. How about your taste? It seems necessary unless we want to litter the code with #ifdefs. > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > > sense to me, it seems entirely redundant to VFIO_GROUP. > > The intention is to make the group code compiling match existing case. > Currently, if VFIO is configured, group code is by default compiled. > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option > for user. User needs to explicitly config VFIO_GROUP if VFIO_DEVICE_CDEV==y. > If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or not, > the group code shall be compiled. I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant and unnecessary. Also, Kconfig should not allow a configuration without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. Thanks, Alex
On Tue, 14 Feb 2023 15:15:28 +0000 "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > From: Jason Gunthorpe <jgg@nvidia.com> > > Sent: Tuesday, February 14, 2023 7:22 AM > > > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > > > I think it's too late for v6.3 already, but given this needs at least > > > one more spin, let's set expectations of this being v6.4 material. Thanks, > > > > Please let's continue to try to get this finished during the merge > > window, all the other series depend on it. We can manage it with a > > shared branch again.. > > > > Sure. I've updated the below branch to address Kevin's latest remarks. > Fixed the compiling failure reported by Alex as well. > > https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 Sorry, I think this is an abuse of the merge window. We have a new uAPI proposal that's barely a week old and has no reviews or acks other than Yi's, we have build configuration issues which suggests a lack of testing, we're finding subtle implications to other existing uAPIs, and nobody seems to have finished an upstream review, including me. Code for the merge window should already be in maintainer trees by now, the merge window should be for integration. There are a lot of things in flight and many more review comments coming in than we should see for this to be a v6.3 candidate. Thanks, Alex
On Tue, Feb 14, 2023 at 08:54:19AM -0700, Alex Williamson wrote: > On Tue, 14 Feb 2023 15:15:28 +0000 > "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > > > From: Jason Gunthorpe <jgg@nvidia.com> > > > Sent: Tuesday, February 14, 2023 7:22 AM > > > > > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > > > > > I think it's too late for v6.3 already, but given this needs at least > > > > one more spin, let's set expectations of this being v6.4 material. Thanks, > > > > > > Please let's continue to try to get this finished during the merge > > > window, all the other series depend on it. We can manage it with a > > > shared branch again.. > > > > > > > Sure. I've updated the below branch to address Kevin's latest remarks. > > Fixed the compiling failure reported by Alex as well. > > > > https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 > > > Sorry, I think this is an abuse of the merge window. We have a new uAPI > proposal that's barely a week old and has no reviews or acks other than > Yi's, we have build configuration issues which suggests a lack of > testing, we're finding subtle implications to other existing uAPIs, and > nobody seems to have finished an upstream review, including me. > > Code for the merge window should already be in maintainer trees by now, > the merge window should be for integration. There are a lot of things > in flight and many more review comments coming in than we should see > for this to be a v6.3 candidate. Thanks, Sorry, I ment that we continue to review and try to get this ready for rc1, not abuse the merge window. Obviously this cycle is lost. Jason
> From: Alex Williamson <alex.williamson@redhat.com> > Sent: Tuesday, February 14, 2023 11:47 PM > > On Tue, 14 Feb 2023 01:55:17 +0000 > "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > > > On Mon, 13 Feb 2023 07:13:33 -0800 > > > Yi Liu <yi.l.liu@intel.com> wrote: > > > > > > > Existing VFIO provides group-centric user APIs for userspace. > Userspace > > > > opens the /dev/vfio/$group_id first before getting device fd and > hence > > > > getting access to device. This is not the desired model for iommufd. > Per > > > > the conclusion of community discussion[1], iommufd provides device- > > > centric > > > > kAPIs and requires its consumer (like VFIO) to be device-centric user > > > > APIs. Such user APIs are used to associate device with iommufd and > also > > > > the I/O address spaces managed by the iommufd. > > > > > > > > This series first introduces a per device file structure to be prepared > > > > for further enhancement and refactors the kvm-vfio code to be > prepared > > > > for accepting device file from userspace. Then refactors the vfio to be > > > > able to handle iommufd binding. This refactor includes the mechanism > of > > > > blocking device access before iommufd bind, making > vfio_device_open() > > > be > > > > exclusive between the group path and the cdev path. Eventually, adds > the > > > > cdev support for vfio device, and makes group infrastructure optional > as > > > > it is not needed when vfio device cdev is compiled. > > > > > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > > > > > The complete code can be found in below branch, simple test done > with > > > the > > > > legacy group path and the cdev path. Draft QEMU branch can be found > > > at[3] > > > > > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > > > Even using your branch[1], it seems like this has not been tested > > > except with cdev support enabled: > > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > ‘vfio_device_add’: > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: > ‘struct > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > 253 | ret = cdev_device_add(&device->cdev, &device->device); > > > | ^~~~ > > > | dev > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > ‘vfio_device_del’: > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: > ‘struct > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > 262 | cdev_device_del(&device->cdev, &device->device); > > > | ^~~~ > > > | dev > > > > Sorry for it. It is due to the cdev definition is under > > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > > readability, it would be better to always define cdev in vfio_device, > > and keep the using of cdev in code. How about your taste? > > It seems necessary unless we want to litter the code with #ifdefs. I've moved it to the header file and call cdev_device_add() under #if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". > > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > > > sense to me, it seems entirely redundant to VFIO_GROUP. > > > > The intention is to make the group code compiling match existing case. > > Currently, if VFIO is configured, group code is by default compiled. > > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option > > for user. User needs to explicitly config VFIO_GROUP if VFIO_DEVICE_CDEV==y. > > If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or > > not, the group code shall be compiled. > > I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant > and unnecessary. Also, Kconfig should not allow a configuration > without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not > functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, > but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. How about below? As Jason's remark on patch 0003, cdev is not available for SPAPR. diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index 0476abf154f2..96535adc2301 100644 --- a/drivers/vfio/Kconfig +++ b/drivers/vfio/Kconfig @@ -4,6 +4,8 @@ menuconfig VFIO select IOMMU_API depends on IOMMUFD || !IOMMUFD select INTERVAL_TREE + select VFIO_GROUP if SPAPR_TCE_IOMMU + select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM || ARM64) select VFIO_CONTAINER if IOMMUFD=n help VFIO provides a framework for secure userspace device drivers. @@ -14,7 +16,8 @@ menuconfig VFIO if VFIO config VFIO_DEVICE_CDEV bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" depends on IOMMUFD && (X86 || S390 || ARM || ARM64) + default !VFIO_GROUP help The VFIO device cdev is another way for userspace to get device access. Userspace gets device fd by opening device cdev under @@ -23,9 +26,21 @@ config VFIO_DEVICE_CDEV If you don't know what to do here, say N. +config VFIO_GROUP + bool "Support for the VFIO group /dev/vfio/$group_id" + default y + help + VFIO group is legacy interface for userspace. As the introduction + of VFIO device cdev interface, this can be N. For now, before + userspace applications are fully converted to new vfio device cdev + interface, this should be Y. + + If you don't know what to do here, say Y. + config VFIO_CONTAINER bool "Support for the VFIO container /dev/vfio/vfio" select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64) + depends on VFIO_GROUP default y help The VFIO container is the classic interface to VFIO for establishing Regards, Yi Liu
On Wed, 15 Feb 2023 07:54:31 +0000 "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > From: Alex Williamson <alex.williamson@redhat.com> > > Sent: Tuesday, February 14, 2023 11:47 PM > > > > On Tue, 14 Feb 2023 01:55:17 +0000 > > "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > > > > > On Mon, 13 Feb 2023 07:13:33 -0800 > > > > Yi Liu <yi.l.liu@intel.com> wrote: > > > > > > > > > Existing VFIO provides group-centric user APIs for userspace. > > Userspace > > > > > opens the /dev/vfio/$group_id first before getting device fd and > > hence > > > > > getting access to device. This is not the desired model for iommufd. > > Per > > > > > the conclusion of community discussion[1], iommufd provides device- > > > > centric > > > > > kAPIs and requires its consumer (like VFIO) to be device-centric user > > > > > APIs. Such user APIs are used to associate device with iommufd and > > also > > > > > the I/O address spaces managed by the iommufd. > > > > > > > > > > This series first introduces a per device file structure to be prepared > > > > > for further enhancement and refactors the kvm-vfio code to be > > prepared > > > > > for accepting device file from userspace. Then refactors the vfio to be > > > > > able to handle iommufd binding. This refactor includes the mechanism > > of > > > > > blocking device access before iommufd bind, making > > vfio_device_open() > > > > be > > > > > exclusive between the group path and the cdev path. Eventually, adds > > the > > > > > cdev support for vfio device, and makes group infrastructure optional > > as > > > > > it is not needed when vfio device cdev is compiled. > > > > > > > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > > > > > > > The complete code can be found in below branch, simple test done > > with > > > > the > > > > > legacy group path and the cdev path. Draft QEMU branch can be found > > > > at[3] > > > > > > > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > > > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > > > > > Even using your branch[1], it seems like this has not been tested > > > > except with cdev support enabled: > > > > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > > ‘vfio_device_add’: > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: > > ‘struct > > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > > 253 | ret = cdev_device_add(&device->cdev, &device->device); > > > > | ^~~~ > > > > | dev > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > > ‘vfio_device_del’: > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: > > ‘struct > > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > > 262 | cdev_device_del(&device->cdev, &device->device); > > > > | ^~~~ > > > > | dev > > > > > > Sorry for it. It is due to the cdev definition is under > > > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > > > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > > > readability, it would be better to always define cdev in vfio_device, > > > and keep the using of cdev in code. How about your taste? > > > > It seems necessary unless we want to litter the code with #ifdefs. > > I've moved it to the header file and call cdev_device_add() > under #if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". > > > > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > > > > sense to me, it seems entirely redundant to VFIO_GROUP. > > > > > > The intention is to make the group code compiling match existing case. > > > Currently, if VFIO is configured, group code is by default compiled. > > > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option > > > for user. User needs to explicitly config VFIO_GROUP if VFIO_DEVICE_CDEV==y. > > > If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or > > > not, the group code shall be compiled. > > > > I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant > > and unnecessary. Also, Kconfig should not allow a configuration > > without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not > > functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, > > but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. > > How about below? As Jason's remark on patch 0003, cdev is not available > for SPAPR. > > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > index 0476abf154f2..96535adc2301 100644 > --- a/drivers/vfio/Kconfig > +++ b/drivers/vfio/Kconfig > @@ -4,6 +4,8 @@ menuconfig VFIO > select IOMMU_API > depends on IOMMUFD || !IOMMUFD > select INTERVAL_TREE > + select VFIO_GROUP if SPAPR_TCE_IOMMU > + select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM || ARM64) > select VFIO_CONTAINER if IOMMUFD=n > help > VFIO provides a framework for secure userspace device drivers. > @@ -14,7 +16,8 @@ menuconfig VFIO > if VFIO > config VFIO_DEVICE_CDEV > bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" > depends on IOMMUFD && (X86 || S390 || ARM || ARM64) > + default !VFIO_GROUP > help > The VFIO device cdev is another way for userspace to get device > access. Userspace gets device fd by opening device cdev under > @@ -23,9 +26,21 @@ config VFIO_DEVICE_CDEV > > If you don't know what to do here, say N. > > +config VFIO_GROUP > + bool "Support for the VFIO group /dev/vfio/$group_id" > + default y > + help > + VFIO group is legacy interface for userspace. As the introduction > + of VFIO device cdev interface, this can be N. For now, before > + userspace applications are fully converted to new vfio device cdev > + interface, this should be Y. > + > + If you don't know what to do here, say Y. > + I think this does the correct thing, but I'll reserve final judgment until I can try to break it ;) This message needs some tuning though, we're not far enough along the path of cdev access to consider the group interface "legacy" (imo) or expect that there are any userspace applications converted. There are also multiple setting recommendations to befuddle a layperson. Perhaps: VFIO group support provides the traditional model for accessing devices through VFIO and is used by the majority of userspace applications and drivers making use of VFIO. If you don't know what to do here, say Y. Thanks, Alex > config VFIO_CONTAINER > bool "Support for the VFIO container /dev/vfio/vfio" > select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64) > + depends on VFIO_GROUP > default y > help > The VFIO container is the classic interface to VFIO for establishing > > Regards, > Yi Liu
> From: Alex Williamson <alex.williamson@redhat.com> > Sent: Thursday, February 16, 2023 4:09 AM > > On Wed, 15 Feb 2023 07:54:31 +0000 > "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > Sent: Tuesday, February 14, 2023 11:47 PM > > > > > > On Tue, 14 Feb 2023 01:55:17 +0000 > > > "Liu, Yi L" <yi.l.liu@intel.com> wrote: > > > > > > > > From: Alex Williamson <alex.williamson@redhat.com> > > > > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > > > > > > > On Mon, 13 Feb 2023 07:13:33 -0800 > > > > > Yi Liu <yi.l.liu@intel.com> wrote: > > > > > > > > > > > Existing VFIO provides group-centric user APIs for userspace. > > > Userspace > > > > > > opens the /dev/vfio/$group_id first before getting device fd and > > > hence > > > > > > getting access to device. This is not the desired model for iommufd. > > > Per > > > > > > the conclusion of community discussion[1], iommufd provides > device- > > > > > centric > > > > > > kAPIs and requires its consumer (like VFIO) to be device-centric > user > > > > > > APIs. Such user APIs are used to associate device with iommufd > and > > > also > > > > > > the I/O address spaces managed by the iommufd. > > > > > > > > > > > > This series first introduces a per device file structure to be > prepared > > > > > > for further enhancement and refactors the kvm-vfio code to be > > > prepared > > > > > > for accepting device file from userspace. Then refactors the vfio to > be > > > > > > able to handle iommufd binding. This refactor includes the > mechanism > > > of > > > > > > blocking device access before iommufd bind, making > > > vfio_device_open() > > > > > be > > > > > > exclusive between the group path and the cdev path. Eventually, > adds > > > the > > > > > > cdev support for vfio device, and makes group infrastructure > optional > > > as > > > > > > it is not needed when vfio device cdev is compiled. > > > > > > > > > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > > > > > > > > > The complete code can be found in below branch, simple test done > > > with > > > > > the > > > > > > legacy group path and the cdev path. Draft QEMU branch can be > found > > > > > at[3] > > > > > > > > > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 > > > > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > > > > > > > Even using your branch[1], it seems like this has not been tested > > > > > except with cdev support enabled: > > > > > > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > > > ‘vfio_device_add’: > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: > > > ‘struct > > > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > > > 253 | ret = cdev_device_add(&device->cdev, &device- > >device); > > > > > | ^~~~ > > > > > | dev > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > > > ‘vfio_device_del’: > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: > > > ‘struct > > > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > > > 262 | cdev_device_del(&device->cdev, &device->device); > > > > > | ^~~~ > > > > > | dev > > > > > > > > Sorry for it. It is due to the cdev definition is under > > > > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > > > > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > > > > readability, it would be better to always define cdev in vfio_device, > > > > and keep the using of cdev in code. How about your taste? > > > > > > It seems necessary unless we want to litter the code with #ifdefs. > > > > I've moved it to the header file and call cdev_device_add() > > under #if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". > > > > > > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make > much > > > > > sense to me, it seems entirely redundant to VFIO_GROUP. > > > > > > > > The intention is to make the group code compiling match existing case. > > > > Currently, if VFIO is configured, group code is by default compiled. > > > > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an > option > > > > for user. User needs to explicitly config VFIO_GROUP if > VFIO_DEVICE_CDEV==y. > > > > If VFIO_DEVICE_CDEV==n, then no matter user configed > VFIO_GROUP or > > > > not, the group code shall be compiled. > > > > > > I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant > > > and unnecessary. Also, Kconfig should not allow a configuration > > > without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not > > > functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, > > > but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. > > > > How about below? As Jason's remark on patch 0003, cdev is not available > > for SPAPR. > > > > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > > index 0476abf154f2..96535adc2301 100644 > > --- a/drivers/vfio/Kconfig > > +++ b/drivers/vfio/Kconfig > > @@ -4,6 +4,8 @@ menuconfig VFIO > > select IOMMU_API > > depends on IOMMUFD || !IOMMUFD > > select INTERVAL_TREE > > + select VFIO_GROUP if SPAPR_TCE_IOMMU > > + select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM > || ARM64) > > select VFIO_CONTAINER if IOMMUFD=n > > help > > VFIO provides a framework for secure userspace device drivers. > > @@ -14,7 +16,8 @@ menuconfig VFIO > > if VFIO > > config VFIO_DEVICE_CDEV > > bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" > > depends on IOMMUFD && (X86 || S390 || ARM || ARM64) > > + default !VFIO_GROUP > > help > > The VFIO device cdev is another way for userspace to get device > > access. Userspace gets device fd by opening device cdev under > > @@ -23,9 +26,21 @@ config VFIO_DEVICE_CDEV > > > > If you don't know what to do here, say N. > > > > +config VFIO_GROUP > > + bool "Support for the VFIO group /dev/vfio/$group_id" > > + default y > > + help > > + VFIO group is legacy interface for userspace. As the introduction > > + of VFIO device cdev interface, this can be N. For now, before > > + userspace applications are fully converted to new vfio device cdev > > + interface, this should be Y. > > + > > + If you don't know what to do here, say Y. > > + > > I think this does the correct thing, but I'll reserve final judgment > until I can try to break it ;) > > This message needs some tuning though, we're not far enough along the > path of cdev access to consider the group interface "legacy" (imo) or > expect that there are any userspace applications converted. There are > also multiple setting recommendations to befuddle a layperson. Perhaps: > > VFIO group support provides the traditional model for accessing > devices through VFIO and is used by the majority of userspace > applications and drivers making use of VFIO. > > If you don't know what to do here, say Y. Got it. I'll update it to my branch first.
Existing VFIO provides group-centric user APIs for userspace. Userspace opens the /dev/vfio/$group_id first before getting device fd and hence getting access to device. This is not the desired model for iommufd. Per the conclusion of community discussion[1], iommufd provides device-centric kAPIs and requires its consumer (like VFIO) to be device-centric user APIs. Such user APIs are used to associate device with iommufd and also the I/O address spaces managed by the iommufd. This series first introduces a per device file structure to be prepared for further enhancement and refactors the kvm-vfio code to be prepared for accepting device file from userspace. Then refactors the vfio to be able to handle iommufd binding. This refactor includes the mechanism of blocking device access before iommufd bind, making vfio_device_open() be exclusive between the group path and the cdev path. Eventually, adds the cdev support for vfio device, and makes group infrastructure optional as it is not needed when vfio device cdev is compiled. This is also a prerequisite for iommu nesting for vfio device[2]. The complete code can be found in below branch, simple test done with the legacy group path and the cdev path. Draft QEMU branch can be found at[3] https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v3 (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) base-commit: 06a24ad [1] https://lore.kernel.org/kvm/BN9PR11MB5433B1E4AE5B0480369F97178C189@BN9PR11MB5433.namprd11.prod.outlook.com/ [2] https://lore.kernel.org/linux-iommu/20230209043153.14964-1-yi.l.liu@intel.com/ [3] https://github.com/yiliu1765/qemu/tree/iommufd_rfcv3 (it is based on Eric's QEMU iommufd rfcv3 (https://lore.kernel.org/kvm/20230131205305.2726330-1-eric.auger@redhat.com/) plus two commits to align with vfio_device_cdev v3) Change log: v3: - Add r-b from Kevin on patch 03, 06, 07, 08. - Refine the group and cdev path exclusion. Remove vfio_device:single_open; add vfio_group::cdev_device_open_cnt to achieve exlucsion between group path and cdev path (Kevin, Jason) - Fix a bug in the error handling path (Yan Zhao) - Address misc remarks from Kevin v2: https://lore.kernel.org/kvm/20230206090532.95598-1-yi.l.liu@intel.com/ - Add r-b from Kevin and Eric on patch 01 02 04. - "Split kvm/vfio: Provide struct kvm_device_ops::release() insted of ::destroy()" from this series and got applied. (Alex, Kevin, Jason, Mathhew) - Add kvm_ref_lock to protect vfio_device_file->kvm instead of reusing dev_set->lock as dead-lock is observed with vfio-ap which would try to acquire kvm_lock. This is opposite lock order with kvm_device_release() which holds kvm_lock first and then hold dev_set->lock. (Kevin) - Use a separate ioctl for detaching IOAS. (Alex) - Rename vfio_device_file::single_open to be is_cdev_device (Kevin, Alex) - Move the vfio device cdev code into device_cdev.c and add a VFIO_DEVICE_CDEV kconfig for it. (Kevin, Jason) v1: https://lore.kernel.org/kvm/20230117134942.101112-1-yi.l.liu@intel.com/ - Fix the circular refcount between kvm struct and device file reference. (JasonG) - Address comments from KevinT - Remained the ioctl for detach, needs to Alex's taste (https://lore.kernel.org/kvm/BN9PR11MB5276BE9F4B0613EE859317028CFF9@BN9PR11MB5276.namprd11.prod.outlook.com/) rfc: https://lore.kernel.org/kvm/20221219084718.9342-1-yi.l.liu@intel.com/ Thanks, Yi Liu Yi Liu (15): vfio: Allocate per device file structure vfio: Refine vfio file kAPIs vfio: Accept vfio device file in the driver facing kAPI kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd kvm/vfio: Accept vfio device file from userspace vfio: Pass struct vfio_device_file * to vfio_device_open/close() vfio: Block device access via device fd until device is opened vfio: Add infrastructure for bind_iommufd from userspace vfio-iommufd: Add detach_ioas support for physical VFIO devices vfio-iommufd: Add detach_ioas for emulated VFIO devices vfio: Add cdev_device_open_cnt to vfio_group vfio: Make vfio_device_open() single open for device cdev path vfio: Add cdev for vfio_device vfio: Add ioctls for device cdev using iommufd vfio: Compile group optionally Documentation/driver-api/vfio.rst | 8 +- Documentation/virt/kvm/devices/vfio.rst | 45 ++- drivers/gpu/drm/i915/gvt/kvmgt.c | 1 + drivers/s390/cio/vfio_ccw_ops.c | 1 + drivers/s390/crypto/vfio_ap_ops.c | 1 + drivers/vfio/Kconfig | 29 ++ drivers/vfio/Makefile | 3 +- drivers/vfio/device_cdev.c | 264 ++++++++++++++++ drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 + drivers/vfio/group.c | 149 +++++---- drivers/vfio/iommufd.c | 59 +++- .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 2 + drivers/vfio/pci/mlx5/main.c | 1 + drivers/vfio/pci/vfio_pci.c | 1 + drivers/vfio/pci/vfio_pci_core.c | 4 +- drivers/vfio/platform/vfio_amba.c | 1 + drivers/vfio/platform/vfio_platform.c | 1 + drivers/vfio/vfio.h | 168 +++++++++- drivers/vfio/vfio_main.c | 295 ++++++++++++++++-- include/linux/iommufd.h | 6 + include/linux/vfio.h | 28 +- include/uapi/linux/kvm.h | 16 +- include/uapi/linux/vfio.h | 86 +++++ virt/kvm/vfio.c | 141 ++++----- 24 files changed, 1106 insertions(+), 205 deletions(-) create mode 100644 drivers/vfio/device_cdev.c