sys: 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

sys: 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 ...

hwpmc: tidy pcd_finalize methods

Make them a little bit more consistent with one another in terms of what
is done:
- Add/reduce assertions to what is most useful: a loop to ensure
pcpu_fini free

hwpmc: tidy pcd_finalize methods

Make them a little bit more consistent with one another in terms of what
is done:
- Add/reduce assertions to what is most useful: a loop to ensure
pcpu_fini freed everything
- Add PMCDBG trace entries

The exception is the dmc620/cmn600 classes, which behave a little
differently, so leave them untouched.

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

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 ...

sys: Remove $FreeBSD$: one-line .c pattern

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

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 ...

hwpmc: pass pmc pointer to more class methods

In many cases this avoids an extra lookup, since the callers always have
pm at hand. We can also eliminate several assertions, mostly for pm !=
NULL. Th

hwpmc: pass pmc pointer to more class methods

In many cases this avoids an extra lookup, since the callers always have
pm at hand. We can also eliminate several assertions, mostly for pm !=
NULL. The class methods are an internal interface, and the callers
already handle such a scenario. No functional change intended.

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

show more ...

hwpmc: don't use deprecated copystr(9)

It is just wrapper around strlcpy(), but results in more complicated
code. Clean this up to use strlcpy() or snprintf() as appropriate.

Reviewed by: jkoshy
MF

hwpmc: don't use deprecated copystr(9)

It is just wrapper around strlcpy(), but results in more complicated
code. Clean this up to use strlcpy() or snprintf() as appropriate.

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

show more ...

hwpmc: remove remaining UCP event definitions

Although this block has remained in __PMC_EVENTS(), there is no handling
of UCP in libpmc/libpmc.c, so it is not possible to select one of these
events.

hwpmc: remove remaining UCP event definitions

Although this block has remained in __PMC_EVENTS(), there is no handling
of UCP in libpmc/libpmc.c, so it is not possible to select one of these
events. It should therefore be impossible to trigger the code removed
from ucp_start_pmc(). Note that the GQ_SNOOP_MSF MSR exists only for
Nehalem and Westmere architectures, and the related events do not exist
for later generations.

The Uncore support in hwpmc has severely atrophied in general. We have
uncore event definitions in pmu-events, but the kernel support was
written against Intel Performance Measurement Architecture version 2,
and is disabled for processor generations later than Westmere. Nehalem
and Westmere lack uncore event definitions in pmu-events. I'd be
surprised if Uncore support is usable on any machine in its current
state.

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

show more ...

hwpmc: purge EOL release compatibility

hwpmc: Skip GLOBAL_CTRL updates on stop_pmc().

After we wipe PMC configuration, including its local enable bit(s),
we don't really care about its global enable bit. Global enable bits
now may only

hwpmc: Skip GLOBAL_CTRL updates on stop_pmc().

After we wipe PMC configuration, including its local enable bit(s),
we don't really care about its global enable bit. Global enable bits
now may only be cleared by interrupt handler in case of error (sample
buffer overflow). Being set is actually a reset default for them.

This saves one WRMSR per process-scope PMC per context switch, that
is clearly visible in profiles.

MFC after: 1 month

show more ...

hwpmc: Bump Intel's IA32_PERFEVTSELx width to 64 bits.

Haswell added there bits 32/33 for TSX, and AlderLake added bit 34
for Adaptive PEBS Record.

MFC after: 1 month

hwpmc: Remove always zero pc_resync field.

MFC after: 1 month

hwpmc: Fix amd/arm64/armv7/uncore sampling overflow race

If a counter more than overflows just as we read it on switch out then,
if using sampling mode, we will negate this small value to give a hug

hwpmc: Fix amd/arm64/armv7/uncore sampling overflow race

If a counter more than overflows just as we read it on switch out then,
if using sampling mode, we will negate this small value to give a huge
reload count, and if we later switch back in that context we will
validate that value against pm_reloadcount and panic an INVARIANTS
kernel with:

panic: [pmc,1470] pmcval outside of expected range cpu=2 ri=16 pmcval=fffff292 pm_reloadcount=10000

or similar. Presumably in a non-INVARIANTS kernel we will instead just
use the provided value as the reload count, which would lead to the
overflow not happing for a very long time (e.g. 78 minutes for a 48-bit
counter incrementing at an averate rate of 1GHz).

Instead, clamp the reload count to 0 (which corresponds precisely to the
value we would compute if it had just overflowed and no more), which
will result in hwpmc using the full original reload count again. This is
the approach used by core for Intel (for both fixed and programmable
counters).

As part of this, armv7 and arm64 are made conceptually simpler; rather
than skipping modifying the overflow count for sampling mode counters so
it's always kept as ~0, those special cases are removed so it's always
applicable and the concatentation of it and the hardware counter can
always be viewed as a 64-bit counter, which also makes them look more
like other architectures.

Whilst here, fix an instance of UB (shifting a 1 into the sign bit) for
amd in its sign-extension code.

Reviewed by: andrew, mhorne, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D33654

show more ...

hwpmc: don't validate capabilities in allocation method

These checks were inconsistently applied across the various hwpmc
classes. The condition is already checked by the generic code in
hwpmc_mod.c

hwpmc: don't validate capabilities in allocation method

These checks were inconsistently applied across the various hwpmc
classes. The condition is already checked by the generic code in
hwpmc_mod.c, so remove them.

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

show more ...

hwpmc: consistently validate PMC class in allocation method

It is always a good idea. In one case, attempting to allocate N+1 PMCs
from a class with N hardware counters would incorrectly attempt to

hwpmc: consistently validate PMC class in allocation method

It is always a good idea. In one case, attempting to allocate N+1 PMCs
from a class with N hardware counters would incorrectly attempt to
allocate from the next class in the list. Without this validation, this
can lead to all kinds of strange behaviour.

Since powerpc_allocate_pmc() is used by both the mpc7xxx and ppc970
classes, add a new global to track which is active (it will never be
both).

Reviewed by: luporl, ray
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31387

show more ...

hwpmc: mostly clean up cc --analyze

Sponsored by: Rubicon Communications, LLC ("Netgate")

hwpmc: remove unused pre-table driven bits for intel

Intel now provides comprehensive tables for all performance counters
and the various valid configuration permutations as text .json files.
Libpmc

hwpmc: remove unused pre-table driven bits for intel

Intel now provides comprehensive tables for all performance counters
and the various valid configuration permutations as text .json files.
Libpmc has been converted to use these and hwpmc_core has been greatly
simplified by moving to passthrough of the table values.

The one gotcha is that said tables don't support pentium pro and and pentium
IV. There's very few users of hwpmc on _amd64_ kernels on new hardware. It is
unlikely that anyone is doing low level optimization on 15 year old Intel
hardware. Nonetheless, if someone feels strongly enough to populate the
corresponding tables for p4 and ppro I will reinstate the files in to the
build.

Code for the K8 counters and !x86 architectures remains unchanged.

show more ...

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error

sys/dev: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...

Remove slightly used const values that can be replaced with nitems().

Suggested by: jhb

Catch up with HEAD (r280229-r284686).

MFH: r282615-r283655

Sponsored by: The FreeBSD Foundation

Merge sync of head

Convert hwpmc(4) debug printfs over to KTR.

Differential Revision: https://reviews.freebsd.org/D2487
Reviewed by: davide, emaste
MFC after: 2 weeks
Sponsored by: Norse Corp, Inc.

MFhead @ r277403

Reintegrate head: r274132-r277384

Sponsored by: The FreeBSD Foundation