[PATCH 2/2] drm/xe/vf: Don't update GuC reset policy when changing wedged mode

Michal Wajdeczko michal.wajdeczko at intel.com
Thu Apr 3 11:05:16 UTC 2025



On 03.04.2025 11:41, Lukasz Laguna wrote:
> Prevent the VF from attempting to update the GuC reset policy when
> changing the wedged mode, as this operation is not supported for VFs.
> 
> Log a message to indicate that GuC may still cause engine reset even
> with wedged_mode=2.
> 
> Signed-off-by: Lukasz Laguna <lukasz.laguna at intel.com>
> ---
>  drivers/gpu/drm/xe/xe_debugfs.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xe/xe_debugfs.c b/drivers/gpu/drm/xe/xe_debugfs.c
> index d0503959a8ed..062668d02365 100644
> --- a/drivers/gpu/drm/xe/xe_debugfs.c
> +++ b/drivers/gpu/drm/xe/xe_debugfs.c
> @@ -171,6 +171,11 @@ static ssize_t wedged_mode_set(struct file *f, const char __user *ubuf,
>  
>  	xe->wedged.mode = wedged_mode;
>  
> +	if (IS_SRIOV_VF(xe)) {
> +		drm_info_once(&xe->drm, "VF can't change GuC's engine reset policy. GuC may still cause engine reset even with wedged_mode=2\n");

never use drm_info_once() logs for places where multiple different
devices can be reached, as then doing something similar on next device
there will be no trace at all

also should we change xe->wedged.mode if it is N/A for VF?

btw, what is our approach if someone on the PF already set some policy
on GuC will not do engine reset? or it is n/a after a VF switch?

> +		return size;

shouldn't we return -EPERM instead?

> +	}
> +
>  	xe_pm_runtime_get(xe);
>  	for_each_gt(gt, xe, id) {
>  		ret = xe_guc_ads_scheduler_policy_toggle_reset(&gt->uc.guc.ads);



More information about the Intel-xe mailing list