Re: [PATCH V18 11/14] drm/xe/vram: Check bad_page_reservation policy in fault handler

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Page reservation is unconditionally disabled on non-Crescent Island platforms (like PVC), silently ignoring configfs settings.
--

commit e2ecbfdccfac5cd8843020d324241d927ec0f055
Author: Tejas Upadhyay <tejas.upadhyay@intel.com>

drm/xe/vram: Check bad_page_reservation policy in fault handler

This commit adds a check for the cached bad_page_reservation policy in the
VRAM address fault handler. If the policy is disabled, it logs the corrupted
address and returns -EOPNOTSUPP instead of offlining the page.

> diff --git a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> index b2b6c1bd2c555..24d1347542651 100644
> --- a/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> +++ b/drivers/gpu/drm/xe/xe_ttm_vram_mgr.c
> @@ -864,6 +864,12 @@ int xe_ttm_vram_handle_addr_fault(struct xe_device *xe, u64 addr)
>  	vram_mgr = &vr->ttm;
>  	mm = &vram_mgr->mm;
>  
> +	if (!xe->ras.bad_page_reservation) {
        ^^^^

[Severity: High]
Does this unintentionally disable page reservation on non-Crescent Island
platforms that support RAS?

Because xe_ras_init() only populates xe->ras.bad_page_reservation on
XE_CRESCENTISLAND, the cached value remains false (0) on other platforms like
PVC. As a result, this check will unconditionally evaluate to true on those
platforms, skipping page reservation and silently ignoring the configfs setting.

> +		drm_err(&xe->drm, "0x%llx is reported as corrupted address by HW\n",
> +			addr);
> +		return -EOPNOTSUPP;
> +	}
> +
>  	/* Reserve page at address */
>  	return xe_ttm_vram_reserve_page_at_addr(xe, addr - vr->dpa_base, vram_mgr, mm);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260826135136.204044-16-tejas.upadhyay@intel.com?part=11