From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>, intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/xe: Make p2pdma distance check verbose via dynamic debug
Date: Mon, 14 Sep 2026 13:39:56 +0200 [thread overview]
Message-ID: <086554d9370ee0e9ea24589454300eb394acb52c.camel@linux.intel.com> (raw)
In-Reply-To: <eff47fd6-7108-4561-927b-d01749937d48@intel.com>
On Mon, 2026-09-14 at 12:34 +0100, Matthew Auld wrote:
> On 14/09/2026 10:46, Thomas Hellström wrote:
> > pci_p2pdma_distance() can optionally print details about how it
> > computed the ACS/PCIe topology distance between the two devices,
> > but
> > xe_dma_buf_attach() always called it with verbose set to false,
> > silently hiding useful diagnostics whenever a dma-buf attach unset
> > attach->peer2peer.
> >
> > Tie the verbose argument to a dedicated dynamic-debug callsite
> > tagged
> > "xe dma-buf p2p debug" (in addition to keeping the existing
> > DRM_UT_DRIVER category as a default), so the extra p2pdma distance
> > logging can be switched on without a recompile in any of the
> > following
> > ways:
> >
> > - Enable the whole DRIVER category for xe via drm.debug, which is
> > already used elsewhere in the driver:
> >
> > # echo 0x10 > /sys/module/drm/parameters/debug
> >
> > - Enable dynamic debug for the whole file:
> >
> > # echo 'file xe_dma_buf.c +p' > \
> > /sys/kernel/debug/dynamic_debug/control
> >
> > - Enable dynamic debug for just this callsite by function name:
> >
> > # echo 'func xe_dma_buf_attach +p' > \
> > /sys/kernel/debug/dynamic_debug/control
> >
> > - Enable dynamic debug by matching the format string used to
> > register the callsite:
> >
> > # echo 'format "xe dma-buf p2p debug" +p' > \
> > /sys/kernel/debug/dynamic_debug/control
> >
> > - Enable it at boot via the dyndbg= kernel command line
> > parameter:
> >
> > dyndbg="func xe_dma_buf_attach +p"
> >
> > Any of the above flips verbose_p2p_dist to true for that attach
> > call,
> > causing pci_p2pdma_distance() to log its distance calculation
> > without
> > requiring the whole DRM_UT_DRIVER category to be enabled.
>
> Is drm.debug not enough here for typical usescases? If you are
> interested in this you would maybe toggle that anyway, in case there
> is
> other interesting stuff? Or do you think the dynamic debug will be
> useful?
There are cases where we just want to check just if p2p is enabled. And
normally IIRC you can do this by targeting a separate pr_debug or
drm_debug using dynamic debug. But since this one triggers printouts in
the p2pdma code, it seems like this construct is neecessary.
>
> >
> > Cc: Matthew Brost <matthew.brost@intel.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Assisted-by: LLM
> > Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
>
> Either way,
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Thanks,
Thomas
>
> (With the ifdef guard or so)
>
> > ---
> > drivers/gpu/drm/xe/xe_dma_buf.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c
> > b/drivers/gpu/drm/xe/xe_dma_buf.c
> > index 5d9f1cd24b7f..b63fd70fb4de 100644
> > --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> > +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> > @@ -22,13 +22,21 @@
> >
> > MODULE_IMPORT_NS("DMA_BUF");
> >
> > +static void xe_ddebug_flip_bool(const struct _ddebug *desc, bool
> > *flag)
> > +{
> > + *flag = true;
> > +}
> > +
> > static int xe_dma_buf_attach(struct dma_buf *dmabuf,
> > struct dma_buf_attachment *attach)
> > {
> > struct drm_gem_object *obj = attach->dmabuf->priv;
> > + bool verbose_p2p_dist = drm_debug_enabled(DRM_UT_DRIVER);
> > +
> > + _dynamic_func_call("xe dma-buf p2p debug",
> > xe_ddebug_flip_bool, &verbose_p2p_dist);
> >
> > if (attach->peer2peer &&
> > - pci_p2pdma_distance(to_pci_dev(obj->dev->dev), attach-
> > >dev, false) < 0)
> > + pci_p2pdma_distance(to_pci_dev(obj->dev->dev), attach-
> > >dev, verbose_p2p_dist) < 0)
> > attach->peer2peer = false;
> >
> > if (!attach->peer2peer &&
> > !xe_bo_can_migrate(gem_to_xe_bo(obj), XE_PL_TT))
prev parent reply other threads:[~2026-09-14 11:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 9:46 [PATCH] drm/xe: Make p2pdma distance check verbose via dynamic debug Thomas Hellström
2026-09-14 9:56 ` sashiko-bot
2026-09-14 11:34 ` Matthew Auld
2026-09-14 11:39 ` Thomas Hellström [this message]
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=086554d9370ee0e9ea24589454300eb394acb52c.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox