Re: [PATCH v3 5/5] pci: Suspend iommu function prior to resetting a device

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Aug 21, 2025 at 11:35:27PM -0700, Nicolin Chen wrote:
> On Thu, Aug 21, 2025 at 10:07:41AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 19, 2025 at 02:59:07PM -0700, Nicolin Chen wrote:
> > >  c) multiple pci_devs with their own RIDs
> > > 
> > >     In this case, either FLR or IOMMU only resets the PF. That
> > >     being said, VFs might be affected since PF is resetting?
> > >     If there is an issue, I don't see it coming from the IOMMU-
> > >     level reset..
> > 
> > It would still allow the ATS issue from the VF side. The VF could be
> > pushing an invalidation during the PF reset that will get clobbered.
> > 
> > I haven't fully checked but I think Linux doesn't really (easially?)
> > allow resetting a PF while a VF is present...
> 
> Hmm, what if the PF encountered some fault? Does Linux have a choice
> not to reset PF?

Upon more reflect I guess outside VFIO I seem to remember the SRIOV
reset to the PFs will clobber the VFs too and then restore the SRIOV
configuration in config space to bring them back.

> > Arguably if the PF is reset the VFs should have their translations
> > blocked too.
> 
> Yea, that sounds plausible to me. But, prior to that (an IOMMU-level
> reset), should VFs be first reset at the PCI level?

PF reset of a SRIOV PF disables the VFs and effectively resets them
already.

But reaching out to mangle the translation of the VFs means you do
have to take care not to disrupt anything else the VF owning driver is
doing since it is fully unaware of this. Ie it could be reattaching to
something else concurrently.

Jason