+ Jakub + Alexander On Mon, 17 Mar 2025, Alex Williamson wrote: > On Mon, 17 Mar 2025 19:18:03 +0100 > Micha³ Winiarski wrote: > > On Fri, Mar 14, 2025 at 08:56:49AM -0600, Alex Williamson wrote: > > > On Fri, 7 Mar 2025 16:03:49 +0200 > > > Ilpo Järvinen wrote: > > > > > > > __resource_resize_store() attempts to release all resources of the > > > > device before attempting the resize. The loop, however, only covers > > > > standard BARs (< PCI_STD_NUM_BARS). If a device has VF BARs that are > > > > assigned, pci_reassign_bridge_resources() finds the bridge window still > > > > has some assigned child resources and returns -NOENT which makes > > > > pci_resize_resource() to detect an error and abort the resize. > > > > > > > > Change the release loop to cover all resources up to VF BARs which > > > > allows the resize operation to release the bridge windows and attempt > > > > to assigned them again with the different size. > > > > > > > > As __resource_resize_store() checks first that no driver is bound to > > > > the PCI device before resizing is allowed, SR-IOV cannot be enabled > > > > during resize so it is safe to release also the IOV resources. > > > > > > Is this true? pci-pf-stub doesn't teardown SR-IOV on release, which I > > > understand is done intentionally. Thanks, Thanks for reviewing. I'm sorry I just took Micha³'s word on this for granted so I didn't check it myself. I could amend __resource_resize_store() to return -EBUSY if SR-IOV is there despite no driver being present, but lets hear if Alexander or Jakub has some input on this. > > Is that really intentional? > > PCI warns when that scenario occurs: > > https://elixir.bootlin.com/linux/v6.13.7/source/drivers/pci/iov.c#L936 > > Yep, it warns. It doesn't prevent it from happening though. > > > I thought that the usecase is binding pci-pf-stub, creating VFs, and > > letting the driver be. > > But unbinding after creating VFs? What's the goal of that? > > Perhaps we're just missing .remove() in pci-pf-stub? > > I guess I don't actually know that leaving SR-IOV enabled was > intentional, maybe it was an oversight. The original commit only > mentions the case of a device that requires nothing but this shim as > the PF driver. A pci_warn() isn't much disincentive, the system might > already have taints. If it's something that we really want to show as > broken, it'd probably need to be a WARN_ON. Added Alexander and Jakub, perhaps they remember something or if there are caveats going either way. -- i.