Re: [PATCH v2 1/2] drm/xe: Expose retired VRAM pages via drm-ras

["Tauro, Riana" <riana.tauro@intel.com>]

Hi Aravind/Rodrigo

How about using a generic telemetry node for this series from 
https://lore.kernel.org/dri-devel/20261029203000.1763447-1-zachary.mckevitt@oss.qualcomm.com/T/#t 
instead of a dedicated node for vram-retired-pages?

Thanks
Riana

On 19-10-2026 17:26, Rodrigo Vivi wrote:
> On Fri, Oct 16, 2026 at 03:49:13PM -0700, Jakub Kicinski wrote:
>> On Wed,  7 Oct 2026 13:33:53 +0530 Aravind Iddamsetty wrote:
>>> +  -
>>> +    name: retired-resource-attrs
>>> +    attributes:
>>> +      -
>>> +        name: node-id
>>> +        type: u32
>>> +        doc: Node ID targeted by this retired resource operation.
>>> +      -
>>> +        name: vram-page
>>> +        type: nest
>>> +        nested-attributes: vram-page-attrs
>> why wrap attrs in a nest? Are you planning to add other resource types
>> (than a page)? It's a common anti-pattern in Netlink to over-wrap stuff.
> we should indeed remove the wrap and have only the page info.
>
>>> +        doc: >-
>>> +             Type-specific payload. The resource type is identified by the
>>> +             node (its node-name); each node reports a single resource type.
>>> +  -
>>> +    name: vram-page-attrs
>>> +    attributes:
>>> +      -
>>> +        name: address
>>> +        type: u64
>>> +        doc: Device address of the retired VRAM page (e.g. DPA).
>>> +      -
>>> +        name: size
>>> +        type: u64
>> prefer uint
>>
>>> +        doc: Size of the retired VRAM page in bytes.
>>> +      -
>>> +        name: max-pages
>>> +        type: u32
>>> +        doc: >-
>>> +             Maximum VRAM pages that can be retired. Present only in the
>>> +             leading summary entry of the dump (no address/size/status).
>>> +      -
>>> +        name: status
>>> +        type: u32
>>> +        doc: Retirement status of the retired VRAM page.
>>> +        enum: retired-resource-status
>>> +      -
>>> +        name: pad
>>> +        type: pad
>> And then you won't need pad
> I noticed this in the review prompts, but I have some reservations here.
> We know for sure our value is always u64 because it is our hw definition.
> I don't see a good reason why not use the exact size that matches our hw.