On Tue, Nov 05, 2024 at 01:28:39PM +0100, Niklas Schnelle wrote: > On Mon, 2024-11-04 at 10:01 -0700, Keith Busch wrote: > > On Mon, Nov 04, 2024 at 10:44:23AM +0100, Niklas Schnelle wrote: > > > > > > One more question though, what would happen with this reset for a bus > > > with an SR-IOV device with more than 256 VFs i.e. where > > > pci_iov_virtfn_bus() returns anything other than 0. I'm guessing since > > > VFs are physically still controlled by the bridge all VFs would be > > > reset but at the same time virtfn_add_bus() sets the bridge device for > > > the added bus as NULL so I think it might look odd in sysfs, sadly I > > > don't have such a device to test with. Still, this might actually be an > > > argument for having the attribute on the bridge. > > > > I assume everything is reset at the PCI level. > > > > Are you asking what the kernel does? I don't think it does anything > > special with SR-IOV functions. Those pci_dev's aren't attached to the > > bridge pci_dev; you have to go through the pci_bus' children instead. > > > > I just want to make sure we're okay with the behavior with such VFs as > it seems like the one case where a reset via the bridge affects PCI > functions which aren't attached to the bridge pci_dev otherwise. And > for example as I understand it these would not be covered by the > pci_bus_save_and_disable_locked(). Well, it's no different than doing FLR to the PF while VFs are configured, which is existing behavior, so I think it's okay. The PF's SRIOV state still gets restored to the end of the reset. The VFs themselves don't get saved and locked, though. But again, this new patch is following how it already works for other reset methods.
