> From: Alex Williamson <alex.williamson@xxxxxxxxxx> > Sent: Friday, April 14, 2023 2:07 AM > > We had already iterated a proposal where the group-id is replaced with > a dev-id in the existing ioctl and a flag indicates when the return > value is a dev-id vs group-id. This had a gap that userspace cannot > determine if a reset is available given this information since un-owned > devices report an invalid dev-id and userspace can't know if it has > implicit ownership. > > It seems cleaner to me though that we would could still re-use INFO in > a similar way, simply defining a new flag bit which is valid only in > the case of returning dev-ids and indicates if the reset is available. > Therefore in one ioctl, userspace knows if hot-reset is available > (based on a kernel determination) and can pull valid dev-ids from the So the kernel needs to compare the group id between devices with valid dev-ids and devices with invalid dev-ids to decide the implicit ownership. For noiommu device which has no group_id when VFIO_GROUP is off then it's resettable only if having a valid dev_id. The only corner case with this option is when a user mixes group and cdev usages. iirc you mentioned it's a valid usage to be supported. In that case the kernel doesn't have sufficient knowledge to judge 'resettable' as it doesn't know which groups are opened by this user. Not sure whether we can leave it in a ugly way so INFO may not tell 'resettable' accurately in that weird scenario. > array to associate affected, owned devices, and still has the > equivalent information to know that one or more of the devices listed > with an invalid dev-id are preventing the hot-reset from being > available. > > Is that an option? Thanks, > This works for me if above corner case can be waived.
