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

[Alex Williamson <alex.williamson@nvidia.com>]

On Wed, 12 Aug 2026 16:45:54 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

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

I don't understand how the i40e and ice NIC VFs can continue operation
with only MSI-X state restored.  It seems to directly contradict the
requirements of the PCIe spec (7.0):

9.2.2.3 FLR That Targets a PF §

  PFs must support FLR.

  FLR to a PF resets the PF state as well as the SR-IOV extended
  capability including VF Enable which means that VFs no longer exist.

9.2.3 IOV Re-initialization and Reallocation §

  If VF Enable is Cleared after having been Set, all of the VFs
  associated with the PF no longer exist and must no longer issue PCIe
  transactions or respond to Configuration Space or Memory Space
  accesses. VFs must not retain any architected state after VF Enable
  has been Cleared (including sticky bits). For security, unarchitected
  VF state configured through the VF must be cleared or randomized,
  with the exception of persistent storage data.

For the PF driver patches noted to be effective, the VFs must not be
scrubbed on re-initialization, nor can a .reset_done hook in the PF
driver do anything to avoid unsupported requests from ongoing DMA and
MMIO accesses while VF Enable is cleared.  So it looks like an
incomplete fix for non-compliant devices?  Thanks,

Alex