libpmc: Map AMD Family 1Ah models 00h-0Fh to amdzen5

[ojanerif_amd.com]

Summary

178d0b5b8da7 adapted the Zen 5 pattern matching from Linux perf.
However, Linux prints CPU models with a single digit when under 0xF
(allowing |:xdigit: to match 0h-Fh), whereas hwpmc/libpmc formats
model numbers with two leading hex digits (00h-0Fh).

Fix the pattern to explicitly cover two-digit hex models in the 00h-0Fh
range, and add a test case verifying table selection across Zen 5 and Zen 6
cpuid strings.

Fixes: 178d0b5b8da7 ("libpmc: Import AMD Zen 6 PMU events.")
Sponsored by: Advanced Micro Devices, Inc.
Signed-off-by: Osvaldo Janeri Filho <[e-mail]>

Test Plan

kyua test -k /usr/tests/sys/pmc/Kyuafile pmc_mapfile_test:zen5_models
Fails before change (models 02h and 0Fh resolve to amdzen6), passes after.

[ali_mashtizadeh.com]

We generally just copy this from Linux why does it not match the current linux upstream?

https://github.com/torvalds/linux/blob/master/tools/perf/pmu-events/arch/x86/mapfile.csv

Not sure it's worth the bloat of adding test cases for these things.

[netchild]

In D60625#1391891, @ali_mashtizadeh.com wrote:

Not sure it's worth the bloat of adding test cases for these things.

I do not consider it bloat to ship test cases for code we use. The bug I found which resulted in a recent SA for the PMC was found by adding test cases.

[ojanerif_amd.com]

Linux perf formats the model with %X (Turin = AuthenticAMD-26-2-…), which is why its Zen 5 line has the |[[:xdigit:]] alternative.

hwpmc uses %02X (AuthenticAMD-26-02-…), so that alternative never matches here, and models 00h–0Fh currently fall through to amdzen6.

This is the same adaptation already in the tree for Zen 3: Linux has 25-([245][[:xdigit:]]|[[:xdigit:]]), and 278d695094 imported it as 25-[0245][[:xdigit:]].

The test is small, needs no PMC hardware, and catches this exact mismatch on the next import from Linux. I can split it into a separate review if you prefer.

[ali_mashtizadeh.com]

@mhorne I'm okay either way with the tests, I suggested we just add better error checking not sure how we prevent this in the future given the parsing difference between the string.

It's not a test case that prevents future versions of the bug and not a place were we would likely get a regression.

[ojanerif_amd.com]

Agreed. D60790 strips the leading zeros in libpmc instead, so the
entries can be imported as is. low_models fails if they get hand-edited
again.