Re: [PATCH 2/2] drm/xe/xe_guc: Skip GuC reset post SBR

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Returning 0 from xe_guc_reset() when the device is in PCI reset falsely signals success, causing a racing GT reset worker to attempt massive MMIO access on a disconnected device.
--

commit cd9fc028eb46b88c6e7e520f4ef7e342f490d472
Author: Riana Tauro <riana.tauro@intel.com>

drm/xe/xe_guc: Skip GuC reset post SBR

Secondary Bus Reset causes VRAM and hardware state loss. This patch skips
GuC reset during teardown when the device is in PCI reset to avoid accessing
the device in an unknown state.

> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index c7f8bbd4cb927..2c7f411b89a79 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -986,6 +986,11 @@ int xe_guc_reset(struct xe_guc *guc)
>  	u32 guc_status, gdrst;
>  	int ret;
>  
> +	if (xe_device_is_in_reset(gt_to_xe(gt))) {
> +		xe_gt_dbg(gt, "Skipping GuC reset, device is in reset\n");
> +		return 0;
> +	}
> +

[Severity: High]
Could returning 0 here falsely signal a successful reset to callers?

When a GT reset worker (like do_gt_restart) races with a PCI error handler,
the worker might pass its initial reset checks before the PCI handler sets
the in_reset flag. If the worker then reaches xe_guc_reset() and receives 0
(success) because the device is in reset, it appears to proceed with MMIO
initialization (via xe_uc_load_hw()).

Since the device is disconnected or undergoing a Secondary Bus Reset,
would this lead to unintentional and extensive MMIO accesses, potentially
causing PCIe bus hangs, AER cascades, and multi-second thread hangs in
guc_wait_ucode()? Would returning an error code (like -ENODEV) safely abort
the racing GT reset worker while still being handled gracefully by teardown
paths like guc_fini_hw()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260828113104.319843-4-riana.tauro@intel.com?part=2