> From: Alex Williamson > Sent: Friday, March 17, 2023 2:46 AM > > On Wed, 15 Mar 2023 23:31:23 +0000 > "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > > > > From: Alex Williamson <alex.williamson@xxxxxxxxxx> > > > Sent: Thursday, March 16, 2023 6:53 AM > > > I'm afraid this proposal reduces or eliminates the handshake we have > > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO and > > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to ignore > the > > > _INFO ioctl altogether, resulting in drivers that don't understand the > > > scope of the reset. Is it worth it? What do we really gain? > > > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > > useful today. > > > > It's an interface on opened device. So the tiny difference is whether the > > user knows the device is resettable when calling GET_INFO or later when > > actually calling PCI_HOT_RESET. > > No, GET_PCI_HOT_RESET_INFO conveys not only whether a PCI_HOT_RESET > can > be performed, but equally important the scope of the reset, ie. which > devices are affected by the reset. If we de-emphasize the INFO > portion, then this easily gets confused as just a variant of > VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In > fact, I'd say the interface is not only trying to validate that the > user has sufficient privileges for the reset, but that they explicitly > acknowledge the scope of the reset. > IMHO the usefulness of scope is if it's discoverable by the management stack which then can try to assign devices with affected reset to a same user. but this info is only available after the device is opened. Then the mgmt. stack just assigns devices w/o awareness of reset scope and nothing can be changed by the user no matter it knows the scope or not. from this angle I don't see a value of probe-and-reset vs. direct reset when reset itself also takes the scope into consideration. Probably the slight difference is that with probe a more informative error message can be printed out?
