Re: [PATCH v3 06/10] drm/xe/vsec: Support Crescent Island PMT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The VSEC PMT/Crashlog subsystem registration lacks an IS_SRIOV_VF() early return guard, allowing Virtual Functions to attempt registration of PF-only SOC_BASE MMIO resources.
--

--- Patch [6]: [PATCH v3 06/10] drm/xe/vsec: Support Crescent Island PMT ---
(Note: Due to system recitation restrictions, the standard inline-quoted
patch format has been altered. The following is a free-form summary of the
review findings instead of the usual inline comments.)

Commit: 375a8279959bc1d7613d31c9ae9881fa3baa2d18
Author: Michael J. Ruhl <michael.j.ruhl@intel.com>
Subject: drm/xe/vsec: Support Crescent Island PMT

This commit adds Crescent Island (CRI) discovery structure (DVSEC)
information to allow for Xe registration of PMT telemetry and crashlog.

[Severity: High]

This is a pre-existing issue, but I wanted to ask about the execution flow
in xe_vsec_init() within drivers/gpu/drm/xe/xe_vsec.c.

Does xe_vsec_init() need an IS_SRIOV_VF() early return guard to prevent
Virtual Functions from attempting to register PF-only resources?

The intel_vsec auxiliary device driver will attempt to read from restricted
offsets, such as BMG_DISCOVERY_OFFSET or CRI_DISCOVERY_OFFSET, which are
based on SOC_BASE. Since xe_vsec_init() is called unconditionally during
device probe, VFs might register the intel_vsec subsystem with headers
pointing directly to SOC_BASE.

Could this lead to MMIO timeouts or incorrect driver behavior when a
Virtual Function context attempts to access these PF-only registers?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824162317.2450380-12-michael.j.ruhl@intel.com?part=6