From: sashiko-bot@kernel.org
To: "Nareshkumar Gollakoti" <naresh.kumar.g@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v4 7/7] drm/xe/guc: capture additional engine state registers
Date: Mon, 12 Oct 2026 15:07:12 +0000 [thread overview]
Message-ID: <sashiko-outbox-168316@kernel.org> (raw)
In-Reply-To: <20261012145237.3788198-8-naresh.kumar.g@intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] xe: missing GuC capture registers for video and pre-Xe3p render engines
- [Medium] xe: invalid MMIO accesses during GuC error capture due to mixed BCS/RCS registers
--
commit 5e669b4655462fa28596fd46c77d07300abb8f59
Author: Nareshkumar Gollakoti <naresh.kumar.g@intel.com>
drm/xe/guc: capture additional engine state registers
This patch adds a wider set of engine state registers to the GuC error capture
to improve post-mortem debugging of engine hangs and reset-related failures.
> diff --git a/drivers/gpu/drm/xe/xe_guc_capture.c b/drivers/gpu/drm/xe/xe_guc_capture.c
> index 6a20eab0f8204..b3c42052b70bb 100644
> --- a/drivers/gpu/drm/xe/xe_guc_capture.c
> +++ b/drivers/gpu/drm/xe/xe_guc_capture.c
> @@ -127,11 +127,7 @@ struct __guc_capture_parsed_output {
> { RING_START(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> { RING_START_UDW(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_START"}, \
> { RING_DMA_FADD(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> - { RING_DMA_FADD_UDW(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_DMA_FADD"}, \
> - { RING_EXECLIST_STATUS_LO(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> - { RING_EXECLIST_STATUS_HI(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_EXECLIST_STATUS"}, \
> - { RING_EXECLIST_SQ_CONTENTS_LO(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> - { RING_EXECLIST_SQ_CONTENTS_HI(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_EXECLIST_SQ_CONTENTS"}
> + { RING_DMA_FADD_UDW(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_DMA_FADD"}
>
> #define COMMON_XELP_RC_CLASS \
> { RCU_MODE, REG_32BIT, 0, 0, 0, "RCU_MODE"}
[Severity: Medium]
When removing the execlist registers from COMMON_BASE_ENGINE_INSTANCE,
does this break the capture for engines that rely solely on the common list?
Since the new XE_BCS_RCS_ENGINE_INSTANCE macro is only added to the Blitter
and Xe3p Render lists, this leaves xe_rc_inst_regs (pre-Xe3p render/compute),
xe_vd_inst_regs (video), xe_vec_inst_regs (video enhance), and
xe_lp_gsc_inst_regs without any execlist status tracking during a GuC error
capture.
[ ... ]
> @@ -150,6 +146,32 @@ struct __guc_capture_parsed_output {
> #define XE3P_BASE_ENGINE_INSTANCE \
> { RING_CSMQDEBUG(0), REG_32BIT, 0, 0, 0, "CSMQDEBUG"}
>
> +#define XE3P_RC_SLICE_INSTANCE \
> + { FF_SLICE_CS_CHICKEN1(0), REG_32BIT, 0, 0, 0, "FF_SLICE_CS_CHICKEN1"}, \
> + { FF_SLICE_CS_CHICKEN2(0), REG_32BIT, 0, 0, 0, "FF_SLICE_CS_CHICKEN2"}
> +
> +#define XE_BCS_RCS_ENGINE_INSTANCE \
> + { RING_EXECLIST_STATUS_LO(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> + { RING_EXECLIST_STATUS_HI(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_EXECLIST_STATUS"}, \
> + { RING_EXECLIST_SQ_CONTENTS_LO(0), REG_64BIT_LOW_DW, 0, 0, 0, NULL}, \
> + { RING_EXECLIST_SQ_CONTENTS_HI(0), REG_64BIT_HI_DW, 0, 0, 0, "RING_EXECLIST_SQ_CONTENTS"}, \
> + { RESET_CTRL(0), REG_32BIT, 0, 0, 0, "RESET_CTRL"}, \
> + { RING_CSBEFSM3(0), REG_32BIT, 0, 0, 0, "RING_CSBEFSM3"}, \
> + { RING_CSFESM(0), REG_32BIT, 0, 0, 0, "RING_CSFESM"}, \
> + { RING_CSFESM2(0), REG_32BIT, 0, 0, 0, "RING_CSFESM2"}, \
> + { RING_CSFESM3(0), REG_32BIT, 0, 0, 0, "RING_CSFESM3"}, \
> + { RING_CSPWRFSM(0), REG_32BIT, 0, 0, 0, "RING_CSPWRFSM"}, \
> + { RING_CSBEFSM(0), REG_32BIT, 0, 0, 0, "RING_CSBEFSM"}, \
> + { BCS_SWCTRL(0), REG_32BIT, 0, 0, 0, "BCS_SWCTRL"}, \
> + { RING_CSFE_GLB_CHICKEN3(0), REG_32BIT, 0, 0, 0, "RING_CSFE_GLB_CHICKEN3"}, \
> + { RING_PSMI_CTL(0), REG_32BIT, 0, 0, 0, "RING_PSMI_CTL"}, \
> + { RING_INSTPS(0), REG_32BIT, 0, 0, 0, "RING_INSTPS"}, \
> + { RING_BB_ADDR_DIFF(0), REG_32BIT, 0, 0, 0, "RING_BB_ADDR_DIFF"}, \
> + { RING_BB_STATE(0), REG_32BIT, 0, 0, 0, "RING_BB_STATE"}, \
> + { CS_DEBUG_MODE1(0), REG_32BIT, 0, 0, 0, "CS_DEBUG_MODE1"}, \
> + { CS_CHICKEN1(0), REG_32BIT, 0, 0, 0, "CS_CHICKEN1"}, \
> + { CS_PREEMPTION_STATUS(0), REG_32BIT, 0, 0, 0, "CS_PREEMPTION_STATUS"}
> +
> /* XE_LP Global */
> static const struct __guc_mmio_reg_descr xe_lp_global_regs[] = {
> COMMON_XELP_BASE_GLOBAL,
[ ... ]
> @@ -189,6 +211,7 @@ static const struct __guc_mmio_reg_descr xe_vec_inst_regs[] = {
> /* Blitter Per-Engine-Instance */
> static const struct __guc_mmio_reg_descr xe_blt_inst_regs[] = {
> COMMON_BASE_ENGINE_INSTANCE,
> + XE_BCS_RCS_ENGINE_INSTANCE,
> };
>
> /* XE_LP - GSC Per-Engine-Instance */
> @@ -200,6 +223,8 @@ static const struct __guc_mmio_reg_descr xe_lp_gsc_inst_regs[] = {
> static const struct __guc_mmio_reg_descr xe3p_rc_inst_regs[] = {
> COMMON_BASE_ENGINE_INSTANCE,
> XE3P_BASE_ENGINE_INSTANCE,
> + XE_BCS_RCS_ENGINE_INSTANCE,
> + XE3P_RC_SLICE_INSTANCE,
> };
>
> /*
[Severity: Medium]
Does mixing Blitter and Render exclusive registers into a single macro cause
invalid MMIO accesses?
BCS_SWCTRL is Blitter-specific, while CS_CHICKEN1, CS_DEBUG_MODE1, and
CS_PREEMPTION_STATUS are Render-specific.
Because XE_BCS_RCS_ENGINE_INSTANCE is added to both xe_blt_inst_regs and
xe3p_rc_inst_regs, the GuC error capture will attempt to read unimplemented
MMIO addresses (Blitter offsets on Render engines and vice versa) during a
hang.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012145237.3788198-1-naresh.kumar.g@intel.com?part=7
next prev parent reply other threads:[~2026-10-12 15:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 14:52 [PATCH v4 0/7] drm/xe: Capture additional HW register state in devcoredump Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 1/7] drm/xe/devcoredump: Capture GT fuse registers " Nareshkumar Gollakoti
2026-10-12 15:02 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 2/7] drm/xe/devcoredump: Add GuC register snapshot to devcoredump Nareshkumar Gollakoti
2026-10-12 15:03 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 3/7] drm/xe/guc: Print register addresses in capture snapshot output Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 4/7] drm/xe: dump GAM page fault report registers in devcoredump Nareshkumar Gollakoti
2026-10-12 15:02 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 5/7] drm/xe/guc: add TDL, SLICE gfx registers to capture list Nareshkumar Gollakoti
2026-10-12 14:52 ` [PATCH v4 6/7] drm/xe: capture L3 node status registers in devcoredump Nareshkumar Gollakoti
2026-10-12 15:06 ` sashiko-bot
2026-10-12 14:52 ` [PATCH v4 7/7] drm/xe/guc: capture additional engine state registers Nareshkumar Gollakoti
2026-10-12 15:07 ` sashiko-bot [this message]
2026-10-12 18:56 ` ✗ CI.checkpatch: warning for drm/xe: Capture additional HW register state in devcoredump (rev4) Patchwork
2026-10-12 18:58 ` ✓ CI.KUnit: success " Patchwork
2026-10-12 22:04 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-13 4:36 ` ✓ Xe.CI.FULL: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-168316@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=naresh.kumar.g@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.