On Fri, Feb 17, 2023 at 05:48:57AM +0000, Liu, Yi L wrote: > > From: Liu, Yi L <yi.l.liu@xxxxxxxxx> > > Sent: Friday, February 17, 2023 1:34 PM > > > > > From: Jason Gunthorpe <jgg@xxxxxxxxxx> > > > Sent: Wednesday, February 15, 2023 8:18 AM > > > > > > On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > > > > > > > A device file opened through a group could be passed through this > > > > interface though, right? > > > > > > Yes, I think so > > > > > > > Do we just chalk that up to user error? Maybe the SPAPR extension > > > > at least needs to be documented as relying on registering groups > > > > rather than devices. > > > > > > The way these APIs work is you have to pass the same FD to all of > > > them. The SPAPR stuff is no different, if you used a cdev with > > > KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd > > with > > > the > > > SPAPR group_fd. Yi just didn't rename it. > > > > This is because SPAPR cannot accept cdev fd yet. It explicitly requires > > group fd and get iommu_group during the handling. > > Sorry I misunderstood it. I think this can be renamed to be fds if > no objection. Maybe as below, so that old userspace that uses > group_fds can still compile. I doubt if a new flag is needed to > identify the provided fds are group or device fds. I guess no since > the pci hot reset code does not really care about it. It cares more > the fd is held by the application. I wouldn't change it, even though it does work like this spapr requires the group fd because it doesn't work with iommufd. No sense in confusing things. Jason
