From: Rodrigo Vivi <rodrigo.vivi@intel•com>
To: Zack McKevitt <zachary.mckevitt@oss•qualcomm.com>,
<netdev@vger•kernel.org>, "David S. Miller" <davem@davemloft•net>,
"Eric Dumazet" <edumazet@google•com>,
Jakub Kicinski <kuba@kernel•org>, Paolo Abeni <pabeni@redhat•com>,
Simon Horman <horms@kernel•org>
Cc: <dri-devel@lists•freedesktop.org>,
<intel-xe@lists•freedesktop.org>,
Hawking Zhang <Hawking.Zhang@amd•com>,
Alex Deucher <alexander.deucher@amd•com>,
Lukas Wunner <lukas@wunner•de>, Dave Airlie <airlied@gmail•com>,
Simona Vetter <simona.vetter@ffwll•ch>,
"Aravind Iddamsetty" <aravind.iddamsetty@linux•intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux•intel.com>
Subject: Re: [PATCH 0/2] Introduce DRM_RAS using generic netlink for RAS
Date: Thu, 6 Nov 2025 08:42:06 -0500 [thread overview]
Message-ID: <aQylrqUCRkkUYzQl@intel.com> (raw)
In-Reply-To: <c8caad3b-d7b9-4e0c-8d90-5b2bc576cabf@oss.qualcomm.com>
On Thu, Oct 02, 2025 at 02:38:47PM -0600, Zack McKevitt wrote:
> I think this looks good, adding telemetry functionality as a node type and
> in the yaml spec looks straightforward (despite some potential naming
> awkwardness with the RAS module). Thanks for adding this.
>
> Have you considered how this might work for containerized workloads?
From the use cases that we have, we are already expecting network=host,
so there shouldn't be any problem for this usage.
> Specifically, I think it would be best if the underlying drm_ras nodes are
> only accessible for containerized workloads where the device has been
> explicitly passed in. Do you know if this is handled automatically with the
> existing netlink implementation? I imagine that this would be of interest to
> the broader community outside of Qualcomm as well.
My understanding is that it is. But adding the netlink mailing list and maintainers
here for more specialized eyes.
>
> > Also, it is worth to mention that we have a in-tree pyynl/cli.py tool that entirely
> > exercises this new API, hence I hope this can be the reference code for the uAPI
> > usage, while we continue with the plan of introducing IGT tests and tools for this
> > and adjusting the internal vendor tools to open with open source developments and
> > changing them to support these flows.
>
> I think it would be nice to see some accompanying userspace code that makes
> use of this implementation to have as a reference if at all possible.
We have some folks working on the userspace tools, but I just realized that
perhaps we don't even need that and we could perhaps only using the
kernel-tools/ynl as official drm-ras consumer?
$ sudo ynl --family drm_ras --dump list-nodes
[{'device-name': '00:02.0',
'node-id': 0,
'node-name': 'non-fatal',
'node-type': 'error-counter'},
{'device-name': '00:02.0',
'node-id': 1,
'node-name': 'correctable',
'node-type': 'error-counter'}]
thoughts?
>
> As a side note, I will be on vacation for a couple of weeks as of this
> weekend and my response time will be affected.
Thank you,
Please let me know if you have further thoughts here, or if you see any blocker
or an ack to move forward with this path.
Thanks,
Rodrigo.
>
> Thanks,
>
> Zack
next prev parent reply other threads:[~2025-11-06 13:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250929214415.326414-4-rodrigo.vivi@intel.com>
[not found] ` <aQEVy1qjaDCwL_cc@intel.com>
2025-10-30 14:47 ` DRM_RAS for CPER Error logging?! Rodrigo Vivi
2025-10-30 15:37 ` DRM_RAS (netlink genl family) " Rodrigo Vivi
2025-10-31 5:38 ` DRM_RAS " Lukas Wunner
2025-11-06 13:08 ` Rodrigo Vivi
[not found] ` <c8caad3b-d7b9-4e0c-8d90-5b2bc576cabf@oss.qualcomm.com>
2025-11-06 13:42 ` Rodrigo Vivi [this message]
2025-11-07 20:20 ` [PATCH 0/2] Introduce DRM_RAS using generic netlink for RAS Zack McKevitt
2025-11-08 3:01 ` Rodrigo Vivi
2025-12-09 21:40 ` Rodrigo Vivi
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=aQylrqUCRkkUYzQl@intel.com \
--to=rodrigo.vivi@intel$(echo .)com \
--cc=Hawking.Zhang@amd$(echo .)com \
--cc=airlied@gmail$(echo .)com \
--cc=alexander.deucher@amd$(echo .)com \
--cc=aravind.iddamsetty@linux$(echo .)intel.com \
--cc=davem@davemloft$(echo .)net \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=edumazet@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=intel-xe@lists$(echo .)freedesktop.org \
--cc=joonas.lahtinen@linux$(echo .)intel.com \
--cc=kuba@kernel$(echo .)org \
--cc=lukas@wunner$(echo .)de \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=simona.vetter@ffwll$(echo .)ch \
--cc=zachary.mckevitt@oss$(echo .)qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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