> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Wednesday, March 22, 2023 9:43 PM > > On Wed, Mar 22, 2023 at 01:33:09PM +0000, Liu, Yi L wrote: > > > 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. > > Yes, it would be simplest for qemu to do the query after it gains a > new dev_id and then it can add the new dev_id with the correct reset > group. I see. QEMU can decide. For now, it seems like QEMU doesn't store such the info return by the existing _INFO ioctl. It is used in the hot reset helper and freed before it returns. Though, I'm not sure whether QEMU will store the dev_id info returned by the new _INFO. Perhaps Alex can give some guidance. > > > 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. > > Yes > > > 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. > > Yes > > qemu should refuse to use the device at this moment. Yes. it is. btw. Another question about this new _INFO ioctl. If there are affected devices that have not been bound to vfio driver yet, should this new _INFO ioctl fail all the same with EPERM? Or it still just returns the dev_ids of the devices that are already bound and opened. This seems to make sense with two reasons: - for one, the new _INFO is not designed to give userspace an exact affected device list; - for two, reset shall fail when checking vfio_pci_dev_set_resettable(); Please feel free to correct me if this is wrong. Regards, Yi Liu
