From: Matthew Brost <matthew.brost@intel.com>
To: <sashiko-reviews@lists.linux.dev>
Cc: Honglei Huang <honghuan@amd.com>,
<dri-devel@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH v3 5/6] drm/gpusvm: keep a single DMA mapping inline for THP
Date: Fri, 4 Sep 2026 10:13:30 -0700 [thread overview]
Message-ID: <apr8Ok1NeYrUCcbC@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <20260904165805.13BF21F00A3D@smtp.kernel.org>
On Fri, Sep 04, 2026 at 04:58:04PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Incompatible pointer type in `xe_pt_stage_bind` when `CONFIG_DRM_XE_GPUSVM` is disabled, leading to a build failure.
> --
>
> commit ba41c31a99e11c5fd960b8101a85807f5290cd76
> Author: Honglei Huang <honghuan@amd.com>
>
> drm/gpusvm: keep a single DMA mapping inline for THP
>
> This commit optimizes drm_gpusvm_get_pages() by inlining a single DMA
> mapping entry for Transparent Huge Pages (THP), reducing memory overhead.
> It updates the accessors, including xe_pt_stage_bind() paths, to safely
> handle the new union containing the inline address.
>
> > diff --git a/drivers/gpu/drm/xe/xe_pt.c b/drivers/gpu/drm/xe/xe_pt.c
> > index 5d990c1c3740a..96ea9735f34ce 100644
> > --- a/drivers/gpu/drm/xe/xe_pt.c
> > +++ b/drivers/gpu/drm/xe/xe_pt.c
> > @@ -831,7 +831,7 @@ xe_pt_stage_bind(struct xe_tile *tile, struct xe_vma *vma,
> > return -EAGAIN;
> > }
> > if (xe_svm_range_has_dma_mapping(range)) {
> > - xe_res_first_dma(range->pages.dma_addr, 0,
> > + xe_res_first_dma(drm_gpusvm_pages_first_dma(&range->pages), 0,
>
> [Severity: Low]
> Will this cause a build failure when compiling the driver with
> CONFIG_DRM_XE_GPUSVM disabled?
>
> When CONFIG_DRM_XE_GPUSVM is disabled, struct xe_svm_range uses an anonymous
> struct for its pages field instead of struct drm_gpusvm_pages. Since
> drm_gpusvm_pages_first_dma() expects a const struct drm_gpusvm_pages *,
> passing &range->pages here appears to result in a compiler type mismatch
> error.
>
Yep. This is related to failure in Intel's CI - kunit builds without
CONFIG_DRM_XE_GPUSVM [1].
I believe Xe side we'd some more inline wrapper:
xe_svm_range_first_dma(struct xe_svm *range)
Then use ifdef around CONFIG_DRM_XE_GPUSVM to either call
drm_gpusvm_pages_first_dma or return NULL. xe_svm.h is structured with
this ifdef in mind.
If you ask AI how build and run Xe's kunit, it should give you
instructions and should work without any Intel hardware.
Matt
[1] https://patchwork.freedesktop.org/series/173405/
> > xe_svm_range_size(range),
> > &curs);
> > xe_svm_range_debug(range, "BIND PREPARE - MIXED");
>
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260904163956.3433293-1-honghuan@amd.com?part=5
next prev parent reply other threads:[~2026-09-04 17:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 16:39 [PATCH v3 0/6] drm/gpusvm: share one HMM fault and keep single mappings inline Honglei Huang
2026-09-04 16:39 ` [PATCH v3 1/6] drm/gpusvm: move dma_addr allocation before the notifier lock Honglei Huang
2026-09-04 16:39 ` [PATCH v3 2/6] drm/gpusvm: extract drm_gpusvm_dma_map_pages() helper Honglei Huang
2026-09-04 16:39 ` [PATCH v3 3/6] drm/gpusvm: let drm_gpusvm_get_pages() map an array of pages Honglei Huang
2026-09-04 17:21 ` Matthew Brost
2026-09-04 16:39 ` [PATCH v3 4/6] drm/gpusvm: make the DMA mapping step in get_pages() optional Honglei Huang
2026-09-04 16:39 ` [PATCH v3 5/6] drm/gpusvm: keep a single DMA mapping inline for THP Honglei Huang
2026-09-04 16:58 ` sashiko-bot
2026-09-04 17:13 ` Matthew Brost [this message]
2026-09-05 13:27 ` Huang, Honglei
2026-09-04 17:16 ` Matthew Brost
2026-09-04 16:39 ` [PATCH v3 6/6] drm/gpusvm: keep an IOVA mapped range dma address inline Honglei Huang
2026-09-04 17:20 ` Matthew Brost
2026-09-04 16:48 ` ✗ CI.KUnit: failure for drm/gpusvm: share one HMM fault and keep single mappings inline 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=apr8Ok1NeYrUCcbC@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=honghuan@amd.com \
--cc=intel-xe@lists.freedesktop.org \
--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.