[Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace

[Liu, Yi L]

> From: Liu, Yi L <yi.l.liu at intel.com>
> Sent: Friday, February 17, 2023 1:34 PM
> 
> > From: Jason Gunthorpe <jgg at 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.

struct vfio_pci_hot_reset {
	__u32   argsz;
	__u32   flags;
	__u32   count;
	union {
		__s32   group_fds[];
		__s32   fds[];
	};
};

Regards,
Yi Liu