> From: Jason Gunthorpe > Sent: Wednesday, April 12, 2023 8:01 AM > > I see this problem as a few basic requirements from a qemu-like > application: > > 1) Does the configuration I was given support reset right now? > 2) Will the configuration I was given support reset for the duration > of my execution? > 3) What groups of the devices I already have open does the reset > effect? > 4) For debugging, report to the user the full list of devices in the > reset group, in a way that relates back to sysfs. > 5) Away to trigger a reset on a group of devices > > #1/#2 is the API I suggested here. Ask the kernel if the current > configuration works, and ask it to keep it working. > > #3 is either INFO and a CAP for BDF or INFO2 reporting dev_id > > #4 is either INFO and print the BDFs or INFO2 reporting the struct > vfio_device IDR # (eg /sys/class/vfio/vfioXXX/). mdev doesn't have BDF. Of course it doesn't support hot_reset either. but it's presented to userspace as a pci device. Is it weird for a pci device which doesn't provide a BDF cap? from this point the vfio_device IDR# sounds more generic. > > #5 is adjusting the FD list in existing RESET ioctl. Remove the need > for userspace to specify a minimal exact list of FDs means userspace > doesn't need the information to figure out what that list actually > is. Pass a 0 length list and use iommufdctx. > > None of these requirements suggests to me that qemu needs to know the > group_id, or that it needs to have enough information to know how to > fix an unavailable reset. >
