[PATCH V1] nvme-pci: disable SR-IOV VFs on driver unbind

[Leon Romanovsky]

On Tue, Jan 27, 2026 at 05:09:12PM -0600, Bjorn Helgaas wrote:
> [+cc Jakub, author of 38972375ef7b ("PCI/IOV: Reset total_VFs limit
> after detaching PF driver"), which added the message]
> 
> On Tue, Jan 27, 2026 at 08:00:42PM +0200, Leon Romanovsky wrote:
> > On Tue, Jan 27, 2026, at 18:06, Keith Busch wrote:
> > > On Tue, Jan 27, 2026 at 04:31:43PM +0200, Leon Romanovsky wrote:
> > >> On Tue, Jan 27, 2026 at 09:48:07AM +0100, Christoph Hellwig wrote:
> > >> > On Tue, Jan 27, 2026 at 03:33:44PM +0800, Qinyun Tan wrote:
> > >> > > The NVMe PCI driver exports the sriov_configure callback via
> > >> > > pci_sriov_configure_simple(), which allows userspace to enable SR-IOV
> > >> > > VFs through sysfs. However, when the PF driver is unbound, the driver
> > >> > > does not disable SR-IOV, leaving VFs orphaned in the system.
> > >> > 
> > >> > That sounds dangerous.
> > >> 
> > >> It is not. In a real SR-IOV device, VFs are created by the hardware and
> > >> are independent of their PF. There are several use cases where an
> > >> operator unbinds the PF and reuses it to improve overall device
> > >> utilization.
> > >
> > > If this is expected, should the warn message "driver left SR-IOV
> > > enabled after remove" be downgraded to 'info' level?
> > 
> > It is not important, no one complained about it. People who unbind
> > PF, simply ignore this warning.
> > 
> > BTW, the use case which I presented is for SR-IOV handled by
> > drivers. Maybe VFs created by NVMe are different here and they must
> > be destroyed.
> 
> If it's to be expected, I do think 'info' would be more appropriate,
> if nothing else as an indication to code readers that nothing is
> wrong.  Or maybe even no message at all.

The issue is that not all devices are created equal. Some devices from major
vendor rely on messages sent from the VF to the PF, and expect the PF driver
to perform certain configuration steps in response. These devices must disable
SR-IOV when the PF is unbound.

>From one side, for users of such hardware, this message is important.
>From another, for many other devices, this message is not important.

Like Jakub, I don't have any preference here.

Thanks