summaryrefslogtreecommitdiffstats
path: root/sys/cddl/dev/dtrace/powerpc
Commit message (Collapse)AuthorAgeFilesLines
* MFC r314370,r318130,r318167:jhibbits2017-05-201-30/+27
| | | | | | | | | | | DTrace related fixes for PowerPC. r314370: Unbreak kernel breakpoints, broken for ~4 years now r318130: Fix the encoded instruction for FBT traps on powerpc r318167: Fix stack tracing in dtrace for powerpc
* MFC r303796:jhibbits2016-12-232-2/+8
| | | | | | | Two fixups for dtrace * Use the right incantation to get the next stack pointer. * Clear EE using the correct instruction sequence.
* Add an EARLY_AP_STARTUP option to start APs earlier during boot.jhb2016-05-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make the second argument of dtrace_invop() a trapframe pointer.markj2016-04-171-9/+8
| | | | | | | | | | | | | 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.
* Remove unused variables dtrace_in_probe and dtrace_in_probe_addr.markj2016-03-171-2/+0
|
* dtrace_getarg: remove stray return statement on amd64, powerpcavg2015-09-291-1/+0
| | | | MFC after: 10 days
* Fix DTrace's panic() action.markj2015-04-241-40/+0
| | | | | | | | | | | | It would previously call into some unfinished Solaris compatibility code and return without actually calling panic(9). The compatibility code is unneeded, however, so just remove it and have dtrace_panic() call vpanic(9) directly. Differential Revision: https://reviews.freebsd.org/D2349 Reviewed by: avg MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division
* Fix build after unifying DAR/DEAR storage in trap frame.nwhitehorn2015-03-051-1/+1
|
* Restore the trap type argument to the DTrace trap hook, removed in r268600.markj2014-12-231-2/+3
| | | | | | It's redundant at the moment since it can be obtained from the trapframe on the architectures where DTrace is supported, but this won't be the case with ARM.
* Fix the stack tracing for dtrace/powerpc.jhibbits2014-09-171-19/+121
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix the stack tracing for dtrace/powerpc by using the trapexit/asttrapexit return address sentinels instead of checking within the kernel address space. As part of this, I had to add new inline functions. FBT traces the kernel, so we have to have special case handling for this, since a trap will create a full new trap frame, and there's no way to pass around the 'real' stack. I handle this by special-casing 'aframes == 0' with the trap frame. If aframes counts out to the trap frame, then assume we're looking for the full kernel trap frame, so switch to the real stack pointer. Test Plan: Tested on powerpc64 Reviewers: rpaulo, markj, nwhitehorn Reviewed By: markj, nwhitehorn Differential Revision: https://reviews.freebsd.org/D788 MFC after: 3 week Relnotes: Yes
* Invoke the DTrace trap handler before calling trap() on amd64. This matchesmarkj2014-07-141-4/+3
| | | | | | | | | | | the upstream implementation and helps ensure that a trap induced by tracing fbt::trap:entry is handled without recursively generating another trap. This makes it possible to run most (but not all) of the DTrace tests under common/safety/ without triggering a kernel panic. Submitted by: Anton Rang <anton.rang@isilon.com> (original version) Phabric: D95
* ELF PowerPC64 ABI puts the LR save word at 16 byte offset, not 8.jhibbits2013-10-251-1/+2
|
* Whitespace cleanup.jhibbits2013-09-021-48/+48
|
* Fixes for DTrace on PowerPC:jhibbits2013-08-312-88/+207
| | | | | | - Implement dtrace_getarg() - Sync fbt with x86, and fix a typo. - Pull in the time synchronization code from amd64.
* Make dtrace_copy() actually work on PowerPC. Although unused currently,jhibbits2013-08-221-4/+4
| | | | it may be used in the future by dtrace.
* Fix some ppc64 dtrace bugs, and enable systrace_freebsd32 for ppc64.jhibbits2013-08-192-0/+15
|
* Add FBT for PowerPC DTrace. Also, clean up the DTrace assembly code,jhibbits2013-03-183-43/+101
| | | | | | | | | | | much of which is not necessary for PowerPC. The FBT module can likely be factored into 3 separate files: common, intel, and powerpc, rather than duplicating most of the code between the x86 and PowerPC flavors. All DTrace modules for PowerPC will be MFC'd together once Fasttrap is completed.
* Fix the PowerPC DTrace copy functions. The kernel doesn't hold the same view tojhibbits2013-02-032-66/+61
| | | | | | the user map, so use the md copy in/out functions provided by the kernel. MFC with: r242723
* Implement DTrace for PowerPC. This includes both 32-bit and 64-bit.jhibbits2012-11-074-0/+1067
There is one known issue: Some probes will display an error message along the lines of: "Invalid address (0)" I tested this with both a simple dtrace probe and dtruss on a few different binaries on 32-bit. I only compiled 64-bit, did not run it, but I don't expect problems without the modules loaded. Volunteers are welcome. MFC after: 1 month
OpenPOWER on IntegriCloud