From: "Mallesh, Koujalagi" <mallesh.koujalagi@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 6/6] drm/xe/log: Relax location ID recognition
Date: Wed, 9 Sep 2026 14:30:36 +0530 [thread overview]
Message-ID: <f0f7e21a-6d90-498c-92bc-e8227a393d8d@intel.com> (raw)
In-Reply-To: <20260904170531.516-7-michal.wajdeczko@intel.com>
[-- Attachment #1: Type: text/plain, Size: 4402 bytes --]
On 04-09-2026 10:35 pm, Michal Wajdeczko wrote:
> It turned out that during early probe phase, VFs use detached from
> the xe_device, temporary xe_gt objects, which when used as location
> in xe_log() macros, will be treated by the dmesg decoration code as
> bogus, possibly triggering a WARN, and the output will look like:
>
> [drm] *ERROR* SIGID=104 (-ETIMEDOUT) LOC3.0? GUC: MMIO request ...
>
> instead of expected:
>
> [drm] *ERROR* SIGID=104 (-ETIMEDOUT) Tile0: GT0: GUC: MMIO request ...
>
> Relax the tile/GT id validation and instead of looking for the real
> objects, only check if encoded id is within the range of possible
> tiles or GTs on the current xe device, using data from the device
> descriptor rather then the object list.
nit: 'rather than'
Please mention invalid id case, how it's going to render like
Warn + Tile3? GT9? now.
>
> Fixes: 1151b9f6f465 ("drm/xe/log: Add component/location decorations to dmesg")
> Signed-off-by: Michal Wajdeczko<michal.wajdeczko@intel.com>
> ---
> Cc: Rodrigo Vivi<rodrigo.vivi@intel.com>
> Cc: Mallesh Koujalagi<mallesh.koujalagi@intel.com>
> ---
> drivers/gpu/drm/xe/xe_log.c | 40 ++++++++++++++++++++++++-------------
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_log.c b/drivers/gpu/drm/xe/xe_log.c
> index 5549ef6966fd..29eb16db3320 100644
> --- a/drivers/gpu/drm/xe/xe_log.c
> +++ b/drivers/gpu/drm/xe/xe_log.c
> @@ -10,6 +10,7 @@
>
> #include "xe_device.h"
> #include "xe_log.h"
> +#include "xe_pci_types.h"
> #include "xe_printk.h"
>
> static void log_emit_cper(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
> @@ -52,18 +53,24 @@ static const char *log_component_prefix(u32 component)
> return component ? log_unknown_component_prefix(component) : "";
> }
>
> -static struct xe_gt *get_gt_safe(struct pci_dev *pdev, u8 id)
> +static bool allowed_tile_id(struct xe_device *xe, u8 tile_id)
> {
> - struct xe_device *xe = pdev_to_xe_device(pdev);
> + return tile_id < 1 + xe->desc->max_remote_tiles;
> +}
>
> - return xe ? xe_device_get_gt(xe, id) : NULL;
> +static bool allowed_gt_id(struct xe_device *xe, u8 gt_id)
> +{
> + return gt_id < (1 + xe->desc->max_remote_tiles) * xe->desc->max_gt_per_tile;
> }
>
> -static struct xe_tile *get_tile_safe(struct pci_dev *pdev, u8 id)
> +static u8 gt_id_to_tile_id(struct xe_device *xe, u8 gt_id)
> {
> - struct xe_device *xe = pdev_to_xe_device(pdev);
> + return gt_id / xe->desc->max_gt_per_tile;
hmm, we need to check max_gt_per_tile should not be zero to avoid hard
Oops. I know in real scenario, max_gt_per_tile
value is greater than 0 and less than equal to XE_MAX_GT_PER_TILE,
however rogue user can write kunit test case and manipulate it, to avoid
such scenario, we need to handle it.
Thanks,
-/Mallesh
> +}
>
> - return xe && id < xe->info.tile_count ? &xe->tiles[id] : NULL;
> +static const char *location_suffix(bool valid)
> +{
> + return valid ? ":" : "?";
> }
>
> static const char *log_location_prefix(struct pci_dev *pdev, u32 location, char *buf, size_t size)
> @@ -76,17 +83,22 @@ static const char *log_location_prefix(struct pci_dev *pdev, u32 location, char
> goto unrecognized;
> strscpy(buf, "", size);
> } else if (type == XE_LOG_LOCATION_TYPE_TILE) {
> - struct xe_tile *tile = get_tile_safe(pdev, id);
> + struct xe_device *xe = xe_any_to_xe(pdev);
> + bool valid = xe ? allowed_tile_id(xe, id) : false;
> + const char *pad = location_suffix(valid);
>
> - if (!tile)
> - goto unrecognized;
> - snprintf(buf, size, "Tile%u: ", id);
> + pci_WARN(pdev, !valid && IS_ENABLED(CONFIG_DRM_XE_DEBUG),
> + "LOG: invalid tile identifier: %u\n", id);
> + snprintf(buf, size, "Tile%u%s ", id, pad);
> } else if (type == XE_LOG_LOCATION_TYPE_GT) {
> - struct xe_gt *gt = get_gt_safe(pdev, id);
> + struct xe_device *xe = xe_any_to_xe(pdev);
> + bool valid = xe ? allowed_gt_id(xe, id) : false;
> + const char *pad = location_suffix(valid);
> + u8 tile_id = xe ? gt_id_to_tile_id(xe, id) : 0;
>
> - if (!gt)
> - goto unrecognized;
> - snprintf(buf, size, "Tile%u: GT%u: ", gt->tile->id, id);
> + pci_WARN(pdev, !valid && IS_ENABLED(CONFIG_DRM_XE_DEBUG),
> + "LOG: invalid GT identifier: %u\n", id);
> + snprintf(buf, size, "Tile%u%s GT%u%s ", tile_id, pad, id, pad);
> } else {
> goto unrecognized;
> }
[-- Attachment #2: Type: text/html, Size: 5690 bytes --]
next prev parent reply other threads:[~2026-09-09 9:01 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 17:05 [PATCH 0/6] drm/xe/log: Relax location ID recognition Michal Wajdeczko
2026-09-04 17:05 ` [PATCH 1/6] drm/xe: Drop unused parameter from xe_info_init Michal Wajdeczko
2026-09-04 18:09 ` Rodrigo Vivi
2026-09-05 13:04 ` Gustavo Sousa
2026-09-04 17:05 ` [PATCH 2/6] drm/xe: Keep reference to device descriptor Michal Wajdeczko
2026-09-04 17:14 ` sashiko-bot
2026-09-05 13:52 ` Gustavo Sousa
2026-09-07 19:30 ` Michal Wajdeczko
2026-09-11 11:25 ` Michal Wajdeczko
2026-09-11 16:36 ` Gustavo Sousa
2026-09-04 17:05 ` [PATCH 3/6] drm/xe: Drop redundant parameters from xe_info_init_early Michal Wajdeczko
2026-09-05 13:54 ` Gustavo Sousa
2026-09-04 17:05 ` [PATCH 4/6] drm/xe: Drop redundant parameter from xe_probe_info_early Michal Wajdeczko
2026-09-05 13:55 ` Gustavo Sousa
2026-09-04 17:05 ` [PATCH 5/6] drm/xe: Drop redundant parameter from xe_probe_info and friends Michal Wajdeczko
2026-09-05 13:58 ` Gustavo Sousa
2026-09-04 17:05 ` [PATCH 6/6] drm/xe/log: Relax location ID recognition Michal Wajdeczko
2026-09-04 18:44 ` Rodrigo Vivi
2026-09-09 9:00 ` Mallesh, Koujalagi [this message]
2026-09-09 9:42 ` Michal Wajdeczko
2026-09-09 11:02 ` Mallesh, Koujalagi
2026-09-09 13:01 ` Michal Wajdeczko
2026-09-04 17:13 ` ✓ CI.KUnit: success for " Patchwork
2026-09-04 17:52 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-05 1: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=f0f7e21a-6d90-498c-92bc-e8227a393d8d@intel.com \
--to=mallesh.koujalagi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.wajdeczko@intel.com \
--cc=rodrigo.vivi@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox