lib: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

lib: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...

pmc: better distinguish pmu-events allocation path

Background:

The pm_ev field of struct pmc_op_pmcallocate and struct pmc
traditionally contains the index of the chosen event, corresponding to
the

pmc: better distinguish pmu-events allocation path

Background:

The pm_ev field of struct pmc_op_pmcallocate and struct pmc
traditionally contains the index of the chosen event, corresponding to
the __PMC_EVENTS array in pmc_events.h. This is a static list of events,
maintained by FreeBSD.

In the usual case, libpmc translates the user supplied event name
(string) into the pm_ev index, which is passed as an argument to the
allocation syscall. On the kernel side, the allocation method for the
relevant hwpmc class translates the given index into the event code that
will be written to an event selection register.

In 2018, a new source of performance event definitions was introduced:
the pmu-events json files, which are maintained by the Linux kernel. The
result was better coverage for newer Intel processors with a reduced
maintenance burden for libpmc/hwpmc. Intel and AMD CPUs were
unconditionally switched to allocate events from pmu-events instead of
the traditional scheme (959826ca1bb0a, 81eb4dcf9e0d).

Under the pmu-events scheme, the pm_ev field contains an index
corresponding to the selected event from the pmu-events table, something
which the kernel has no knowledge of. The configuration for the
performance counting registers is instead passed via class-dependent
fields (struct pmc_md_op_pmcallocate).

In 2021 I changed the allocation logic so that it would attempt to
pull from the pmu-events table first, and fall-back to the traditional
method (dfb4fb41166bc3). Later, pmu-events support for arm64 and power8
CPUs was added (28dd6730a5d6 and b48a2770d48b).

The problem that remains is that the pm_ev field is overloaded, without
a definitive way to determine whether the event allocation came from the
pmu-events table or FreeBSD's statically-defined PMC events. This
resulted in a recent fix, 21f7397a61f7.

Change:

To disambiguate these two supported but separate use-cases, add a new
flag, PMC_F_EV_PMU, to be set as part of the allocation, indicating that
the event index came from pmu-events.

This is useful in two ways:
1. On the kernel side, we can validate the syscall arguments better.
Some classes support only the traditional event scheme (e.g.
hwpmc_armv7), while others support only the pmu-events method (e.g.
hwpmc_core for Intel). We can now check for this. The hwpmc_arm64
class supports both methods, so the new flag supersedes the existing
MD flag, PM_MD_EVENT_RAW.

2. The flag will be tracked in struct pmc for the duration of its
lifetime, meaning it is communicated back to userspace. This allows
libpmc to perform the reverse index-to-event-name translation
without speculating about the meaning of the index value.

Adding the flag is a backwards-incompatible ABI change. We recently
bumped the major version of the hwpmc module, so this breakage is
acceptable.

Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40753

show more ...

libpmc: make pmc_pmu_pmcallocate() machine-independent

Have it call the platform-dependent version. For better layering, move
the reset logic inside the new function. This is mainly to facilitate an

libpmc: make pmc_pmu_pmcallocate() machine-independent

Have it call the platform-dependent version. For better layering, move
the reset logic inside the new function. This is mainly to facilitate an
upcoming change.

Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40752

show more ...

Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

libpmc: Handle PMCALLOCATE log with PMC code on PMU event system

On an arm64 system that reports as a Cortex A72 r0p3, running

pmcstat -P CPU_CYCLES command

works, but

pmcstat -P cpu-cycles c

libpmc: Handle PMCALLOCATE log with PMC code on PMU event system

On an arm64 system that reports as a Cortex A72 r0p3, running

pmcstat -P CPU_CYCLES command

works, but

pmcstat -P cpu-cycles command

