On Fri, Oct 25, 2024 at 11:57:25AM -0500, Bjorn Helgaas wrote: > [+cc Alex, Amey, Raphael] > > On Fri, Oct 25, 2024 at 07:50:21AM -0700, Keith Busch wrote: > > From: Keith Busch <kbusch@xxxxxxxxxx> > > > > Attempting a bus reset on an end device only works if it's the only > > function on or below that bus. > > > > Provide an attribute on the pci_bus device that can perform the > > secondary bus reset. This makes it possible for a user to safely reset > > multiple devices in a single command using the secondary bus reset > > method. > > I confess to being a little ambivalent or even hesitant about > operations on the pci_bus (as opposed to on a pci_dev), but I can't > really articulate a great reason, other than the fact that the "bus" > is kind of abstract and from a hardware perspective, the *devices* are > the only things we can control. If you prefer, this could probably be a pci_dev attribute specific to bridges. Maybe we call it "reset_subordinate" to make it different than the existing "reset" attribute. > I assume this is useful in some scenario. I guess this is root-only, > so there's no real concern about whether all the devices are used by > the same VM or in the same IOMMU group or anything? Yes, definitely root only. The concern for misuse is real, so must be used carefully. If you have binded drivers that are not ready for this, it may get confused. The same thing could happen with existing function-level resets though too. Making this operate on the bus just has potentially larger blast radius if you reset the wrong bus. It is still useful. Ioctl VFIO_DEVICE_PCI_HOT_RESET also eventually calls __pci_reset_bus(), but this gets the same thing without having to bind all the functions to vfio.
