From: James Clark <james.clark@linaro.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Mike Leach <mike.leach@linaro.org>,
John Garry <john.g.garry@oracle.com>,
Will Deacon <will@kernel.org>, Leo Yan <leo.yan@linux.dev>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 05/12] perf evsel: Add a helper to get the value of a config field
Date: Wed, 17 Dec 2025 11:30:47 +0200 [thread overview]
Message-ID: <58d9f452-c075-4499-8975-387f3cdb052a@linaro.org> (raw)
In-Reply-To: <CAP-5=fUbr56hFd7e7yt33-gnhEGGa72GLmShQ5bCHxQjFAbFCQ@mail.gmail.com>
On 16/12/2025 22:44, Ian Rogers wrote:
> On Fri, Dec 12, 2025 at 7:32 AM James Clark <james.clark@linaro.org> wrote:
>>
>> This will be used by aux PMUs to read an already written value for
>> configuring their events and for also testing.
>>
>> Its helper pmu_format_unpack() does the opposite of the existing
>> pmu_format_value() so rename that one to pmu_format_pack() so it's clear
>> how they are related.
>>
>> Signed-off-by: James Clark <james.clark@linaro.org>
>> ---
>> tools/perf/util/evsel.h | 2 ++
>> tools/perf/util/pmu.c | 77 ++++++++++++++++++++++++++++++++++++++++++-------
>> 2 files changed, 68 insertions(+), 11 deletions(-)
>>
>> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
>> index a08130ff2e47a887b19f6c47bfa9f51e0c40d226..092904a61ec7afdc59253f9b78a9fe8b7cb5bfa7 100644
>> --- a/tools/perf/util/evsel.h
>> +++ b/tools/perf/util/evsel.h
>> @@ -575,6 +575,8 @@ void evsel__uniquify_counter(struct evsel *counter);
>> ((((src) >> (pos)) & ((1ull << (size)) - 1)) << (63 - ((pos) + (size) - 1)))
>>
>> u64 evsel__bitfield_swap_branch_flags(u64 value);
>> +int evsel__get_config_val(struct perf_pmu *pmu, struct evsel *evsel,
>> + const char *config_name, u64 *val);
>> void evsel__set_config_if_unset(struct perf_pmu *pmu, struct evsel *evsel,
>> const char *config_name, u64 val);
>>
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 514cba91f5d99b399d2d6a1e350971660c54a9fc..ef7358ad1fb955f29f2e68b3d0ce711754e4d67c 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -144,8 +144,8 @@ struct perf_pmu_format {
>> };
>>
>> static int pmu_aliases_parse(struct perf_pmu *pmu);
>> -static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v,
>> - bool zero);
>> +static void pmu_format_pack(unsigned long *format, __u64 value, __u64 *v,
>> + bool zero);
>> static struct perf_pmu_format *pmu_find_format(const struct list_head *formats,
>> const char *name);
>>
>> @@ -1377,6 +1377,61 @@ bool evsel__is_aux_event(const struct evsel *evsel)
>> return pmu && pmu->auxtrace;
>> }
>>
>> +/*
>> + * Unpacks a raw config[n] value using the sparse bitfield that defines a
>> + * format attr. For example "config1:1,6-7,44" defines a 4 bit value across non
>> + * contiguous bits and this function returns those 4 bits as a value.
>> + */
>> +static u64 pmu_format_unpack(u64 format, u64 config_val)
>> +{
>> + int val_bit = 0;
>> + u64 res = 0;
>> + int fmt_bit;
>> +
>> + for_each_set_bit(fmt_bit, &format, PERF_PMU_FORMAT_BITS) {
>> + if (test_bit(fmt_bit, &config_val))
>> + res |= BIT_ULL(val_bit);
>> +
>> + val_bit++;
>> + }
>> + return res;
>> +}
>> +
>> +int evsel__get_config_val(struct perf_pmu *pmu, struct evsel *evsel,
>> + const char *config_name, u64 *val)
>
> nits:
> This is an evsel__ function but the evsel is the 2nd argument not the first.
> Why pass the PMU and not just read evsel->pmu (or better evsel__find_pmu) ?
That makes sense, I can do that.
> Why not place this in evsel.c to match the header file declaration?
This was for consistency with evsel__set_config_if_unset() that Arnaldo
moved to pmu.c because of an issue with the Python bindings [1]. That
doesn't seem to be an issue any more so I could move both to evsel.c.
That would require making the following things public:
struct perf_pmu_format
pmu_format_pack()
pmu_format_unpack()
pmu_find_format()
Probably not the end of the world though?
[1]: https://lore.kernel.org/all/ZEbAS2yx2fguW60w@kernel.org/
> The evsel could be likely be const.
>
Will do
> Thanks,
> Ian
>
>> +{
>> + struct perf_pmu_format *format = pmu_find_format(&pmu->format, config_name);
>> + u64 bits = perf_pmu__format_bits(pmu, config_name);
>> +
>> + if (!format || !bits) {
>> + pr_err("Unknown/empty format name: %s\n", config_name);
>> + *val = 0;
>> + return -EINVAL;
>> + }
>> +
>> + switch (format->value) {
>> + case PERF_PMU_FORMAT_VALUE_CONFIG:
>> + *val = pmu_format_unpack(bits, evsel->core.attr.config);
>> + return 0;
>> + case PERF_PMU_FORMAT_VALUE_CONFIG1:
>> + *val = pmu_format_unpack(bits, evsel->core.attr.config1);
>> + return 0;
>> + case PERF_PMU_FORMAT_VALUE_CONFIG2:
>> + *val = pmu_format_unpack(bits, evsel->core.attr.config2);
>> + return 0;
>> + case PERF_PMU_FORMAT_VALUE_CONFIG3:
>> + *val = pmu_format_unpack(bits, evsel->core.attr.config3);
>> + return 0;
>> + case PERF_PMU_FORMAT_VALUE_CONFIG4:
>> + *val = pmu_format_unpack(bits, evsel->core.attr.config4);
>> + return 0;
>> + default:
>> + pr_err("Unknown format value: %d\n", format->value);
>> + *val = 0;
>> + return -EINVAL;
>> + }
>> +}
>> +
>> /*
>> * Set @config_name to @val as long as the user hasn't already set or cleared it
>> * by passing a config term on the command line.
>> @@ -1432,7 +1487,7 @@ void evsel__set_config_if_unset(struct perf_pmu *pmu, struct evsel *evsel,
>> return;
>>
>> /* Otherwise replace it */
>> - pmu_format_value(&bits, val, vp, /*zero=*/true);
>> + pmu_format_pack(&bits, val, vp, /*zero=*/true);
>> }
>>
>> static struct perf_pmu_format *
>> @@ -1477,8 +1532,8 @@ int perf_pmu__format_type(struct perf_pmu *pmu, const char *name)
>> * Sets value based on the format definition (format parameter)
>> * and unformatted value (value parameter).
>> */
>> -static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v,
>> - bool zero)
>> +static void pmu_format_pack(unsigned long *format, __u64 value, __u64 *v,
>> + bool zero)
>> {
>> unsigned long fbit, vbit;
>>
>> @@ -1595,23 +1650,23 @@ static int pmu_config_term(const struct perf_pmu *pmu,
>> switch (term->type_term) {
>> case PARSE_EVENTS__TERM_TYPE_CONFIG:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> - pmu_format_value(bits, term->val.num, &attr->config, zero);
>> + pmu_format_pack(bits, term->val.num, &attr->config, zero);
>> break;
>> case PARSE_EVENTS__TERM_TYPE_CONFIG1:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> - pmu_format_value(bits, term->val.num, &attr->config1, zero);
>> + pmu_format_pack(bits, term->val.num, &attr->config1, zero);
>> break;
>> case PARSE_EVENTS__TERM_TYPE_CONFIG2:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> - pmu_format_value(bits, term->val.num, &attr->config2, zero);
>> + pmu_format_pack(bits, term->val.num, &attr->config2, zero);
>> break;
>> case PARSE_EVENTS__TERM_TYPE_CONFIG3:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> - pmu_format_value(bits, term->val.num, &attr->config3, zero);
>> + pmu_format_pack(bits, term->val.num, &attr->config3, zero);
>> break;
>> case PARSE_EVENTS__TERM_TYPE_CONFIG4:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> - pmu_format_value(bits, term->val.num, &attr->config4, zero);
>> + pmu_format_pack(bits, term->val.num, &attr->config4, zero);
>> break;
>> case PARSE_EVENTS__TERM_TYPE_LEGACY_HARDWARE_CONFIG:
>> assert(term->type_val == PARSE_EVENTS__TERM_TYPE_NUM);
>> @@ -1749,7 +1804,7 @@ static int pmu_config_term(const struct perf_pmu *pmu,
>> */
>> }
>>
>> - pmu_format_value(format->bits, val, vp, zero);
>> + pmu_format_pack(format->bits, val, vp, zero);
>> return 0;
>> }
>>
>>
>> --
>> 2.34.1
>>
next prev parent reply other threads:[~2025-12-17 9:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 15:32 [PATCH v3 00/12] perf cs-etm/arm-spe: Remove hard coded config fields James Clark
2025-12-12 15:32 ` [PATCH v3 01/12] perf parse-events: Refactor get_config_terms() to remove macros James Clark
2025-12-12 15:32 ` [PATCH v3 02/12] perf evsel: Support sparse fields in evsel__set_config_if_unset() James Clark
2025-12-12 15:32 ` [PATCH v3 03/12] perf parse-events: Track all user changed config bits James Clark
2025-12-16 20:39 ` Ian Rogers
2025-12-12 15:32 ` [PATCH v3 04/12] perf evsel: apply evsel__set_config_if_unset() to all config fields James Clark
2025-12-12 15:32 ` [PATCH v3 05/12] perf evsel: Add a helper to get the value of a config field James Clark
2025-12-16 20:44 ` Ian Rogers
2025-12-17 9:30 ` James Clark [this message]
2025-12-12 15:32 ` [PATCH v3 06/12] perf parse-events: Always track user config changes James Clark
2025-12-12 15:32 ` [PATCH v3 07/12] perf tests: Test evsel__set_config_if_unset() and config change tracking James Clark
2025-12-12 15:32 ` [PATCH v3 08/12] perf cs-etm: Make a helper to find the Coresight evsel James Clark
2025-12-12 15:32 ` [PATCH v3 09/12] perf cs-etm: Don't use hard coded config bits when setting up ETMCR James Clark
2025-12-12 15:32 ` [PATCH v3 10/12] perf cs-etm: Don't use hard coded config bits when setting up TRCCONFIGR James Clark
2025-12-12 15:32 ` [PATCH v3 11/12] perf cs-etm: Don't hard code config attribute when configuring the event James Clark
2025-12-12 15:32 ` [PATCH v3 12/12] perf arm-spe: Don't hard code config attribute James Clark
2025-12-16 21:00 ` [PATCH v3 00/12] perf cs-etm/arm-spe: Remove hard coded config fields Ian Rogers
2026-01-13 20:51 ` Arnaldo Carvalho de Melo
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=58d9f452-c075-4499-8975-387f3cdb052a@linaro.org \
--to=james.clark@linaro.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=irogers@google.com \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/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
all inboxes | Powered by JetHome®