When booting to VHE we need to handle using the PMU at either EL1 or
EL2. WE already support EL1 so add support for EL2.
Reviewed by: mhorne
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45527
Add braces to the dmc620 MD4 macro to fix the GCC build.
Reviewed by: brooks, imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D45266
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
This includes event definitions from sys/pmc_events.h, definitions from
sys/pmc.h, and the man pages.
Reviewed by: jkoshy
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41275
This is i386-only, and has been effectively disabled since 2018 when the
companion support was removed from libpmc (e92a1350b5). Remove the
kernel support to simplify the AMD class.
Reviewed by: jkoshy
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41274
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
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 (959826ca1b, 81eb4dcf9e).
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 (dfb4fb4116). Later, pmu-events support for arm64 and power8
CPUs was added (28dd6730a5 and b48a2770d4).
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, 21f7397a61.
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
Free allocated per-CPU structures in the pcpu_fini and finalize methods.
While here, add debug trace entries to these methods.
Reviewed by: jkoshy, andrew
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41269
Free allocated per-CPU structures in the pcpu_fini and finalize methods.
While here, add debug trace entries to these methods.
Reviewed by: jkoshy, andrew
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41268
It points to non-existent documentation. The wiki page still contains a
useful overview, so keep this link.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Use a goto to clarify the control flow when there is no process
descriptor. This wins back a level of indentation.
No functional change intended.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40518
Split out the functional logic from the syscall handler into a helper
function. This keeps it separate from the syscall control-flow logic,
resulting in better readability overall. It also wins back a level of
indentation.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40294
Split out the functional logic from the syscall handler into a helper
function. This keeps it separate from the syscall control-flow logic,
resulting in better readability overall. It also wins back a level of
indentation.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40293
Split out the large chunk of functional logic from the syscall handler
into a helper function. This keeps it separate from the syscall
control-flow logic, resulting in better readability overall. It also
wins back a level of indentation.
Flip the return values of the pmc_can_allocate_row() and
pmc_can_allocate_rowindex() functions to boolean types, like their
naming implies. We weren't actually using the error codes they were
returning.
While here, make some small style cleanups. No functional change
intended.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40292
Begin splitting out the large chunks of functional logic from the
syscall handler into separate helper functions. This keeps it separate
from the syscall control-flow logic, resulting in better readability
overall. It also wins back a level of indentation.
For this and the similar changes to follow, try to keep copyin() and
copyout() calls outside of the helper functions. The changes are
intended to have no functional impact, but do address style issues.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40291
Move the functionality into a separate helper function. All other
actions in pmc_hook_handler() already have this.
While here make some small style improvements. Restructure one for loop.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40333
Everything else I found worthy of adjustment.
- Order local variable declarations per style(9)
- Make use of __unused annotations rather than cast to void
- Remove unnecessary casts
- Add (void) casts to PMC class methods where the return value is
ignored
- A couple instances of reordering statements for clarity
- Prefer bool type where applicable
- unsigned int -> u_int
- Use uintmax_t/%j in printf calls
- Formatting of comments
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40517
- Explicitly check the value in conditional statements, per style(9)
- Add braces around more loops and conditionals, wherever it appears
(to me) to aid legibility
- Expand some assignments within if statements
- Fix formatting around list-type FOREACH macros
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40515
Handle a few things related to spacing:
- Remove redundant/superfluous blank lines (and add a couple where
helpful)
- Add spacing around binary operators
- Remove spacing after casts and before goto labels
- Adjustments for line width of 80 chars
- Tab/space character issues
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40514
Currently the PROCEXEC event only reports a single address, entryaddr,
which is the entry point of the interpreter in the typical dynamic case,
and used solely to calculate the base address of the interpreter. For
PDEs this is fine, since the base address is known from the program
headers, but for PIEs the base address varies at run time based on where
the kernel chooses to load it, and so pmcstat has no way of knowing the
real address ranges for the executable. This was less of an issue in the
past since PIEs were rare, but now they're on by default on 64-bit
architectures it's more of a problem.
To solve this, pass through what was picked for et_dyn_addr by the
kernel, and use that as the offset for the executable's start address
just as is done for everything in the kernel. Since we're changing this
interface, sanitise the way we determine the interpreter's base address
by passing it through directly rather than indirectly via the entry
point and having to subtract off whatever the ELF header's e_entry is
(and anything that wants the entry point in future can still add that
back on as needed; this merely changes the interface to directly provide
the underlying variables involved).
This will be followed up by a bump to the pmc major version.
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D39595
This unifies the user object and kernel module paths in libpmcstat,
allows modules loaded from non-standard locations (e.g. from a user's
home directory when testing) to be found and, since buffer is what all
the warnings here use (they were never updated when buffer_modules were
added to pick based on where the file was found) has the side-effect of
ensuring the messages are correct.
This includes obsoleting the now-superfluous -k option in pmcstat.
This change breaks the hwpmc ABI and will be followed by a bump to the
pmc major version.
Reviewed by: jhb, jkoshy, mhorne
Differential Revision: https://reviews.freebsd.org/D40048
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
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
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
These are preferred over casts to void. No functional change.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39914
Most platforms (non-x86) don't require these methods and implement stub
versions. If we initialize the pmc_mdep structure to always point to the
generic versions, then we can purge the duplicate stubs.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39913
These are unused on all platforms.
Reviewed by: jkoshy, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39912
Provide the log type names in their entirely, rather than relying on the
macro to prepend the prefix. This improves their searchability; for
example, if I see PMCLOG_TYPE_PMCALLOCATE in libpmc I will now be able
to find where that is emitted in the kernel with a simple grep.
Reviewed by: jkoshy, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39911
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
This existing helper function is preferable to the hand-rolled
calculation of the kstack bounds.
Make some small style improvements while here. Notably, rename every
instance of "r", the return address, to "ra". Tidy the includes in the
affected files.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39909
Use the unwind_frame() function, which properly validates the frame
pointer and uses ADDR_MAKE_CANONICAL() for the pc, required when PAC is
enabled.
Reviewed by: andrew, markj, jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39934
Improve the legibility of the list. Bump overall indentation, fix some
whitespace, and sort the IAF block.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39903
This comment is no longer in sync with the contents of __PMC_EVENTS().
Update to reflect the removal of various Intel event definitions from
this list; these event definitions now come from Linux and live in
lib/libpmc/pmu-events/.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39902
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
These are maintained elsewhere. No functional change.
Reviewed by: jkoshy
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39900
A subsequent commit will instead use existing infrastructure to
exclude the files from hwpmc.ko for non-ACPI builds. Note that the
original commit left the files as optional in sys/conf/files.arm64.
This reverts commit 751d88119f.
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38736
