Re: [PATCH] drm/xe/pf: Move VFs reprovisioning to worker

[Michal Wajdeczko <michal.wajdeczko@intel.com>]

On 27.01.2025 18:07, Summers, Stuart wrote:
> On Sat, 2025-01-25 at 22:55 +0100, Michal Wajdeczko wrote:
>> Since the GuC is reset during GT reset, we need to re-send the
>> entire SR-IOV provisioning configuration to the GuC. But since
>> this whole configuration is protected by the PF master mutex and
>> we can't avoid making allocations under this mutex (like during
>> LMEM provisioning), we can't do this reprovisioning from gt-reset
>> path if we want to be reclaim-safe. Move VFs reprovisioning to a
>> async worker that we will start from the gt-reset path.
> 
> Admittedly I don't fully understand the PF restart flow here from
> userspace. Is there some race condition we need to check for whether
> GuC completes base configuration before the PF config comes through? Is
> it possible we can get into either some deadlock between the native
> init and the PF init or start running content on some engines in native
> mode before PF completes?

Even if due to a race we start running PF content on engines before we
finish GuC reconfiguration from native to SRIOV mode, then that content
may just run a little longer than before a reset, due to initial
"infinity" execution quantum or preemption timeout settings, which in
SRIOV mode were likely reconfigured to a smaller values.

Also any race with new provisioning requests from the user space should
be harmless since during a PF restart we will resend whole SRIOV
configuration, including any latest changes done between GT reset and PF
restart.

- Michal