All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Subject: Re: [PATCH 1/3] drm/xe/oa: Use xe_map layer
Date: Fri, 10 Apr 2026 17:49:03 -0700	[thread overview]
Message-ID: <877bqe8gow.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20260409231754.528518-2-ashutosh.dixit@intel.com>

On Thu, 09 Apr 2026 16:17:52 -0700, Ashutosh Dixit wrote:
>

Hi Umesh,

> +/* Because there is no iosys_map_copy_to_user() or copy_to_user_from_iomem() */
> +static int xe_oa_copy_to_user(struct xe_oa_stream *stream, void __user *dst, u32 head, u32 len)
> +{
> +	u32 __user *dptr = dst;
> +
> +	xe_gt_assert(stream->gt, len % 4 == 0);
> +
> +	for (int i = 0; i < len / 4; i++) {
> +		struct iosys_map *map = &stream->oa_buffer.bo->vmap;
> +		u32 val = xe_map_rd(stream->oa->xe, map, head, u32);
> +		int ret = put_user(val, dptr++);
> +
> +		if (ret)
> +			return ret;
> +		head += 4;
> +	}
> +
> +	return 0;
> +}

Unfortunately, with this copy_to_user() implementation we are seeing buffer
overflow, implying there is significant performance impact, even when OA
buffer is in system memory:

  Starting subtest: non-zero-reason
  Starting dynamic subtest: oag-0
  (xe_oa:6798) CRITICAL: Test assertion failure function test_non_zero_reason, file ../tests/intel/xe_oa.c:2693:
  (xe_oa:6798) CRITICAL: Failed assertion: !(oa_status & DRM_XE_OASTATUS_BUFFER_OVERFLOW)

That is, we are unable to read data at the rate at which HW is writing
data, causing buffer overrun.

Therefore in v3 I have basically reverted to the copy_to_user()
implementation of v1, except that I have taken the copy_to_user() out of
xe_oa.c and moved it to xe_map.h, to make that implementation "official"
(and OA code to strictly use the xe_map layer). This seems to be the best
approach to me, it avoids unnecessary copies and works correctly on all of
our systems of interest.

Also, the previous code, without this patch, is of course doing this exact
same thing, except that the use of the xe_map layer make these assumptions
explicit.

If you still don't think we should be doing this, I can try to get a second
opinion about this patch. Thanks.

  reply	other threads:[~2026-04-11  0:49 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-09 23:17 [PATCH v2 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-09 23:17 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-11  0:49   ` Dixit, Ashutosh [this message]
2026-04-13 18:05     ` Umesh Nerlige Ramappa
2026-04-13 22:06       ` Dixit, Ashutosh
2026-04-09 23:17 ` [PATCH 2/3] drm/xe/oa: Use drm_gem_mmap_obj for OA buffer mmap Ashutosh Dixit
2026-04-09 23:17 ` [PATCH 3/3] drm/xe/oa: Implement Wa_14026633728 Ashutosh Dixit
2026-04-09 23:25 ` ✓ CI.KUnit: success for drm/xe/oa: Wa_14026633728 (rev2) Patchwork
2026-04-10  0:15 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-10  2:07 ` ✗ Xe.CI.FULL: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2026-04-27 22:11 [PATCH v8 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-27 22:11 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-27 20:26 [PATCH v7 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-27 20:26 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-27 19:02 [PATCH v6 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-27 19:02 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-27 19:34   ` Umesh Nerlige Ramappa
2026-04-27 20:30     ` Dixit, Ashutosh
2026-04-25  0:14 [PATCH v5 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-25  0:14 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-27 19:23   ` Umesh Nerlige Ramappa
2026-04-15  2:03 [PATCH v4 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-15  2:03 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-24 21:05   ` Umesh Nerlige Ramappa
2026-04-24 23:56     ` Dixit, Ashutosh
2026-04-25  0:16       ` Dixit, Ashutosh
2026-04-27 18:27         ` Umesh Nerlige Ramappa
2026-04-27 19:04           ` Dixit, Ashutosh
2026-04-11  0:48 [PATCH v3 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-11  0:48 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-07  3:02 [PATCH 0/3] drm/xe/oa: Wa_14026633728 Ashutosh Dixit
2026-04-07  3:02 ` [PATCH 1/3] drm/xe/oa: Use xe_map layer Ashutosh Dixit
2026-04-07 22:49   ` Umesh Nerlige Ramappa
2026-04-08 15:32     ` Dixit, Ashutosh
2026-04-08 18:21       ` Umesh Nerlige Ramappa

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=877bqe8gow.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@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.