#
cc3da195 |
| 22-Nov-2024 |
Mark Johnston <markj@FreeBSD.org> |
dtrace/amd64: Make invop providers usable with KMSAN enabled
- Use a fresh context when entering dtrace_invop() via a breakpoint exception. - Mark the #BP trapframe as initialized.
MFC after: 2 w
dtrace/amd64: Make invop providers usable with KMSAN enabled
- Use a fresh context when entering dtrace_invop() via a breakpoint exception. - Mark the #BP trapframe as initialized.
MFC after: 2 weeks
show more ...
|
Revision tags: release/13.4.0, release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
e49c7cd6 |
| 09-Oct-2023 |
Ed Maste <emaste@FreeBSD.org> |
dtrace: remove x86 non-EARLY_AP_STARTUP support
After 792655abd64c EARLY_AP_STARTUP is mandatory for x86.
Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://revi
dtrace: remove x86 non-EARLY_AP_STARTUP support
After 792655abd64c EARLY_AP_STARTUP is mandatory for x86.
Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D42139
show more ...
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
#
1a149d65 |
| 20-Apr-2023 |
Christos Margiolis <christos@FreeBSD.org> |
dtrace: get rid of uchar_t types
Callers are specifying uint8_t anyway and this slightly reduces dependencies on compatibility typedefs. No functional change intended.
Reviewed by: markj, mhorne M
dtrace: get rid of uchar_t types
Callers are specifying uint8_t anyway and this slightly reduces dependencies on compatibility typedefs. No functional change intended.
Reviewed by: markj, mhorne MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D39490
show more ...
|
Revision tags: release/13.2.0, release/12.4.0 |
|
#
bdd101c4 |
| 04-Oct-2022 |
Mark Johnston <markj@FreeBSD.org> |
dtrace: Add a "regs" variable
This allows invop-based providers (i.e., fbt and kinst) to expose the register file of the CPU at the point where the probe fired. It does not work for SDT providers b
dtrace: Add a "regs" variable
This allows invop-based providers (i.e., fbt and kinst) to expose the register file of the CPU at the point where the probe fired. It does not work for SDT providers because their probes are implemented as plain function calls and so don't save registers. It's not clear what semantics "regs" should have for them anyway.
This is akin to "uregs", which nominally provides access to the userspace registers. In fact, DIF already had a DIF_VAR_REGS variable defined, it was simply unimplemented.
Usage example: print the contents of %rdi upon each call to amd64_syscall():
fbt::amd64_syscall:entry {printf("%x", regs[R_RDI]);}
Note that the R_* constants are defined in /usr/lib/dtrace/regs_x86.d. Currently there are no similar definitions for non-x86 platforms.
Reviewed by: christos MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D36799
show more ...
|
#
3ba8e9dc |
| 09-Aug-2022 |
Mark Johnston <markj@FreeBSD.org> |
dtrace/amd64: Implement emulation of call instructions
Here, the provider is responsible for updating the trapframe to redirect control flow and for computing the return address. Once software-save
dtrace/amd64: Implement emulation of call instructions
Here, the provider is responsible for updating the trapframe to redirect control flow and for computing the return address. Once software-saved registers are restored, the emulation shifts the remaining context down on the stack to make space for the return address, then copies the address provided by the invop handler. dtrace_invop() is modified to allocate temporary storage space on the stack for use by the provider to return the return address.
This is to support a new provider for amd64 which can instrument arbitrary instructions, not just function entry and exit instructions as FBT does.
In collaboration with: christos Sponsored by: Google, Inc. (GSoC 2022) Sponsored by: The FreeBSD Foundation MFC after: 2 weeks
show more ...
|
Revision tags: release/13.1.0, release/12.3.0, release/13.0.0, release/12.2.0 |
|
#
e2515283 |
| 27-Aug-2020 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
9e5787d2 |
| 25-Aug-2020 |
Matt Macy <mmacy@FreeBSD.org> |
Merge OpenZFS support in to HEAD.
The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort.
I would a
Merge OpenZFS support in to HEAD.
The primary benefit is maintaining a completely shared code base with the community allowing FreeBSD to receive new features sooner and with less effort.
I would advise against doing 'zpool upgrade' or creating indispensable pools using new features until this change has had a month+ to soak.
Work on merging FreeBSD support in to what was at the time "ZFS on Linux" began in August 2018. I first publicly proposed transitioning FreeBSD to (new) OpenZFS on December 18th, 2018. FreeBSD support in OpenZFS was finally completed in December 2019. A CFT for downstreaming OpenZFS support in to FreeBSD was first issued on July 8th. All issues that were reported have been addressed or, for a couple of less critical matters there are pull requests in progress with OpenZFS. iXsystems has tested and dogfooded extensively internally. The TrueNAS 12 release is based on OpenZFS with some additional features that have not yet made it upstream.
Improvements include: project quotas, encrypted datasets, allocation classes, vectorized raidz, vectorized checksums, various command line improvements, zstd compression.
Thanks to those who have helped along the way: Ryan Moeller, Allan Jude, Zack Welch, and many others.
Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D25872
show more ...
|
#
9ce875d9 |
| 23-Aug-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
amd64 pmap: LA57 AKA 5-level paging
Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming.
This patch makes pmap su
amd64 pmap: LA57 AKA 5-level paging
Since LA57 was moved to the main SDM document with revision 072, it seems that we should have a support for it, and silicons are coming.
This patch makes pmap support both LA48 and LA57 hardware. The selection of page table level is done at startup, kernel always receives control from loader with 4-level paging. It is not clear how UEFI spec would adapt LA57, for instance it could hand out control in LA57 mode sometimes.
To switch from LA48 to LA57 requires turning off long mode, requesting LA57 in CR4, then re-entering long mode. This is somewhat delicate and done in pmap_bootstrap_la57(). AP startup in LA57 mode is much easier, we only need to toggle a bit in CR4 and load right value in CR3.
I decided to not change kernel map for now. Single PML5 entry is created that points to the existing kernel_pml4 (KML4Phys) page, and a pml5 entry to create our recursive mapping for vtopte()/vtopde(). This decision is motivated by the fact that we cannot overcommit for KVA, so large space there is unusable until machines start providing wider physical memory addressing. Another reason is that I do not want to break our fragile autotuning, so the KVA expansion is not included into this first step. Nice side effect is that minidumps are compatible.
On the other hand, (very) large address space is definitely immediately useful for some userspace applications.
For userspace, numbering of pte entries (or page table pages) is always done for 5-level structures even if we operate in 4-level mode. The pmap_is_la57() function is added to report the mode of the specified pmap, this is done not to allow simultaneous 4-/5-levels (which is not allowed by hw), but to accomodate for EPT which has separate level control and in principle might not allow 5-leve EPT despite x86 paging supports it. Anyway, it does not seems critical to have 5-level EPT support now.
Tested by: pho (LA48 hardware) Reviewed by: alc Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273
show more ...
|
Revision tags: release/11.4.0, release/12.1.0 |
|
#
668ee101 |
| 26-Sep-2019 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r352587 through r352763.
|
#
9093dd9a |
| 23-Sep-2019 |
Mark Johnston <markj@FreeBSD.org> |
Implement x86 dtrace_invop_(un)init() in C.
There is no reason for these routines to be written in assembly. In the ports of DTrace to other platforms, they are already written in C. No functional
Implement x86 dtrace_invop_(un)init() in C.
There is no reason for these routines to be written in assembly. In the ports of DTrace to other platforms, they are already written in C. No functional change intended.
MFC after: 1 week Sponsored by: Netflix
show more ...
|
Revision tags: release/11.3.0 |
|
#
415e34c4 |
| 29-Mar-2019 |
Alan Somers <asomers@FreeBSD.org> |
MFHead@r345677
|
#
a4b59d3d |
| 21-Mar-2019 |
Mark Johnston <markj@FreeBSD.org> |
Use an explicit comparison with VM_GUEST_NO.
Reported by: jhb MFC with: r345359 Sponsored by: The FreeBSD Foundation
|
#
e362e590 |
| 21-Mar-2019 |
Mark Johnston <markj@FreeBSD.org> |
Don't attempt to measure TSC skew when running as a VM guest.
It simply doesn't work in general since VCPUs may migrate between physical cores. The approach used to measure skew also doesn't make m
Don't attempt to measure TSC skew when running as a VM guest.
It simply doesn't work in general since VCPUs may migrate between physical cores. The approach used to measure skew also doesn't make much sense in a VM.
PR: 218452 MFC after: 2 weeks Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/12.0.0, release/11.2.0 |
|
#
d41e41f9 |
| 27-Mar-2018 |
John Baldwin <jhb@FreeBSD.org> |
Remove very old and unused signal information codes.
These have been supplanted by the MI signal information codes in <sys/signal.h> since 7.0. The FPE_*_TRAP ones were deprecated even earlier in 1
Remove very old and unused signal information codes.
These have been supplanted by the MI signal information codes in <sys/signal.h> since 7.0. The FPE_*_TRAP ones were deprecated even earlier in 1999.
PR: 226579 (exp-run) Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D14637
show more ...
|
#
6c7828a2 |
| 18-Dec-2017 |
Mark Johnston <markj@FreeBSD.org> |
Avoid CPU migration in dtrace_gethrtime() on x86.
dtrace_gethrtime() may be called outside of probe context, and in particular, from the DTRACEIOC_BUFSNAP handler.
Disable interrupts rather than us
Avoid CPU migration in dtrace_gethrtime() on x86.
dtrace_gethrtime() may be called outside of probe context, and in particular, from the DTRACEIOC_BUFSNAP handler.
Disable interrupts rather than using sched_pin() to help ensure that we don't call any external functions when in probe context.
PR: 218452 MFC after: 1 week
show more ...
|
Revision tags: release/10.4.0, release/11.1.0 |
|
#
67d955aa |
| 09-Apr-2017 |
Patrick Kelsey <pkelsey@FreeBSD.org> |
Corrected misspelled versions of rendezvous.
The MFC will include a compat definition of smp_no_rendevous_barrier() that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib MFC after: 1 week D
Corrected misspelled versions of rendezvous.
The MFC will include a compat definition of smp_no_rendevous_barrier() that calls smp_no_rendezvous_barrier().
Reviewed by: gnn, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D10313
show more ...
|
#
a3906ca5 |
| 17-Feb-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r313644 through r313895.
|
#
7174af79 |
| 17-Feb-2017 |
Mark Johnston <markj@FreeBSD.org> |
Directly include needed headers rather than relying on pollution.
We get machine/cpu.h via kmem.h -> proc.h -> _vm_domain.h -> seq.h.
Reported by: Ryan Libby Sponsored by: Dell EMC Isilon X-MFC wit
Directly include needed headers rather than relying on pollution.
We get machine/cpu.h via kmem.h -> proc.h -> _vm_domain.h -> seq.h.
Reported by: Ryan Libby Sponsored by: Dell EMC Isilon X-MFC with: r313841
show more ...
|
#
a11ac730 |
| 17-Feb-2017 |
Mark Johnston <markj@FreeBSD.org> |
Prevent CPU migration when checking the DTrace nofault flag on x86.
dtrace_trap() consumes page and protection faults triggered by code running in DTrace probe context. Such faults occur with interr
Prevent CPU migration when checking the DTrace nofault flag on x86.
dtrace_trap() consumes page and protection faults triggered by code running in DTrace probe context. Such faults occur with interrupts disabled and are detected using a per-CPU flag. Regular faults cause dtrace_trap() to be called with interrupts enabled, and nothing was ensuring that the flag was read from the correct CPU. This may result in dtrace_trap() consuming unrelated page and protection faults when DTrace is enabled, causing the fault handler to return without actually having handled the fault.
Diagnosed by: Ryan Libby <rlibby@gmail.com> MFC after: 3 days Sponsored by: Dell EMC Isilon
show more ...
|
Revision tags: release/11.0.1, release/11.0.0 |
|
#
fdce57a0 |
| 14-May-2016 |
John Baldwin <jhb@FreeBSD.org> |
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI
Add an EARLY_AP_STARTUP option to start APs earlier during boot.
Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot.
This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed.
This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs.
However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu.
Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case.
As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code.
These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling).
PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
show more ...
|
#
6c280659 |
| 18-Apr-2016 |
Mark Johnston <markj@FreeBSD.org> |
Make the second argument of dtrace_invop() a trapframe pointer.
Currently this argument is a pointer into the stack which is used by FBT to fetch the first five probe arguments. On all non-x86 archi
Make the second argument of dtrace_invop() a trapframe pointer.
Currently this argument is a pointer into the stack which is used by FBT to fetch the first five probe arguments. On all non-x86 architectures it's simply the trapframe address, so this change has no functional impact. On amd64 it's a pointer into the trapframe such that stack[1 .. 5] gives the first five argument registers, which are deliberately grouped together in the amd64 trapframe definition.
A trapframe argument simplifies the invop handlers on !x86 and makes the x86 FBT invop handler easier to understand. Moreover, it allows for invop handlers that may want to modify the register set of the interrupted thread.
show more ...
|
#
876d357f |
| 11-Apr-2016 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: The FreeBSD Foundation
|
#
e1e33ff9 |
| 10-Apr-2016 |
Mark Johnston <markj@FreeBSD.org> |
Initialize DTrace hrtimer frequency during SI_SUB_CPU on i386 and amd64.
This allows the hrtimer to be used earlier during boot. This is required for boot-time DTrace: anonymous enablings are create
Initialize DTrace hrtimer frequency during SI_SUB_CPU on i386 and amd64.
This allows the hrtimer to be used earlier during boot. This is required for boot-time DTrace: anonymous enablings are created during SI_SUB_DTRACE_ANON, which runs before APs are started. In particular, the DTrace deadman timer requires that the hrtimer be functional.
MFC after: 2 weeks
show more ...
|
#
d6084013 |
| 05-Apr-2016 |
Glen Barber <gjb@FreeBSD.org> |
MFH
Sponsored by: The FreeBSD Foundation
|