On Wed, 5 Apr 2023 13:37:05 -0300 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Wed, Apr 05, 2023 at 10:25:45AM -0600, Alex Williamson wrote: > > > But that kind of brings to light the question of what does the user do > > when they encounter this situation. > > What does it do now when it encounters a group_id it doesn't > understand? Userspace already doesn't know if the foreign group is > open or not, right? It's simple, there is currently no screwiness around opened devices. If the caller doesn't own all the groups mapping to the affected devices, hot-reset is not available. > > reset can complete. If the device is opened by a different user, the > > reset is blocked. The only logical conclusion is that the user should > > try the reset regardless of the result of the info ioctl, which the > > IMHO my suggested version is still the overall saner uAPI. > > An info that basically returns success/fail if reset is security > authorized and information about the reset groupings. > > Actual reset follows the returned groupings automatically. > > Easy for qemu. Call the info at startup to confirm reset can be > emulated, use the returned information to propogate the reset groups > to the guest. Trigger the reset with no fuss when the guest asks for > it. > > Less weird corner cases. This leads to scenarios where the info ioctl indicates a hot-reset is initially available, perhaps only because one of the affected devices was not opened at the time, and now it fails when QEMU actually tries to use it. In the group model, QEMU can know the set of affected devices and the required groups, confirm it owns those, and for all practical purposes guarantee that a hot-reset is available (yes, there might be some exceptionally rare topology changes). This goofiness around unopened devices and null-arrays is killing this API. Thanks, Alex
