Re: PCI resource allocation mismatch with BIOS

[Mika Westerberg <mika.westerberg@linux.intel.com>]

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@wunner.de> 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"

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".

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.