On Tue, 18 Apr 2023 10:34:45 +0000 "Liu, Yi L" <yi.l.liu@xxxxxxxxx> wrote: > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > Sent: Tuesday, April 18, 2023 12:11 PM > > > [...] > > > > We haven't discussed how it fails when called on a group-opened device > > in a mixed environment. I'd propose that the INFO ioctl behaves > > exactly as it does today, reporting group-id and BDF for each affected > > device. However, the hot-reset ioctl itself is not extended to accept > > devicefd because there is no proof-of-ownership model for cdevs. > > Therefore even if the user could map group-id to devicefd, they get > > -EINVAL calling HOT_RESET with a devicefd when the ioctl is called from > > a group-opened device. Thanks, > > Will it be better to let userspace know it shall fail if invoking hot > reset due to no proof-of-ownership as it also has cdev devices? Maybe > the RESETTABLE flag should always be meaningful. Even if the calling > device of _INFO is group-opened device. Old user applications does not > need to check it as it will never have such mixed environment. But for > new applications or the applications that have been updated per latest > vfio uapi, it should strictly check this flag before going ahead to do > hot-reset. The group-opened model cannot consistently predict whether the user can provide proof-of-ownership. I don't think we should define a flag simply because there's a case that we can predict, the definition of that flag becomes problematic. Let's not complicate the interface by trying to optimize a case that will likely never exist in practice and can be handled via the existing legacy API. Thanks, Alex
