> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > 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.
