All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Harish Chegondi <harish.chegondi@intel.com>
Cc: <intel-xe@lists.freedesktop.org>,
	Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Subject: Re: [PATCH 1/1] drm/xe/eustall: Return EBADFD from read if EU stall registers get reset
Date: Fri, 12 Dec 2025 13:18:10 -0800	[thread overview]
Message-ID: <87zf7n4cx9.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <6d78578c015b12e7ae243727ca7ed4b93551075d.1765174462.git.harish.chegondi@intel.com>

On Sun, 07 Dec 2025 22:16:11 -0800, Harish Chegondi wrote:
>

Hi Harish,

> @@ -541,9 +541,24 @@ static ssize_t xe_eu_stall_stream_read_locked(struct xe_eu_stall_data_stream *st
>	size_t total_size = 0;
>	u16 group, instance;
>	unsigned int xecore;
> +	u32 base_reg_value;
>	int ret = 0;
>
>	mutex_lock(&stream->xecore_buf_lock);
> +	/* If a GT or engine reset happens during EU stall data sampling,
> +	 * all EU stall registers get reset to 0 and the cached values of
> +	 * EU stall data buffers' read and write pointers are out of sync
> +	 * with the register values. This can cause invalid data to be
> +	 * returned from read(). To prevent this, check the value of a
> +	 * EU stall base register. If it is zero, return -EBADFD. The
> +	 * user is expected to close the fd and open a new fd.
> +	 */
> +	base_reg_value = xe_gt_mcr_unicast_read_any(gt, XEHPC_EUSTALL_BASE);
> +	if (unlikely(!base_reg_value)) {
> +		xe_gt_dbg(gt, "EU stall base register has been reset to 0\n");
> +		mutex_unlock(&stream->xecore_buf_lock);
> +		return -EBADFD;
> +	}

Since we are introducing an extra register read every read() call here,
does it make sense to first check if there's a real userland need for this?
And actually have a UMD PR which will consume this -EBADFD return value,
before we merge this?

Thanks.
--
Ashutosh

  parent reply	other threads:[~2025-12-12 21:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-08  6:16 [PATCH 1/1] drm/xe/eustall: Return EBADFD from read if EU stall registers get reset Harish Chegondi
2025-12-08  6:32 ` ✓ CI.KUnit: success for series starting with [1/1] " Patchwork
2025-12-08  7:56 ` ✓ Xe.CI.BAT: " Patchwork
2025-12-08  8:48 ` ✗ Xe.CI.Full: failure " Patchwork
2025-12-12 21:18 ` Dixit, Ashutosh [this message]
2025-12-16 23:53   ` [PATCH 1/1] " Harish Chegondi
2025-12-18 19:53 ` Dixit, Ashutosh
2025-12-22 22:37   ` Harish Chegondi
2025-12-23  5:08     ` Dixit, Ashutosh
2025-12-23 23:39       ` Harish Chegondi
2025-12-24  1:47         ` Dixit, Ashutosh
  -- strict thread matches above, loose matches on Subject: below --
2025-10-01  6:38 Harish Chegondi

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=87zf7n4cx9.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=harish.chegondi@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=umesh.nerlige.ramappa@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 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.