All of lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org,
	Stuart Summers <stuart.summers@intel.com>,
	Matt Roper <matthew.d.roper@intel.com>,
	Riana Tauro <riana.tauro@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	Tvrtko Ursulin <tursulin@ursulin.net>
Subject: Re: [PATCH v4 6/6] drm/xe/configfs: Add post context restore bb
Date: Fri, 12 Sep 2025 10:05:21 +0200	[thread overview]
Message-ID: <aMPUQcgJsZARb8P4@black.igk.intel.com> (raw)
In-Reply-To: <20250911-wa-bb-cmds-v4-6-c8f7e48f7eae@intel.com>

On Thu, Sep 11, 2025 at 12:36:30PM -0700, Lucas De Marchi wrote:
> Allow the user to specify commands to execute during a context restore.
> Currently it's possible to parse 2 types of actions:
> 
> 	- cmd: the instructions are added as is to the bb
> 	- reg: just use the address and value, without worrying about
> 	  encoding the right LRI instruction. This is possibly the most
> 	  useful use case, so added a dedicated action for that.
> 
> This also prepares for future BBs: mid context restore and rc6 context
> restore that can re-use the same parsing functions.

...

> @@ -123,11 +156,18 @@
>   *	# rmdir /sys/kernel/config/xe/0000:03:00.0/
>   */
>  
> +/* Similar to struct xe_bb, but not tied to HW (yet) */

Should I assume we plan to do it at some point?

> +struct wa_bb {
> +	u32 *cs;
> +	u32 len; /* in dwords */
> +};

...

> +static ssize_t wa_bb_show(struct xe_config_group_device *dev,
> +			  struct wa_bb wa_bb[static XE_ENGINE_CLASS_MAX],
> +			  char *data, size_t sz)
> +{
> +	char *p = data;
> +
> +	guard(mutex)(&dev->lock);
> +
> +	for (size_t i = 0; i < ARRAY_SIZE(engine_info); i++) {
> +		enum xe_engine_class ec = engine_info[i].engine_class;
> +		size_t len;
> +
> +		if (!wa_bb[ec].len)
> +			continue;
> +
> +		len = snprintf(p, sz, "%s:", engine_info[i].cls);
> +		if (!wa_bb_read_advance(data, &p, NULL, len, &sz))
> +			return -ENOBUFS;
> +
> +		for (size_t j = 0; j < wa_bb[ec].len; j++) {
> +			len = snprintf(p, sz, " %08x", wa_bb[ec].cs[j]);

Should we use '0x' prefix?

> +			if (!wa_bb_read_advance(data, &p, NULL, len, &sz))
> +				return -ENOBUFS;
> +		}
> +
> +		if (!wa_bb_read_advance(data, &p, "\n", 1, &sz))
> +			return -ENOBUFS;
> +	}
> +
> +	if (!wa_bb_read_advance(data, &p, "", 1, &sz))
> +		return -ENOBUFS;
> +
> +	/* Reserve one more to match check for '\0' */
> +	if (!data)
> +		p++;
> +
> +	return p - data;
> +}

...

> +static ssize_t parse_wa_bb_lines(const char *lines,
> +				 struct wa_bb wa_bb[static XE_ENGINE_CLASS_MAX])
> +{
> +	ssize_t dwords = 0, ret;
> +	const char *p;
> +
> +	for (p = lines; *p; p++) {

I found it to be zeroed page but does it gurantee termination at page
boundary? (just thinking out loud about overrun cases)

> +		const struct engine_info *info = NULL;
> +		u32 val, val2;
> +
> +		/* Also allow empty lines */
> +		p += strspn(p, " \t\n");
> +		if (!*p)
> +			break;
> +
> +		ret = parse_engine(p, " \t\n", NULL, &info);

Nit: Can we work without a double pointer? I've always found it easier to read.

> +		if (ret < 0)
> +			return ret;
> +
> +		p += ret;
> +		p += strspn(p, " \t");
> +
> +		if (str_has_prefix(p, "cmd")) {
> +			for (p += strlen("cmd"); *p;) {
> +				ret = parse_hex(p, &val);
> +				if (ret < 0)
> +					return -EINVAL;
> +				if (!ret)
> +					break;
> +
> +				p += ret;
> +				dwords++;
> +				wa_bb_append(&wa_bb[info->engine_class], val);
> +			}
> +		} else if (str_has_prefix(p, "reg")) {
> +			p += strlen("reg");
> +			ret = parse_hex(p, &val);
> +			if (ret <= 0)
> +				return -EINVAL;
> +
> +			p += ret;
> +			ret = parse_hex(p, &val2);
> +			if (ret <= 0)
> +				return -EINVAL;
> +
> +			p += ret;
> +			dwords += 3;
> +			wa_bb_append(&wa_bb[info->engine_class],
> +				     MI_LOAD_REGISTER_IMM | MI_LRI_NUM_REGS(1));
> +			wa_bb_append(&wa_bb[info->engine_class], val);
> +			wa_bb_append(&wa_bb[info->engine_class], val2);
> +		} else {
> +			return -EINVAL;
> +		}
> +	}
> +
> +	return dwords;
> +}

...

> +CONFIGFS_ATTR(, ctx_restore_post_bb);

I know this is alphabetic order but let's be consistent, either at the top ...

>  CONFIGFS_ATTR(, enable_psmi);
>  CONFIGFS_ATTR(, engines_allowed);
>  CONFIGFS_ATTR(, survivability_mode);
> @@ -379,6 +640,7 @@ static struct configfs_attribute *xe_config_device_attrs[] = {
>  	&attr_enable_psmi,
>  	&attr_engines_allowed,
>  	&attr_survivability_mode,
> +	&attr_ctx_restore_post_bb,

... or bottom.

>  	NULL,
>  };

...

> diff --git a/drivers/gpu/drm/xe/xe_lrc.c b/drivers/gpu/drm/xe/xe_lrc.c
> index f337954066f55..c706585611d55 100644
> --- a/drivers/gpu/drm/xe/xe_lrc.c
> +++ b/drivers/gpu/drm/xe/xe_lrc.c
> @@ -8,6 +8,7 @@
>  #include <generated/xe_wa_oob.h>
>  
>  #include <linux/ascii85.h>
> +#include <linux/panic.h>
>  
>  #include "instructions/xe_mi_commands.h"
>  #include "instructions/xe_gfxpipe_commands.h"
> @@ -1120,6 +1121,12 @@ static ssize_t setup_configfs_post_ctx_restore_bb(struct xe_lrc *lrc,
>  	if (count > max_len)
>  		return -ENOSPC;
>  
> +	/*
> +	 * This should be used only for tests and validation. Taint the kernel
> +	 * as anything could be submitted directly in context switches
> +	 */
> +	add_taint(TAINT_TEST, LOCKDEP_STILL_OK);

I know we add wa_bb support in this patch but perhaps this belongs to
previous patch?

Raag

>  	memcpy(cmd, user_batch, count * sizeof(u32));
>  	cmd += count;
>  
> 
> -- 
> 2.50.1
> 

  reply	other threads:[~2025-09-12  8:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-11 19:36 [PATCH v4 0/6] drm/xe: Add user commands to WA BB via configfs Lucas De Marchi
2025-09-11 19:36 ` [PATCH v4 1/6] drm/xe: Update workaround documentation Lucas De Marchi
2025-09-11 19:36 ` [PATCH v4 2/6] drm/xe/configfs: Fix documentation warning Lucas De Marchi
2025-09-11 19:36 ` [PATCH v4 3/6] drm/xe/configfs: Extract function to parse engine Lucas De Marchi
2025-09-11 19:36 ` [PATCH v4 4/6] drm/xe/configfs: Allow to select by class only Lucas De Marchi
2025-09-12  5:18   ` Raag Jadav
2025-09-12  5:30     ` Lucas De Marchi
2025-09-12  5:58       ` Raag Jadav
2025-09-11 19:36 ` [PATCH v4 5/6] drm/xe/lrc: Allow to add user commands on context switch Lucas De Marchi
2025-09-16 20:27   ` Rodrigo Vivi
2025-09-16 21:07     ` Lucas De Marchi
2025-09-16 21:16       ` Rodrigo Vivi
2025-09-16 21:19       ` Lucas De Marchi
2025-09-11 19:36 ` [PATCH v4 6/6] drm/xe/configfs: Add post context restore bb Lucas De Marchi
2025-09-12  8:05   ` Raag Jadav [this message]
2025-09-12 14:07     ` Lucas De Marchi
2025-09-12 16:56       ` Raag Jadav
2025-09-11 20:19 ` ✗ CI.checkpatch: warning for drm/xe: Add user commands to WA BB via configfs Patchwork
2025-09-11 20:20 ` ✓ CI.KUnit: success " Patchwork
2025-09-11 21:06 ` ✓ Xe.CI.BAT: " Patchwork
2025-09-12  3:16 ` ✗ Xe.CI.Full: failure " 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=aMPUQcgJsZARb8P4@black.igk.intel.com \
    --to=raag.jadav@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=stuart.summers@intel.com \
    --cc=tursulin@ursulin.net \
    --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.