Re: [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Feb 17, 2023 at 05:48:57AM +0000, Liu, Yi L wrote:
> > From: Liu, Yi L <yi.l.liu@intel.com>
> > Sent: Friday, February 17, 2023 1:34 PM
> > 
> > > From: Jason Gunthorpe <jgg@nvidia.com>
> > > 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