Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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);
> > 
> 

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox