RE: [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

Tian, Kevin
2023-04-12T07:27:50Z

> 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.
>