From: Matthew Brost <matthew.brost@intel.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: Jia Yao <jia.yao@intel.com>, <intel-xe@lists.freedesktop.org>,
<gwan-gyeong.mun@intel.com>, <stable@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] drm/xe/guc_ads: allocate UM queues in VRAM on dGFX
Date: Thu, 30 Jul 2026 17:52:40 -0700 [thread overview]
Message-ID: <amvx2Ev7I32jqH1O@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <789a05bc-f33f-41ed-869d-0fbe45ebef09@intel.com>
On Thu, Jul 30, 2026 at 02:12:42PM +0100, Matthew Auld wrote:
> On 30/07/2026 11:51, Matthew Auld wrote:
> > On 30/07/2026 01:47, Jia Yao wrote:
> > > On dGFX the original ADS BO is explicitly migrated to VRAM by
> > > xe_guc_realloc_post_hwconfig() so that xe_bo_main_addr() returns a
> > > real device-physical address (DPA) rather than an IOMMU IOVA. A
> > > separate SYSTEM BO for the UM queues would not go through that migration
> > > path, so its IOVA would differ from the physical address on systems
> > > where pages are allocated above 4 GB. GuC/GAM accesses the UM queue
> > > ring via base_dpa (with_dpa=true on pre-Xe3p), so an incorrect DPA
> > > causes all-zero fault descriptors to be forwarded to the driver.
> >
> > I feel like I don't fully understand the explanation here. Is the issue
> > not just the contig requirement for base_dpa? We now use attempt a best
> > effort approach for system memory, however for dgpu we can go further
> > and use VRAM to guarantee that requirement. If that is all this is doing
> > then commit message can be simplified with something like:
> >
> > "To fully guarantee the contig requirement for base_dpa, we can instead
> > just use VRAM for the um queue, on dgpu..."
>
> Or is the issue that this has to always be in VRAM, since there is no bit to
> say whether the DPA is system vs VRAM, like we do for the GGTT pte? On dgpu,
> assumption is that this is then always VRAM, if using DPA? If so, please
> make that clearer in the commit message.
>
The register interface to program the page fault queues are DPA / VRAM
on dGPU iirc.
Matt
> >
> > >
> > > Use XE_BO_FLAG_VRAM_IF_DGFX() for the UM queue BO so that on dGFX the
> > > BO is allocated directly in VRAM and xe_bo_main_addr() returns the
> > > correct DPA without needing a post-hwconfig migration step.
> > >
> > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
> > > Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > > Cc: Matthew Auld <matthew.auld@intel.com>
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Jia Yao <jia.yao@intel.com>
> > > ---
> > > drivers/gpu/drm/xe/xe_guc.c | 6 ------
> > > drivers/gpu/drm/xe/xe_guc_ads.c | 11 ++++++-----
> > > 2 files changed, 6 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> > > index 21cf3edef922..4023700ff2a9 100644
> > > --- a/drivers/gpu/drm/xe/xe_guc.c
> > > +++ b/drivers/gpu/drm/xe/xe_guc.c
> > > @@ -714,12 +714,6 @@ static int xe_guc_realloc_post_hwconfig(struct
> > > xe_guc *guc)
> > > if (ret)
> > > return ret;
> > > - if (guc->ads.um_queue_bo) {
> > > - ret = xe_managed_bo_reinit_in_vram(xe, tile, &guc-
> > > >ads.um_queue_bo);
> > > - if (ret)
> > > - return ret;
> > > - }
> > > -
> > > return 0;
> > > }
> > > diff --git a/drivers/gpu/drm/xe/xe_guc_ads.c b/drivers/gpu/drm/xe/
> > > xe_guc_ads.c
> > > index 7f371f9c7268..53636333fb45 100644
> > > --- a/drivers/gpu/drm/xe/xe_guc_ads.c
> > > +++ b/drivers/gpu/drm/xe/xe_guc_ads.c
> > > @@ -409,11 +409,12 @@ int xe_guc_ads_init(struct xe_guc_ads *ads)
> > > size_t um_size = roundup_pow_of_two(GUC_UM_QUEUE_SIZE *
> > > GUC_UM_HW_QUEUE_MAX);
> > > - bo = xe_managed_bo_create_pin_map(xe, tile, um_size,
> > > - XE_BO_FLAG_SYSTEM |
> > > - XE_BO_FLAG_GGTT |
> > > - XE_BO_FLAG_GGTT_INVALIDATE |
> > > - XE_BO_FLAG_PINNED_NORESTORE);
> > > + u32 um_flags = XE_BO_FLAG_VRAM_IF_DGFX(tile) |
> > > + XE_BO_FLAG_GGTT |
> > > + XE_BO_FLAG_GGTT_INVALIDATE |
> > > + XE_BO_FLAG_PINNED_NORESTORE;
> > > +
> > > + bo = xe_managed_bo_create_pin_map(xe, tile, um_size, um_flags);
> > > if (IS_ERR(bo))
> > > return PTR_ERR(bo);
> >
>
next prev parent reply other threads:[~2026-07-31 0:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 5:34 [PATCH v3 0/1] drm/xe/guc_ads: allocate UM queues in a separate UC BO Jia Yao
2026-07-22 5:34 ` [PATCH v3 1/1] " Jia Yao
2026-07-22 9:18 ` Matthew Auld
2026-07-22 23:00 ` Gwan-gyeong Mun
2026-07-22 5:41 ` ✗ CI.checkpatch: warning for " Patchwork
2026-07-22 5:42 ` ✓ CI.KUnit: success " Patchwork
2026-07-22 6:17 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-22 20:20 ` ✓ Xe.CI.FULL: " Patchwork
2026-07-30 0:47 ` [PATCH v4 0/1] " Jia Yao
2026-07-30 0:47 ` [PATCH v4 1/3] drm/xe/guc_ads: allocate UM queues in a separate BO Jia Yao
2026-07-30 10:28 ` Matthew Auld
2026-07-30 0:47 ` [PATCH v4 2/3] drm/xe/guc_ads: allocate UM queues in VRAM on dGFX Jia Yao
2026-07-30 10:51 ` Matthew Auld
2026-07-30 13:12 ` Matthew Auld
2026-07-31 0:52 ` Matthew Brost [this message]
2026-07-30 0:47 ` [PATCH v4 3/3] drm/xe/guc_ads: use uncached mapping for UM queue BO Jia Yao
2026-07-30 9:49 ` Michal Wajdeczko
2026-07-30 11:23 ` Matthew Auld
2026-07-30 23:27 ` [PATCH v5 0/1] drm/xe/guc_ads: allocate UM queues in a separate UC BO Jia Yao
2026-07-30 23:27 ` [PATCH v5 1/3] drm/xe/guc_ads: allocate UM queues in a separate BO Jia Yao
2026-07-30 23:27 ` [PATCH v5 2/3] drm/xe/guc_ads: allocate UM queues in VRAM on dGFX Jia Yao
2026-07-30 23:27 ` [PATCH v5 3/3] drm/xe/guc_ads: use uncached mapping for UM queue BO Jia Yao
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=amvx2Ev7I32jqH1O@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=gwan-gyeong.mun@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=jia.yao@intel.com \
--cc=matthew.auld@intel.com \
--cc=stable@vger.kernel.org \
/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.