Re: [RFC PATCH 0/5] PCI/vfio-pci: Guard resets against active SR-IOV VFs

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc Andrii, Mitch, Nick, Tony, Przemek]

On Tue, Aug 11, 2026 at 10:53:18PM -0600, Alex Williamson wrote:
> It's recently been found[1] that vfio-pci doesn't restrict resets on PFs
> while SR-IOV is enabled.  This can not only result in an uncoordinated
> disruption of the use of the associated VFs, but the ongoing use of and
> access to the VF has the potential to result in machine checks.

I suspect this might also be related to the somewhat weird usage of
pci_restore_msi_state() to restore VF MSI state in several network
drivers:

  https://git.kernel.org/linus/371e576ff3e8 ("i40e: Restore VF MSI-X state during PCI reset")
  https://git.kernel.org/linus/7e4dcc13965c ("iavf: restore MSI state on reset")
  https://git.kernel.org/linus/a54a0b24f4f5 ("ice: restore VF MSI-X state during PCI reset")

I think these are a little weird because they only run on a PF but
call pci_restore_msi_state() on all the VFs.

I guess these paths are recovery after FLR of the PF destroys the VFs,
and after the FLR, pci_restore_state() on the PF re-enables the VFs
but leaves them uninitialized.  It seems kind of ad hoc to restore VF
MSI state but not the rest of VF config space.  This all seems kind of
messy and makes me dubious about exporting pci_restore_msi_state()
directly to drivers.

> This series proposes that this gap is largely an oversight of
> pci_reset_function() to recognize that a PF reset affecting SR-IOV VFs
> violates the scope boundary of the pci_reset_function() API.
> 
> Patch 1 introduces guards in the common wrappers where we can hold
> device_lock to prevent .sriov_configure races.  This covers locking
> conformant use cases.  __pci_reset_function_locked() can't be gated in
> PCI-core; it runs after the potentially destructive .reset_prepare.
> Therefore its callers must provide the gating, along with the locking
> and state manipulation the interface already demands.  The vfio-pci
> change is included as an example and known use case here.
> 
> Patch 2 introduces a callback to pci_reset_bus() which allows a lock
> dependent callback to be evaluated after locking the physical hierarchy
> and before initiating the actual reset.  This allows use cases such as
> in the following patch to evaluate the SR-IOV PF configuration without
> racing.
> 
> Patch 3 implements exactly that test in vfio-pci-core, such that the
> hot-reset ioctl can be blocked when SR-IOV VFs are present on a bus/slot
> affected PF.  This completes the lockdown of resets induced on behalf of
> the vfio-pci in-kernel or userspace drivers.
> 
> Patch 4 exports pci_reset_supported, which allows patch 5 to remove the
> latched reset_works flag, which already had the potential to become
> stale due to reset_method manipulation through sysfs, but now may also
> become stale due to the SR-IOV state of the PF.
> 
> This is RFC to capture the discussion of [1] while it's active but
> requires testing before formal proposal.  This effectively side-steps
> the feasibility and security question of the operating model in use by
> the referenced thread by generically gating resets affecting PFs with
> active SR-IOV.  Please review and comment.  Thanks,
> 
> Alex
> 
> 
> [1]https://lore.kernel.org/all/20260805003355.728299-1-skhawaja@google.com/
> 
> Alex Williamson (5):
>   PCI: Refuse function reset of an SR-IOV PF with enabled VFs
>   PCI: Add pci_reset_bus_cond() for a caller-gated slot or bus reset
>   vfio/pci: Refuse to reset an SR-IOV PF with enabled VFs
>   PCI: Export pci_reset_supported()
>   vfio/pci: Use pci_reset_supported() in place of reset_works
> 
>  drivers/pci/pci.c                | 117 +++++++++++++++++++++++++++----
>  drivers/pci/pci.h                |   1 -
>  drivers/vfio/pci/vfio_pci_core.c |  28 +++++---
>  include/linux/pci.h              |   4 ++
>  include/linux/vfio_pci_core.h    |   1 -
>  include/uapi/linux/vfio.h        |   3 +
>  6 files changed, 129 insertions(+), 25 deletions(-)
> 
> -- 
> 2.53.0
>