[Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

[Liu, Yi L]

> From: Jason Gunthorpe <jgg at nvidia.com>
> Sent: Wednesday, March 22, 2023 8:18 PM
>
> On Wed, Mar 22, 2023 at 08:17:54AM +0000, Liu, Yi L wrote:
> 
> > Could you elaborate what is required with _INFO before libvirt can
> > use a FD pass?
> 
> Make a new _INFO that returns an array of dev_ids within the cdev's
> iommufd_ctx that are part of the reset group, eg the devset.
>
> qemu will call this for each dev_id after it opens the cdev to
> generate the groupings.

Thanks. So this new _INFO only reports a limited scope instead of
the full list of affected devices. Also, it is not static scope since device
may be opened just after the _INFO returns.

> > > But for the current qemu setup it will open cdev directly and it will
> > > know the BDF so it can still use the current _INFO.
> > >
> > > Though it would be nice if qemu didn't need two implementations so Yi
> > > I'd rather see a new info in this series as well and qemu can just
> > > consistently use dev_id and never bdf in iommufd mode.
> >
> > I have one concern here. iommufd dev_id is not a static info as much as
> > bdf. It is generated when bound to iommufd. So if there are devices that
> > are affected but not bound to iommufd yet at the time of invoking _INFO,
> > then the _INFO ioctl just gets a subset of the affected devices. Is it enough?
> 
> I'd probably use similar logic as the reset path, if one of reset
> group devices is open and on a different iommufd_ctx then fail the
> IOCTL with EPERM.

Say there are three devices in the dev_set. When the first device is
opened by the current qemu, this new _INFO would return one dev_id
to user. When the second device is opened, this new _INFO will return
two dev_ids to user. If the third device is opened by another qemu, then
the new _INFO would fail since the former two devices were opened and
have different iommufd_ctx with the third device.

Regards,
Yi Liu