does not. This is because the former uses the PMU event from the JSON
source, resulting in pl_event in the log event being a small index
(here, 5) into the generated events table, whilst the latter does not
match any of the JSON events and falls back on PMC's own tables, mapping
it to the PMC event 0x14111, i.e. PMC_EV_ARMV8_EVENT_11H. Then, when
libpmc gets the PMCALLOCATE event, it tries to use the event as an index
into the JSON-derived table, but doing so only makes sense for the
former, whilst for the latter it will go way out of bounds and either
read junk (which may trigger the != NULL assertion) or segfault. As far
as I can tell we don't have anything lying around to tell us which of
the two cases we're in, but we can exploit the fact that the first
0x1000 PMC event codes are reserved, and that none of our PMU events
tables reach that number of entries yet.

PR: 268857
Reviewed by: mhorne
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D39592

show more ...

libpmc: expand PMC_OP* defines

When performing the syscall, specify the full name of the desired
operation. This improves grep-ability.

No functional change.

Reviewed by: jkoshy
MFC after: 3 days

libpmc: expand PMC_OP* defines

When performing the syscall, specify the full name of the desired
operation. This improves grep-ability.

No functional change.

Reviewed by: jkoshy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40334

show more ...

pmc: Initialise and check the pm_flags field for CONFIGURELOG

Whilst the former is not breaking, the latter is, and so this will be
followed by a bump to the pmc major version. This will allow the f

pmc: Initialise and check the pm_flags field for CONFIGURELOG

Whilst the former is not breaking, the latter is, and so this will be
followed by a bump to the pmc major version. This will allow the flags
to actually be usable in future, as otherwise we cannot distinguish
uninitialised stack junk from a deliberately-initialised value.

Reviewed by: jhb, mhorne
Differential Revision: https://reviews.freebsd.org/D40049

show more ...

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

libpmc: pmc_init() should avoid overflowing pmc_class_table

Use calloc().

Walk the class list we get from kernel, so we will not add something
the kernel does not know about.

Avoid picking headers

libpmc: pmc_init() should avoid overflowing pmc_class_table

Use calloc().

Walk the class list we get from kernel, so we will not add something
the kernel does not know about.

Avoid picking headers from /usr/include.

Differential Revision: https://reviews.freebsd.org/D36401

show more ...

libpmc: attempt to fix the build

Try to fix the build (blindly) after e3572eb654733a94e1e765fe9e95e0579981d851.
I had missed the missing #ifdef in the review. Hope that's all it takes.

Allocate event for DMC-620 and CMN-600 controllers PMU. Add events supported by DMC-620 and CMN-600 controllers PMU.

Allocate event for DMC-620 and CMN-600 controllers PMU.
Add events supported by D

Allocate event for DMC-620 and CMN-600 controllers PMU. Add events supported by DMC-620 and CMN-600 controllers PMU.

Allocate event for DMC-620 and CMN-600 controllers PMU.
Add events supported by DMC-620 and CMN-600 controllers PMU.

Reviewed by: bz
Sponsored By: ARM
Sponsored By: Ampere Computing
Differential Revision: https://reviews.freebsd.org/D35609

show more ...

arm64 hwpmc: Support restricting counters to user or kernel mode.

Support the "usr" and "os" qualifiers on arm64 events to restrict
event counting to either usermode or the kernel, respectively. If

arm64 hwpmc: Support restricting counters to user or kernel mode.

Support the "usr" and "os" qualifiers on arm64 events to restrict
event counting to either usermode or the kernel, respectively. If
neither qualifier is given, events are counted in both.

Reviewed by: emaste
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34527

show more ...

libpmc: Allow specifying explicit EVENT_xxH events on armv7 and arm64

This is useful for processors where we don't have an event table; in
those cases we default to a Cortex A8 (armv7) or Cortex A53

libpmc: Allow specifying explicit EVENT_xxH events on armv7 and arm64

This is useful for processors where we don't have an event table; in
those cases we default to a Cortex A8 (armv7) or Cortex A53 (arm64) in
order to attempt to provide something useful, but you're then limited to
the counters in those tables, some of which may also not be implemented
(e.g. LD/ST_RETIRED are no longer implemented in more recent cores,
replaced by LD/ST_SPEC).

Adding the raw EVENT_xxH event lists to each table ensures that you can
always request the exact events you want, regardless of what has been
detected or is known.

