On Mon, Jan 06, 2025 at 03:52:31PM -0600, Nishanth Aravamudan wrote:
> vfio_pci_ioctl_get_pci_hot_reset_info checks if either the vdev's slot
> or bus is not resettable by calling pci_probe_reset_{slot,bus}. Those
> functions in turn call pci_{slot,bus}_resettable() to see if the PCI
> device supports reset.
This change makes sense to me, but..
> However, commit d88f521da3ef ("PCI: Allow userspace to query and set
> device reset mechanism") added support for userspace to disable reset of
> specific PCI devices (by echo'ing "" into reset_method) and
> pci_{slot,bus}_resettable methods do not check pci_reset_supported() to
> see if userspace has disabled reset. Therefore, if an administrator
> disables PCI reset of a specific device, but then uses vfio-pci with
> that device (e.g. with qemu), vfio-pci will happily end up issuing a
> reset to that device.
How does vfio-pci endup issuing a reset? It looked like all the paths
are blocked in the pci core with pci_reset_supported()? Is there also
a path that vfio is calling that is missing a pci_reset_supported()
check? If yes that should probably be fixed in another patch.
Or do you mean that VFIO tries to do a reset but it fails and nothing
happens, the real issue is that hot_reset_info is reporting incorrect
information to userspace?
Jason
