[Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
Tian, Kevin
kevin.tian at intel.com
Tue Mar 7 02:31:11 UTC 2023
> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Monday, March 6, 2023 9:17 PM
>
> On Fri, Mar 03, 2023 at 09:55:42AM -0700, Alex Williamson wrote:
>
> > I can't think of a reason DPDK couldn't use hot-reset. If we want to
> > make it a policy, it should be enforced by code, but creating that
> > policy based on a difficulty in supporting that mode with iommufd isn't
> > great.
>
> On the other hand adding code to allow device FDs in the hot reset
> path that is never used and never tested isn't great either..
>
> hot-reset does work for DPDK, it just doesn't work in the case where
> DPDK would have many VFIO devices open and they have overlapping
> device sets. Which, again, is something it doesn't do.
>
> IMHO we should leave it out of the kernel and wait for a no-iommu user
> to come forward that wants hot-reset of many devices. Then we can add
> and test the device FD part. Most likely such a thing will never come
> at this point.
>
I think we don't need to have this tradeoff if following Yi's last proposal
which requires every opened device in the set to be covered by the
device fd array. with dev_set->lock held in the reset/open path this is
a safe measure and fully contained in vfio-pci w/o need of further
checking noiommu or iommufd.
In the end same reset uAPI except the fd array can be device fd now. 😊
btw Yi, since this also affects the group path (though positive) it's clearer
to first add open_count check in existing group path in a separate patch
and then add the device fd support.
More information about the Intel-gfx
mailing list