> From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > Sent: Friday, February 24, 2023 11:44 AM > > > Upon reflection we can probably make it even simpler and just have a 0 > > > length fd array mean to use the iommufd the vfio_device is already > > > associated with > > > > > > And the check for correctness can be simplified to simply see if each > > > vfio_device in the dev_set is attached to the same iommufd ctx > > > pointer instead of searching the xarray. > > How about the hot reset info path? We can still keep reporting the > current information to userspace. Isn't it? No need to change that. It's already reported per device. > > another tricky question. If user passess iommufd down for reset > in the vfio iommufd compatible mode, should we support it as > well? > I don't see why we want to ban it. It does change the result from error (vfio container) to success (iommufd vfio-compat) when using the container fd/iommufd. But do we actually have a use case relying on such error pattern? On the other hand an user who knows the presence of vfio-compat should be allowed to pass iommufd to reset even when it still uses the legacy group/container interfaces.
