Hi, On Wed, Nov 30, 2022 at 08:47:38AM -0700, Alex Williamson wrote: > 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. Right, I think that already works. > > 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. Fair enough but if the firmware does not change the resource consumption then we would get back the same devices. I guess this is the use-case with these cards. > >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? I don't think there is. > Possibly if the host were booted with pci=realloc, Linux might expand > the resources to something it's happy with, allowing future re-scans. This was tried (sorry I did not mention that) and it did not work either because of the way Linux allocates the resource space. BIOS allocates "minimal" window that fulfills the alignment requirement so if we had just 16G+16M BARs then we would get 16G+16M bridge window aligned for that 16G. However, Linux tries to align the size of the window too so instead we get 16G aligned to 8G so 24G memory window. This does not fit to the resources BIOS allocated. With pci=realloc Linux tries to release the resources from the upper level bridges and re-allocates more but the IOV resources are put into the "additional" list so it is fine if those don't get allocated in the end. > 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, Sure, I will share dmesg from that system showing the initial allocation and the re-scan as soon as I get confirmation that there is nothing under embargo in there.