Reviewed by: mhorne
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33805

show more ...

libpmc: remove mips support

Bye bye!

Reviewed by: imp, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34083

libpmc: fix the 'cycles' event alias on x86

Looking for "tsc-tsc" in the pmu tables will fail every time. Instead,
make this an alias for the static TSC event defined in pmc_events.h.
This fixes 'pm

libpmc: fix the 'cycles' event alias on x86

Looking for "tsc-tsc" in the pmu tables will fail every time. Instead,
make this an alias for the static TSC event defined in pmc_events.h.
This fixes 'pmcstat -s cycles' on Intel and AMD.

Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32197

show more ...

hwpmc: remove static POWER8 definitions

After b48a2770d48b, static POWER8 definitions became unnecessary,
as all of them (and much more) are already present in libpmc's
PMU events.

Submitted by: L

hwpmc: remove static POWER8 definitions

After b48a2770d48b, static POWER8 definitions became unnecessary,
as all of them (and much more) are already present in libpmc's
PMU events.

Submitted by: Leonardo Bianconi <leonardo.bianconi@eldorado.org.br> (initial version)
Reviewed by: kbowling, mhorne
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D31334

show more ...

libpmc: fall-back to kernel tables if pmu-events fails

On x86, the pmu_events table is the source of truth for finding
supported events. However, events not found there may still be present
in the k

libpmc: fall-back to kernel tables if pmu-events fails

On x86, the pmu_events table is the source of truth for finding
supported events. However, events not found there may still be present
in the kernel's static event tables. For example, the pmc.soft(3) events
will never be available from pmu-events.

Update pmc_allocate() to search the legacy event tables if
pmc_pmu_pmcallocate() fails to return a result. This allows both event
sources to be consulted before giving up, thus restoring pmc.soft(3) and
pmc.tsc(3) on x86.

Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30216

show more ...

libpmc: remove PMC_MDEP_TABLE logic

This logic was added for handling some of the complicated relationships
between events and x86 CPU models. Since that logic has been mostly
removed from libpmc(3)

libpmc: remove PMC_MDEP_TABLE logic

This logic was added for handling some of the complicated relationships
between events and x86 CPU models. Since that logic has been mostly
removed from libpmc(3) in favor of pmu-events, this no longer serves
much of a purpose. Mapping CPU types to event tables is already handled
by the switch statement in pmc_init().

Reviewed by: ray, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30196

show more ...

libpmc: remove unused PMC_MDEP_INIT_INTEL_V2

All uses of this macro were removed in e92a1350b50e. Remove
cpu_has_iaf_counters as well.

Reviewed by: ray, emaste
MFC after: 2 weeks
Sponsored by: The

libpmc: remove unused PMC_MDEP_INIT_INTEL_V2

All uses of this macro were removed in e92a1350b50e. Remove
cpu_has_iaf_counters as well.

Reviewed by: ray, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D30195

show more ...

PMC: remove now orphaned PMC for INTEL XScale processors.
Support for XScale architecture has been deleted in FreeBSD 13.

libpmc: add support for POWER8/9 PMCs

This change adds support for POWER8/9 performance counters.

Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revi

libpmc: add support for POWER8/9 PMCs

This change adds support for POWER8/9 performance counters.

Reviewed by: jhibbits
Sponsored by: Eldorado Research Institute (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D26113

show more ...

Merge ^/head r364082 through r364250.

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Add support for Cortex-A76/Neoverse-N1 to hwpmc

This adds support for the Cortex-A76 and Neoverse-N1 PMU counters to pmc.

While here add more PMCR_IDCODE values and check the implementers code is
c

Add support for Cortex-A76/Neoverse-N1 to hwpmc

This adds support for the Cortex-A76 and Neoverse-N1 PMU counters to pmc.

While here add more PMCR_IDCODE values and check the implementers code is
correct before setting the PMU type.

Reviewed by: bz, emaste (looks reasonable to me)
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25959

show more ...

Merge ^/head r352436 through r352536.