kinst: start moving towards per-probe trampolines

Using per-CPU and per-thread trampolines is expensive and error-prone,
since we're rewriting the same memory blocks constantly. Per-probe
trampolines solve this problem by giving each probe its own block of
executable memory, which more or less remains the same after the initial
write.

What this patch does, is get rid of the initialization code which
allocates a trampoline for each thread, and instead let each port of
kinst allocate a trampoline for each new probe created. It also sets up
the infrastructure needed to support the new trampoline scheme.

This change is not currently supported on amd64, as the amd64 port needs
further changes to work, so this is a temporary/gradual patch to fix the
riscv and arm64 ports.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40962

kinst: update LICENSE headers

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40875

kinst: rename t_kinst to t_kinst_tramp

The forthcoming RISC-V and ARM64 ports of kinst introduce a new field
named "t_kinst_curprobe", so "t_kinst" (which points to a trampoline)
becomes a misleading name.

No functional change intended.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40507

kinst: hide KINST_TRAMPCHUNK_SIZE from ISA-specific headers

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40505

kinst: simplify trampoline fill definitions

Centralize KINST_TRAMP_FILL_PATTERN and KINST_TRAMP_FILL_SIZE to reduce
redefinitions, and use the architecture-dependent kinst_patchval_t as
their size.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40406

kinst: be explicit about trampoline placement

The current implementation and comment was specific to amd64. Even
though in the case of kinst's supported architectures (RISC-V and ARM64)
VM_MIN_KERNEL_ADDRESS is equal to KERNBASE, it's better to be explicit.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40266

kinst: replace KINST_TRAMP_INIT

The current implementation of KINST_TRAMP_INIT is working only on amd64,
where the breakpoint instruction is one byte long, which might not be
the case for other architectures (e.g in RISC-V it's either 2 or 4
bytes). This patch introduces two machine-dependent constants,
KINST_TRAMP_FILL_PATTERN and KINST_TRAMP_FILL_SIZE, which hold the fill
instruction and the size of that instruction in bytes respectively.

Reviewed by: markj
Approved by: markj (mentor)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39504

kinst: test lock in kinst_trampoline_dealloc_locked()

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

kinst: Correct a comment

Fixes: f0bc4ed144fc ("kinst: Initial revision")

kinst: Clarify a comment in the trampoline allocator

Fixes: f0bc4ed144fc ("kinst: Initial revision")

kinst: Remove an unused constant

This was left over after a rework of the trampoline allocator.

Fixes: f0bc4ed144fc ("kinst: Initial revision")

kinst: Initial revision

This is a new DTrace provider which allows arbitrary kernel instructions
to be traced. Currently it is implemented only for amd64.

kinst probes are created on demand by libdtrace, and there is a probe
for each kernel instruction. Probes are named
kinst:<module>:<function>:<offset>, where "offset" is the offset of the
target instruction relative to the beginning of the function. Omitting
"offset" causes all instructions in the function to be traced.

kinst works similarly to FBT in that it places a breakpoint on the
target instruction and hooks into the kernel breakpoint handler.
Because kinst has to be able to trace arbitrary instructions, it does
not emulate most of them in software but rather causes the traced thread
to execute a copy of the instruction before returning to the original
code.

The provider is quite low-level and as-is will be useful mostly only to
kernel developers. However, it provides a great deal of visibility into
kernel code execution and could be used as a building block for
higher-level tooling which can in some sense translate between C sources
and generated machine code. In particular, the "regs" variable recently
added to D allows the CPU's register file to be accessed from kinst
probes.

kinst is experimental and should not be used on production systems for
now.

In collaboration with: markj
Sponsored by: Google, Inc. (GSoC 2022)
MFC after: 3 months
Differential Revision: https://reviews.freebsd.org/D36851