Re: [PATCH v2 04/13] PCI/IOV: Allow VF drivers to handle resets

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc others interested in VF reset]

On Tue, Oct 27, 2026 at 05:04:37PM +0100, Lukasz Laguna wrote:
> From: Michał Winiarski <michal.winiarski@intel.com>
> 
> While the kernel representation of VF device (think struct device) is
> preserved across PF FLR, and the PF IOV state (among other PCI CFG
> state) is saved and restored across reset, the actual VF state is lost,
> as from PCI perspective, VF didn't exist in the time between PF FLR and
> PF IOV state restore.
> 
> Save / restore all subordinate VFs config state, and notify their
> drivers using .reset_prepare() / .reset_done() to make sure that both
> architected and unarchitected state can be preserved across FLR.
> 
> VFs are disabled only after the PF driver's .reset_prepare() and their
> state is restored before PF driver's .reset_done(), so they can still
> communicate with the PF while it handles the reset.
> 
> This also fixes VFs handling during bus and slot reset. Previously, VFs
> were handled like any other device found while walking bus->devices.
> Since that walk is top-down, the .reset_prepare() was triggered on PF
> before it was triggered on the VFs. Moreover, the walk recurses only
> through dev->subordinate, so it never reaches VFs on an SR-IOV virtual
> bus, as such a bus has no bridge. Those VFs were reset without being
> locked, without driver notification and without config space
> save/restore. Now, the bus walk skips VFs and they are locked, saved
> and restored together with their PF.
> 
> As part of this, pci_reset_function_locked() now requires PF callers to
> hold the device locks for all enabled VFs as well.
> 
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> Co-developed-by: Lukasz Laguna <lukasz.laguna@intel.com>
> Signed-off-by: Lukasz Laguna <lukasz.laguna@intel.com>


> @@ -5340,6 +5402,10 @@ void pci_init_reset_methods(struct pci_dev *dev)
>   * from __pci_reset_function_locked() in that it saves and restores device state
>   * over the reset and takes the PCI device lock.
>   *
> + * If @dev is a PF with VFs enabled, the VFs are locked as well, their drivers
> + * are notified via reset_prepare() and reset_done(), and their state is saved
> + * and restored over the reset.
> + *
>   * Returns 0 if the device function was successfully reset or negative if the
>   * device doesn't support resetting a single function.
>   */
> @@ -5360,11 +5426,13 @@ int pci_reset_function(struct pci_dev *dev)
>  		pci_dev_lock(bridge);
>  
>  	pci_dev_lock(dev);
> +	pci_dev_lock_vfs(dev);
>  	pci_dev_save_and_disable(dev);
>  
>  	rc = __pci_reset_function_locked(dev);

Today we can call pci_reset_function() on a VF, can't we?  I assume it
will do an FLR on just that VF?  It looks like this expects to only be
called on a PF.  Or maybe pci_dev_lock_vfs() is a no-op if called on a
VF, although that isn't obvious to me from the implementation?

>  	pci_dev_restore(dev);
> +	pci_dev_unlock_vfs(dev);
>  	pci_dev_unlock(dev);