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

[Bjorn Helgaas]

[+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.  Or maybe the fact that we
reset the driver_max_VFs value is of more interest.

Bjorn