RE: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs

> From: Jason Gunthorpe <[email protected]>
> Sent: Monday, August 17, 2026 8:18 PM
> 
> On Fri, Aug 14, 2026 at 08:37:37AM -0600, Alex Williamson wrote:
> 
> > Devices are only ever opened into a user owned domain, the IOMMU
> > context switch happens before this and regardless of the reset.  Close
> > also disables bus-master regardless of reset, so there's no risk of
> > ongoing DMA if the device is placed into an identity domain between
> > close and re-open.
> 
> I've been told by HW people that bus-master isn't actually a strong
> fence for stopping DMA on most real HW. More of a 'dma will eventually
> stop' kind of thing.
> 
> It does reliably prevent DMA during the post-FLR phase only.
> 
> If the device hasn't been reset it should be kept on a blocking
> domain.
> 
> > PF, I think there are arguments both that the user implicitly opted in
> > to the best-effort reset, as well as a use case that allows the PF
> > driver to fail and re-open the PF demands this behavior.
> 
> I really think we cannot alow a device to be returned back to the
> kernel without a reset. VFIO should be keeping things attached to a
> blocking domain as long as the driver is bound. It should force a
> reset during unbinding as well if the device FD was ever closed
> without a reset..
> 

hmm so we have several resetting categories:

1) reset a hanging PF or for administrative purpose (sysfs, vfio
   open/close etc.)

This series avoids uncoordinated disruptive impact on associated VFs
by rejecting the request. User can reinitiate the resetting request
after disabling SR-IOV.

2) resetting a erroneous PF in the AER path

The link to the PF is down. pci_{slot|bus}_reset() is called by pci core
to recover the error condition. VFs are impacted inevitably as the
cmd to disable sriov may not reach the PF at all.

Not sure any enhancement can be done to relax disruptive on
associated VFs, but so far this series doesn't change this path.

3) resetting a PF due to ad-hoc FW error

e.g. pdsc_check_pci_health() calls pci_reset_function() when FW
reports broken PCI. Sounds a similar condition to AER.

but as it calls pci_reset_function() this series causes a regression
in case of active VFs. Is it desired?

4) Jason's suggestion to force a reset upon unbinding

sounds reasonable and clean as long as reset is done post disabling
sriov, which is the 1st action in vfio_pci_core_unregister_device(). Then
it's just a normal reset w/o concerning any active VFs.