> From: Tian, Kevin <kevin.tian@xxxxxxxxx> > Sent: Friday, February 24, 2023 11:57 AM > > > 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. Yes. although I guess no user would do such a strange thing if no special reason. 😊 Regards, Yi Liu
