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] [thread-next>] [day] [month] [year] [list]
Message-ID: <74a1e5f0-5484-4952-9a61-7a4e5b96b707@intel.com>
Date: Wed, 9 Jul 2025 15:13:20 -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 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?

> 
> the "guid" naming of the value comes from the Intel PMT_DISCOVERY driver.
> 
> An alternative to adding the new event_group::id field would be to
> separate the arrays of known event groups. I.e. change from:
> 
> static struct event_group *known_event_groups[] = {
>         &energy_0x26696143,
>         &perf_0x26557651,
> };
> 
> to
> 
> static struct event_group *known_energy_event_groups[] = {
>         &energy_0x26696143,
> };
> 
> static struct event_group *known_perf_event_groups[] = {
>         &perf_0x26557651,
> };
> 
> then only scan the appropriate array that matches the
> enum pmt_feature_id passed to get_pmt_feature().
> 
> 
> With only one option in each array today this looks
> like extra infrasctruture. But I already have a patch
> for the next generation system that adds another guid.

This also sounds good. Thank you.

Reinette


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