Re: [RFC PATCH 1/5] PCI: Refuse function reset of an SR-IOV PF with enabled VFs
| Newsgroups | org.kernel.vger.linux-pci,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
> pci_reset_function() and its locked and try variants are intended to
> provide a function-scoped reset. The bus and slot methods supporting
> this interface refuse when sibling or subordinate devices are present.
> SR-IOV VFs however, are not currently considered in this scope.
>
> Correct this oversight by testing for non-zero VF count in calls
> through the pci_reset_function() interfaces. This test needs to occur
> under device_lock to avoid races with .sriov_configure. It should
> also occur before pci_dev_save_and_disable() to avoid calling
> potentially destructive reset hooks. Tests are therefore added
> to each of pci_reset_function(), pci_reset_function_locked(), and
> pci_try_reset_function().
>
> The __pci_reset_function_locked() interface remains a low-level
> primitive depending on the caller to perform such tests as necessary.
> The vfio_pci_core use case of __pci_reset_function_locked() is pulled
> through with this test. Other use cases, such as xen-pciback, that
> don't obviously support or prevent binding to SR-IOV enabled PFs will
> need to decide whether VFs are possible and can be preserved.
> Additionally, direct callers of sriov_enable() that do not hold
> device_lock (lpfc) are considered a preexisting, non-compliance issue.
>
> Fixes: dd7cc44d0bce ("PCI: add SR-IOV API for Physical Function driver")
> Cc: [email protected]
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Alex Williamson <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1