hwpmc: handle AMD Zen3-B0 IBS errata in the frontend view

[afscoelho_gmail.com]

Summary

AMD Family 19h Model 00h-0Fh (Zen3-B0) has IBS errata that make some
fetch and op sample fields wrong. Detect this silicon from the CPUID
block in the pmc(1) log header and fix up the affected samples:

#1197: drop fetch samples with a zero linear address.
#1238: mark IcMiss invalid; show "-" instead of a false 0%.
#1293: mark DATA2 and two DATA3 fields invalid on bad conditions.
#1347: decode the L1TLB page size and remap it for display.

Signed-off-by: Andre Silva <[e-mail]>

[mhorne]

I did not review in detail.

References to pmc(1) should actually be pmc(8), as the utility is in /usr/sbin.

The change summary should become:

pmc(8): handle AMD Zen3-B0 IBS errata in the frontend view

Because you are not touching the hwpmc module here.

usr.sbin/pmc/cmd_pmc_frontend.cc

88

Does it need the zen3_b0 parameter, or can it check ibs_zen3_b0_errata directly?

[ali_mashtizadeh.com]

Thanks Andre, like I mentioned in the call I mainly want to reduce the spread of the errata code and concentrate it right before callchain callbacks as much as possible. You may want to rebase this on top of the remaining pmc bits I said I'd push.

usr.sbin/pmc/cmd_pmc_frontend.cc

98

icmiss goes up here.

143

Please move the ICMISS above the L2MISS

156

You can simplify this and just drop printing it if the errata flag is present.

176

Move IC MISS above L2 MISS and hide the column if the errata is present.

196

I think '-' is confusing just don't add the column to processors with the errata.

usr.sbin/pmc/view.cc

64

Some of this info is defined in the main cpuid code in x86/x86/cpuident and its header in x86/include or something like that, but I'm not sure that we keep those headers on other architectures.

Otherwise move these into a header of it's own inside of this folder.

229

Looks good.

817

Unneeded you can access the errata flag directly by setting it in the view.

819

Don't do decoding here.

835

Move this down near where you process #1197 and just fixup the data, zero out those flags rather than marking them valid. Since this condition is rare, we can use the valid samples still.

844

Just zero out the invalid bits because this condition isn't super common, thus the numbers we get in the other cases is still useful even if it's not complete. We should eventually mark the data with some symbol to mean its inconsistent.

898

I think all the errata should processed here in the IBS paths below or inside the individual analysis passes.

907

Move the errata code for #1293 here.

usr.sbin/pmc/view.hh

314

Unneeded access the errata flag from the view.

316

Also unneeded.

332

Not needed if we just zero out the bad samples' flag.

412

Good all the errata that are relevant should have their own flags here.

[ali_mashtizadeh.com]

Remember that the code path is shared on all platforms I’m trying to make it that we can run analysis across 64-bit big-endian machines.

To summarize

1. Inside the cpuid parsing (x86 only) you should compute all the errata flags (which you did).
2. Correcting per-event rare events in the IBS data should be donee right before the call to call chain around lines 900-920 depending if it’s fetch or op events. (a) We should eventually add some annotation to tell the user the event is imprecise, but I’m not to worried about it unless we know the event occurs often.
3. Eliding unreliable data can occur inside the analysis pass.

[ali_mashtizadeh.com]

Can you please comment on https://reviews.freebsd.org/D58698 so the two of you can agree on an API for LBR? I can clean it up and we land it if your happy with it or you can take over.