Message ID | 0-v2-6011bde8e0a1+5f-vfio_mdev_no_group_jgg@nvidia.com (mailing list archive) |
---|---|
Headers | show |
Series | Make the rest of the VFIO driver interface use vfio_device | expand |
On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote: > Prior series have transformed other parts of VFIO from working on struct > device or struct vfio_group into working directly on struct > vfio_device. Based on that work we now have vfio_device's readily > available in all the drivers. > > Update the rest of the driver facing API to use vfio_device as an input. > > The following are switched from struct device to struct vfio_device: > vfio_register_notifier() > vfio_unregister_notifier() > vfio_pin_pages() > vfio_unpin_pages() > vfio_dma_rw() > > The following group APIs are obsoleted and removed by just using struct > vfio_device with the above: > vfio_group_pin_pages() > vfio_group_unpin_pages() > vfio_group_iommu_domain() > vfio_group_get_external_user_from_dev() > > To retain the performance of the new device APIs relative to their group > versions optimize how vfio_group_add_container_user() is used to avoid > calling it when the driver must already guarantee the device is open and > the container_users incrd. > > The remaining exported VFIO group interfaces are only used by kvm, and are > addressed by a parallel series. > > This series is based on Christoph's gvt rework here: > > https://lore.kernel.org/all/5a8b9f48-2c32-8177-1c18-e3bd7bfde558@intel.com/ > > and so will need the PR merged first. Hi Alex, Since all the shared branch PRs are ready, do you have any remarks on this series and the others before I rebase and repost them? This one has a few changes to the commit messages outstanding, but v2 didn't have any code changes. Also, what order would like the different series in - they conflict with each other a little bit. I suggest this: - mdev group removal (this one) - Remove vfio_device_get_from_dev() https://lore.kernel.org/r/0-v1-7f2292e6b2ba+44839-vfio_get_from_dev_jgg@nvidia.com - Remove group from kvm https://lore.kernel.org/r/0-v1-33906a626da1+16b0-vfio_kvm_no_group_jgg@nvidia.com All of them seem to have got enough reviews now. I have one more series on this group topic and a few little patches still It would be great if you could merge the gvt and iommu series together into your tree toward linux-next so I can post patches against a stable commit ID so the build-bots can test them. Thanks, Jason
On Fri, 29 Apr 2022 14:31:49 -0300 Jason Gunthorpe <jgg@nvidia.com> wrote: > On Thu, Apr 21, 2022 at 01:28:31PM -0300, Jason Gunthorpe wrote: > > Prior series have transformed other parts of VFIO from working on struct > > device or struct vfio_group into working directly on struct > > vfio_device. Based on that work we now have vfio_device's readily > > available in all the drivers. > > > > Update the rest of the driver facing API to use vfio_device as an input. > > > > The following are switched from struct device to struct vfio_device: > > vfio_register_notifier() > > vfio_unregister_notifier() > > vfio_pin_pages() > > vfio_unpin_pages() > > vfio_dma_rw() > > > > The following group APIs are obsoleted and removed by just using struct > > vfio_device with the above: > > vfio_group_pin_pages() > > vfio_group_unpin_pages() > > vfio_group_iommu_domain() > > vfio_group_get_external_user_from_dev() > > > > To retain the performance of the new device APIs relative to their group > > versions optimize how vfio_group_add_container_user() is used to avoid > > calling it when the driver must already guarantee the device is open and > > the container_users incrd. > > > > The remaining exported VFIO group interfaces are only used by kvm, and are > > addressed by a parallel series. > > > > This series is based on Christoph's gvt rework here: > > > > https://lore.kernel.org/all/5a8b9f48-2c32-8177-1c18-e3bd7bfde558@intel.com/ > > > > and so will need the PR merged first. > > Hi Alex, > > Since all the shared branch PRs are ready, do you have any remarks on > this series and the others before I rebase and repost them? Only the nit in the commit log: https://lore.kernel.org/all/20220429142820.6afe7bbe.alex.williamson@redhat.com/ > This one has a few changes to the commit messages outstanding, but v2 > didn't have any code changes. > > Also, what order would like the different series in - they conflict > with each other a little bit. I suggest this: > > - mdev group removal (this one) > - Remove vfio_device_get_from_dev() > https://lore.kernel.org/r/0-v1-7f2292e6b2ba+44839-vfio_get_from_dev_jgg@nvidia.com > - Remove group from kvm > https://lore.kernel.org/r/0-v1-33906a626da1+16b0-vfio_kvm_no_group_jgg@nvidia.com I think you mean (v2): https://lore.kernel.org/all/0-v2-6a528653a750+1578a-vfio_kvm_no_group_jgg@nvidia.com/ Otherwise, thanks for sorting these out for me. > All of them seem to have got enough reviews now. > > I have one more series on this group topic and a few little patches still > > It would be great if you could merge the gvt and iommu series together > into your tree toward linux-next so I can post patches against a > stable commit ID so the build-bots can test them. Please check my vfio next branch and see if this matches what you're looking for: https://github.com/awilliam/linux-vfio/commits/next I'll look for any fallout from Stephen and build bots on Monday's linux-next compilation. Thanks, Alex
Prior series have transformed other parts of VFIO from working on struct device or struct vfio_group into working directly on struct vfio_device. Based on that work we now have vfio_device's readily available in all the drivers. Update the rest of the driver facing API to use vfio_device as an input. The following are switched from struct device to struct vfio_device: vfio_register_notifier() vfio_unregister_notifier() vfio_pin_pages() vfio_unpin_pages() vfio_dma_rw() The following group APIs are obsoleted and removed by just using struct vfio_device with the above: vfio_group_pin_pages() vfio_group_unpin_pages() vfio_group_iommu_domain() vfio_group_get_external_user_from_dev() To retain the performance of the new device APIs relative to their group versions optimize how vfio_group_add_container_user() is used to avoid calling it when the driver must already guarantee the device is open and the container_users incrd. The remaining exported VFIO group interfaces are only used by kvm, and are addressed by a parallel series. This series is based on Christoph's gvt rework here: https://lore.kernel.org/all/5a8b9f48-2c32-8177-1c18-e3bd7bfde558@intel.com/ and so will need the PR merged first. I have a followup series that needs this. This is also part of the iommufd work - moving the driver facing interface to vfio_device provides a much cleaner path to integrate with iommufd. v2: - Based on Christoph's series so mdev_legacy_get_vfio_device() is removed - Reflow indenting - Use vfio_assert_device_open() and WARN_ON_ONCE instead of open coding the assertion v1: https://lore.kernel.org/r/0-v1-a8faf768d202+125dd-vfio_mdev_no_group_jgg@nvidia.com Cc: Christoph Hellwig <hch@lst.de> Cc: intel-gfx@lists.freedesktop.org Cc: intel-gvt-dev@lists.freedesktop.org Cc: kvm@vger.kernel.org Cc: "Tian, Kevin" <kevin.tian@intel.com> Cc: "Liu, Yi L" <yi.l.liu@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Jason Gunthorpe (7): vfio: Make vfio_(un)register_notifier accept a vfio_device vfio/ccw: Remove mdev from struct channel_program vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages() vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw() drm/i915/gvt: Change from vfio_group_(un)pin_pages to vfio_(un)pin_pages vfio: Remove dead code vfio: Remove calls to vfio_group_add_container_user() .../driver-api/vfio-mediated-device.rst | 4 +- drivers/gpu/drm/i915/gvt/gvt.h | 5 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 51 ++-- drivers/s390/cio/vfio_ccw_cp.c | 47 +-- drivers/s390/cio/vfio_ccw_cp.h | 4 +- drivers/s390/cio/vfio_ccw_fsm.c | 3 +- drivers/s390/cio/vfio_ccw_ops.c | 7 +- drivers/s390/crypto/vfio_ap_ops.c | 23 +- drivers/vfio/vfio.c | 288 ++---------------- include/linux/vfio.h | 21 +- 10 files changed, 102 insertions(+), 351 deletions(-) base-commit: 3515cc4aa9440795ab20b87ade2e2727267d469d