linux-kernel - Re: [PATCH v6 18/30] x86/resctrl: Count valid telemetry aggregators per package

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f334442b-d0d2-4584-a10e-76c703305350@intel.com>
Date: Wed, 9 Jul 2025 15:59:36 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: "Luck, Tony" <tony.luck@...el.com>
CC: Fenghua Yu <fenghuay@...dia.com>, Maciej Wieczor-Retman
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
 Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>, "Anil
 Keshavamurthy" <anil.s.keshavamurthy@...el.com>, Chen Yu
	<yu.c.chen@...el.com>, <x86@...nel.org>, <linux-kernel@...r.kernel.org>,
	<patches@...ts.linux.dev>
Subject: Re: [PATCH v6 18/30] x86/resctrl: Count valid telemetry aggregators
 per package

Hi Tony,

On 7/9/25 3:48 PM, Luck, Tony wrote:
> On Wed, Jul 09, 2025 at 03:13:20PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 7/9/25 11:12 AM, Luck, Tony wrote:
>>> On Tue, Jul 08, 2025 at 07:20:35PM -0700, Reinette Chatre wrote:
>>>> As I understand there is 1:1 relationship between struct event_group and struct pmt_feature_group.
>>>> It thus seems unnecessary to loop through all the telemetry regions of a struct pmt_feature_group
>>>> if it is known to not be associated with the "event group"?
>>>> Could it be helpful to add a new (hardcoded) event_group::id that is of type enum pmt_feature_id
>>>> that can be used to ensure that only relevant struct pmt_feature_group is used to discover events
>>>> for a particular struct event_group?
>>>>
>>>> Another consideration is that this implementation seems to require that guids are unique across
>>>> all telemetry regions of all RMID telemetry features, is this guaranteed?
>>>
>>> The guids are unique. The XML file tags them like this:
>>>
>>> 	<TELEM:uniqueid>26557651</TELEM:uniqueid>
>>
>> I interpret above that guid is expected to be unique for one
>> telemetry feature. It is not clear to me that it implies that the guid
>> is unique across all telemetry features. For example, what prevents
>> a platform from using the same guid for all the telemetry features it
>> supports?
> 
> There are several non-RMID based telemetry MMIO regions in addition to
> the two used by this patch series.
> 
> Think of the uniqueid as a signature for the format of the region.
> Which event counters are present, in which order? How many total
> counters? What is the binary format of each counter?

I understand this.

> 
> Or think of it as a key. Usermode telemetry tools that access these MMIO
> regions use the uniqueid to choose which XML file to use to interpret
> the data. I'm effectively doing this, but without including an XML
> parser in the kernel. Just distilling each XML file to the basic
> essence described in the event_group structure.

Right. If the analogy it is about ID used to pick the right XML to use then the
question is whether the ID is unique per directory, i.e all XML files in
RMID-ENERGY directory can be expected to have unique ID, or across all directories,
i.e XML files across RMID-ENERGY and RMID-PERF can be expected to have unique ID.

> It would be a catastrophic failure if Intel assigned the same uniqueid
> to regions that had different formats.

I think we may be speaking past each other. New code will address concern
anyway though.

Reinette