On Wed, 30 Nov 2022 09:57:18 +0200 Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > Hi, > > On Wed, Nov 30, 2022 at 08:43:47AM +0100, Lukas Wunner wrote: > > On Tue, Nov 29, 2022 at 09:12:49AM -0700, Alex Williamson wrote: > > > On Tue, 29 Nov 2022 17:06:26 +0100 Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > > On Tue, Nov 29, 2022 at 08:46:46AM -0700, Alex Williamson wrote: > > > > > Maybe the elephant in the room is why it's apparently such common > > > > > practice to need to perform a hard reset these devices outside of > > > > > virtualization scenarios... > > > > > > > > These GPUs are used as accelerators in cloud environments. > > > > > > > > They're reset to a pristine state when handed out to another tenant > > > > to avoid info leaks from the previous tenant. > > > > > > > > That should be a legitimate usage of PCIe reset, no? > > > > > > Absolutely, but why the whole switch? Thanks, > > > > The reset is propagated down the hierarchy, so by resetting the > > Switch Upstream Port, it is guaranteed that all endpoints are > > reset with just a single operation. Per PCIe r6.0.1 sec 6.6.1: > > > > "For a Switch, the following must cause a hot reset to be sent > > on all Downstream Ports: > > [...] > > Receiving a hot reset on the Upstream Port" This was never in doubt. > Adding here the reason I got from the GPU folks: > > In addition to the use case when the GPU is reset when switched to > another tenant, this is used for recovery. The "first level" recovery is > handled by the graphics driver that does Function Level Reset but if > that does not work data centers may trigger reset at higher level (root > port or switch upstream port) to reset the whole card. So called "big > hammer". Ok, so the first level issue can be solved by the reset_method attribute, allowing userspace to trigger a SBR for a signle function endpoint rather than an FLR (though this might suggest some hardware issues in the FLR implementation). This will save and restore the device config space, so there should be no resource reallocation issues. > There is another use case too - firmware upgrade. This allows data > centers to upgrade firmware on those cards without need to reboot - they > just reset the whole thing to make it run the new firmware. The above can also be used for this, so long as the firmware update only targets the GPU and device config space layout and features is not modified by the update. This touches on a long standing issue Bjorn has had with performing bus resets where we assume we get back essentially the same devices after the reset. That's not guaranteed with a pending firmware update. >From the logs in this case, I notice that the BIOS didn't assigned the ROM BAR for the GPU while Linux did when re-scanning. That's a different address space from the SR-IOV BARs, so doesn't explain this failure, but I wonder if there's another resource in the hierarchy that the BIOS didn't program, ex. BAR0 on the upstream switch maybe? Possibly if the host were booted with pci=realloc, Linux might expand the resources to something it's happy with, allowing future re-scans. Otherwise I think we'd need a log of all BIOS vs Linux resource allocations from the root port down to see what might be the issue with the rescan. Thanks, Alex
