aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-05-18riscv: Add SW single-step support for KDBVincent Chen2-2/+396
In KGDB, the GDB in the host is responsible for the single-step operation of the software. In other words, KGDB does not need to derive the next pc address when performing a software single-step operation. KGDB just inserts the break instruction at the indicated address according to the GDB instructions. This approach does not work in KDB because the GDB does not involve the KDB process. Therefore, this patch provides KDB a software single-step mechanism to use. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18riscv: Use the XML target descriptions to report 3 system registersVincent Chen4-1/+140
The $status, $badaddr, and $cause registers belong to the thread context, so KGDB can obtain their contents from pt_regs in each trap. However, the sequential number of these registers in the gdb register list is far from the general-purpose registers. If riscv port uses the existing method to report these three registers, many trivial registers with sequence numbers in the middle of them will also be packaged to the reply packets. To solve this problem, the riscv port wants to introduce the GDB target description mechanism to customize the reported register list. By the list, the KGDB can ignore the intermediate registers and just reports the general-purpose registers and these three system registers. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18riscv: Add KGDB supportVincent Chen6-0/+325
The skeleton of RISC-V KGDB port. Signed-off-by: Vincent Chen <vincent.chen@sifive.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18RISC-V: Skip setting up PMPs on trapsPalmer Dabbelt1-1/+10
The RISC-V ISA manual says that PMPs are WARL, but it appears the K210 doesn't implement them and instead traps on the unsupported accesses. This patch handles those traps by just skipping the PMP initialization entirely, under the theory that machines that trap on PMP accesses must allow memory accesses as otherwise they're pretty useless. Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18riscv: K210: Update defconfigDamien Le Moal1-5/+2
Update the Kendryte K210 default kernel configuration file nommu_k210_defconfig to enable builtin DTB by default. Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18riscv: K210: Add a built-in device treePalmer Dabbelt3-2/+21
The K210's bootloader does not provide a device tree. Give the ability to providea builtin one with the SOC_KENDRYTE_K210_BUILTIN_DTB option. If selected, this option result in the definition of a builtin DTB entry in the k210 sysctl driver. If defined, the builtin DTB entry points to the default k210.dts device tree file and is keyed with the vendor ID 0x4B5, the arch ID 0xE59889E6A5A04149 ("Canaan AI" in UTF-8 coded Chinese) and the impl ID 0x4D41495832303030 ("MAIX200"). These values are reported by the SiPEED MAIXDUINO board, the SiPEED MAIX Go board and the SiPEED Dan Dock board. [Thanks to Damien for the K210 IDs] Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18riscv: Allow device trees to be built into the kernelPalmer Dabbelt7-0/+90
Some systems don't provide a useful device tree to the kernel on boot. Chasing around bootloaders for these systems is a headache, so instead le't's just keep a device tree table in the kernel, keyed by the SOC's unique identifier, that contains the relevant DTB. This is only implemented for M mode right now. While we could implement this via the SBI calls that allow access to these identifiers, we don't have any systems that need this right now. Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-05-18x86/cpu: Use RDRAND and RDSEED mnemonics in archrandom.hUros Bizjak1-18/+8
Current minimum required version of binutils is 2.23, which supports RDRAND and RDSEED instruction mnemonics. Replace the byte-wise specification of RDRAND and RDSEED with these proper mnemonics. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20200508105817.207887-1-ubizjak@gmail.com
2020-05-18arm64: stacktrace: Factor out some common code into on_stack()Yunfeng Ye2-52/+16
There are some common codes for stack checking, so factors it out into the function on_stack(). No functional change. Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com> Link: https://lore.kernel.org/r/07b3b0e6-3f58-4fed-07ea-7d17b7508948@huawei.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18arm64: Call debug_traps_init() from trap_init() to help early kgdbDouglas Anderson3-4/+4
A new kgdb feature will soon land (kgdb_earlycon) that lets us run kgdb much earlier. In order for everything to work properly it's important that the break hook is setup by the time we process "kgdbwait". Right now the break hook is setup in debug_traps_init() and that's called from arch_initcall(). That's a bit too late since kgdb_earlycon really needs things to be setup by the time the system calls dbg_late_init(). We could fix this by adding call_break_hook() into early_brk64() and that works fine. However, it's a little ugly. Instead, let's just add a call to debug_traps_init() straight from trap_init(). There's already a documented dependency between trap_init() and debug_traps_init() and this makes the dependency more obvious rather than just relying on a comment. NOTE: this solution isn't early enough to let us select the "ARCH_HAS_EARLY_DEBUG" KConfig option that is introduced by the kgdb_earlycon patch series. That would only be set if we could do breakpoints when early params are parsed. This patch only enables "late early" breakpoints, AKA breakpoints when dbg_late_init() is called. It's expected that this should be fine for most people. It should also be noted that if you crash you can still end up in kgdb earlier than debug_traps_init(). Since you don't need breakpoints to debug a crash that's fine. Suggested-by: Will Deacon <will@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20200513160501.1.I0b5edf030cc6ebef6ab4829f8867cdaea42485d8@changeid Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18kgdb: Delay "kgdbwait" to dbg_late_init() by defaultDouglas Anderson1-0/+1
Using kgdb requires at least some level of architecture-level initialization. If nothing else, it relies on the architecture to pass breakpoints / crashes onto kgdb. On some architectures this all works super early, specifically it starts working at some point in time before Linux parses early_params's. On other architectures it doesn't. A survey of a few platforms: a) x86: Presumably it all works early since "ekgdboc" is documented to work here. b) arm64: Catching crashes works; with a simple patch breakpoints can also be made to work. c) arm: Nothing in kgdb works until paging_init() -> devicemaps_init() -> early_trap_init() Let's be conservative and, by default, process "kgdbwait" (which tells the kernel to drop into the debugger ASAP at boot) a bit later at dbg_late_init() time. If an architecture has tested it and wants to re-enable super early debugging, they can select the ARCH_HAS_EARLY_DEBUG KConfig option. We'll do this for x86 to start. It should be noted that dbg_late_init() is still called quite early in the system. Note that this patch doesn't affect when kgdb runs its init. If kgdb is set to initialize early it will still initialize when parsing early_param's. This patch _only_ inhibits the initial breakpoint from "kgdbwait". This means: * Without any extra patches arm64 platforms will at least catch crashes after kgdb inits. * arm platforms will catch crashes (and could handle a hardcoded kgdb_breakpoint()) any time after early_trap_init() runs, even before dbg_late_init(). Signed-off-by: Douglas Anderson <dianders@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200507130644.v4.4.I3113aea1b08d8ce36dc3720209392ae8b815201b@changeid Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
2020-05-18arm64: entry-ftrace.S: Update comment to indicate that x18 is liveWill Deacon1-2/+3
The Shadow Call Stack pointer is held in x18, so update the ftrace entry comment to indicate that it cannot be safely clobbered. Reported-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18scs: Move DEFINE_SCS macro into core codeWill Deacon1-4/+0
Defining static shadow call stacks is not architecture-specific, so move the DEFINE_SCS() macro into the core header file. Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18scs: Remove references to asm/scs.h from core codeWill Deacon1-2/+2
asm/scs.h is no longer needed by the core code, so remove a redundant header inclusion and update the stale Kconfig text. Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18scs: Move scs_overflow_check() out of architecture codeWill Deacon3-21/+1
There is nothing architecture-specific about scs_overflow_check() as it's just a trivial wrapper around scs_corrupted(). For parity with task_stack_end_corrupted(), rename scs_corrupted() to task_scs_end_corrupted() and call it from schedule_debug() when CONFIG_SCHED_STACK_END_CHECK_is enabled, which better reflects its purpose as a debug feature to catch inadvertent overflow of the SCS. Finally, remove the unused scs_overflow_check() function entirely. This has absolutely no impact on architectures that do not support SCS (currently arm64 only). Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18arm64: scs: Use 'scs_sp' register alias for x18Will Deacon3-8/+10
x18 holds the SCS stack pointer value, so introduce a register alias to make this easier to read in assembly code. Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18arm64: scs: Store absolute SCS stack pointer value in thread_infoWill Deacon3-8/+7
Storing the SCS information in thread_info as a {base,offset} pair introduces an additional load instruction on the ret-to-user path, since the SCS stack pointer in x18 has to be converted back to an offset by subtracting the base. Replace the offset with the absolute SCS stack pointer value instead and avoid the redundant load. Tested-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-18arm64: dts: juno: Fix SCPI shared mem node nameAndre Przywara1-2/+2
The SRAM DT binding requires child nodes to use a certain node name scheme. Change the naming from scp-shmem to scp-sram to comply with that. Link: https://lore.kernel.org/r/20200513103016.130417-19-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: vexpress: Fix VExpress LED namesAndre Przywara1-8/+8
The common LED binding wants the LED node names to start with led- and then have just a single number. Changing the naming for the 8 user LEDs from using user<x> to led-<x>. Also there is no default-trigger named "mmc0" in the kernel, so use the more generic "disk-activity". Link: https://lore.kernel.org/r/20200513103016.130417-18-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: juno: Fix GPU interrupt orderAndre Przywara1-4/+4
The Mali binding insists on the GPU interrupts to be in ordered as: job, mmu, gpu. Sort the GPU interrupts and interrupt-names properties accordingly. Link: https://lore.kernel.org/r/20200513103016.130417-17-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: fvp/juno: Fix bus node namesAndre Przywara6-10/+10
Most Arm Ltd. boards are employing a layered bus structure, to map the hardware design (SoC, motherboard, IOFPGA) and structure the DTs. The "simple-bus" nodes only allow a limited set of node names. Switch to use *-bus to be binding compliant. This relies on a pending dt-schema.git fix for now: https://github.com/devicetree-org/dt-schema/pull/38 Link: https://lore.kernel.org/r/20200513103016.130417-16-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: fvp: Fix SMMU DT nodeAndre Przywara1-4/+4
The SMMU name in the RevC FVP DT file was not fully binding compliant. Adjust the node name to match the binding's list of allowed names, also shuffle the order of the interrupts to comply with the expected order. Link: https://lore.kernel.org/r/20200513103016.130417-15-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: fvp/juno: Fix serial node namesAndre Przywara4-13/+13
The UARTs for all Arm Ltd. boards were using "uart" as their node name stub. Replace that with the required "serial" string, to comply with the PL011 DT binding. Link: https://lore.kernel.org/r/20200513103016.130417-14-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18arm64: dts: juno: Use proper DT node name for USBAndre Przywara1-2/+2
The EHCI/OCHI DT binding requires to use "usb" as the node name stub. Replace the existing name with "usb" to comply with the binding. Link: https://lore.kernel.org/r/20200513103016.130417-13-andre.przywara@arm.com Signed-off-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-18ARM: dts: at91: sama5d2_xplained: Add aliases for the dedicated I2C IPsTudor Ambarus1-0/+2
The sama5d2 SoC has two dedicated I2C IPs that are enabled on sama5d2_xplained. Add alias for the i2c devices to not rely on probe order for the i2c device numbering. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20200518114802.253660-1-tudor.ambarus@microchip.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2020-05-19powerpc/watchpoint/xmon: Support 2nd DAWRRavi Bangoria1-32/+69
Add support for 2nd DAWR in xmon. With this, we can have two simultaneous breakpoints from xmon. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-17-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint/xmon: Don't allow breakpoint overwritingRavi Bangoria1-0/+4
Xmon allows overwriting breakpoints because it's supported by only one DAWR. But with multiple DAWRs, overwriting becomes ambiguous or unnecessary complicated. So let's not allow it. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-16-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Don't allow concurrent perf and ptrace eventsRavi Bangoria2-0/+223
With Book3s DAWR, ptrace and perf watchpoints on powerpc behaves differently. Ptrace watchpoint works in one-shot mode and generates signal before executing instruction. It's ptrace user's job to single-step the instruction and re-enable the watchpoint. OTOH, in case of perf watchpoint, kernel emulates/single-steps the instruction and then generates event. If perf and ptrace creates two events with same or overlapping address ranges, it's ambiguous to decide who should single-step the instruction. Because of this issue, don't allow perf and ptrace watchpoint at the same time if their address range overlaps. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-15-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Prepare handler to handle more than one watchpointRavi Bangoria4-92/+310
Currently we assume that we have only one watchpoint supported by hw. Get rid of that assumption and use dynamic loop instead. This should make supporting more watchpoints very easy. With more than one watchpoint, exception handler needs to know which DAWR caused the exception, and hw currently does not provide it. So we need sw logic for the same. To figure out which DAWR caused the exception, check all different combinations of user specified range, DAWR address range, actual access range and DAWRX constrains. For ex, if user specified range and actual access range overlaps but DAWRX is configured for readonly watchpoint and the instruction is store, this DAWR must not have caused exception. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Reviewed-by: Michael Neuling <mikey@neuling.org> [mpe: Unsplit multi-line printk() strings, fix some sparse warnings] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200514111741.97993-14-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Use builtin ALIGN*() macrosRavi Bangoria4-13/+14
Currently we calculate hw aligned start and end addresses manually. Replace them with builtin ALIGN_DOWN() and ALIGN() macros. So far end_addr was inclusive but this patch makes it exclusive (by avoiding -1) for better readability. Suggested-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-13-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Introduce is_ptrace_bp() functionRavi Bangoria1-1/+6
Introduce is_ptrace_bp() function and move the check inside the function. It will be utilize more in later set of patches. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-12-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Use loop for thread_struct->ptrace_bpsRavi Bangoria3-10/+31
ptrace_bps is already an array of size HBP_NUM_MAX. But we use hardcoded index 0 while fetching/updating it. Convert such code to loop over array. ptrace interface to use multiple watchpoint remains same. eg: two PPC_PTRACE_SETHWDEBUG calls will create two watchpoint if underneath hw supports it. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-11-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Convert thread_struct->hw_brk to an arrayRavi Bangoria5-41/+78
So far powerpc hw supported only one watchpoint. But Power10 is introducing 2nd DAWR. Convert thread_struct->hw_brk into an array. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-10-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enableRavi Bangoria1-3/+7
Instead of disabling only first watchpoint, disable all available watchpoints while clearing dawr_force_enable. Callback function is used only for disabling watchpoint, rename it to disable_dawrs_cb(). And null_brk parameter is not really required while disabling watchpoint, remove it. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-9-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Get watchpoint count dynamically while disabling themRavi Bangoria1-7/+7
Instead of disabling only one watchpoint, get num of available watchpoints dynamically and disable all of them. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-8-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Provide DAWR number to __set_breakpointRavi Bangoria6-15/+15
Introduce new parameter 'nr' to __set_breakpoint() which indicates which DAWR should be programed. Also convert current_brk variable to an array. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-7-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Provide DAWR number to set_dawrRavi Bangoria3-8/+13
Introduce new parameter 'nr' to set_dawr() which indicates which DAWR should be programed. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-6-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint/ptrace: Return actual num of available watchpointsRavi Bangoria1-1/+1
User can ask for num of available watchpoints(dbginfo.num_data_bps) using ptrace(PPC_PTRACE_GETHWDBGINFO). Return actual number of available watchpoints on the machine rather than hardcoded 1. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-5-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Introduce function to get nr watchpoints dynamicallyRavi Bangoria4-3/+12
So far we had only one watchpoint, so we have hardcoded HBP_NUM to 1. But Power10 is introducing 2nd DAWR and thus kernel should be able to dynamically find actual number of watchpoints supported by hw it's running on. Introduce function for the same. Also convert HBP_NUM macro to HBP_NUM_MAX, which will now represent maximum number of watchpoints supported by Powerpc. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-4-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Add SPRN macros for second DAWRRavi Bangoria1-0/+2
Power10 is introducing second DAWR. Add SPRN_ macros for the same. Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-3-ravi.bangoria@linux.ibm.com
2020-05-19powerpc/watchpoint: Rename current DAWR macrosRavi Bangoria5-20/+20
Power10 is introducing second DAWR. Use real register names from ISA for current macros: s/SPRN_DAWR/SPRN_DAWR0/ s/SPRN_DAWRX/SPRN_DAWRX0/ Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michael Neuling <mikey@neuling.org> Link: https://lore.kernel.org/r/20200514111741.97993-2-ravi.bangoria@linux.ibm.com
2020-05-19powerpc sstep: Add support for prefixed fixed-point arithmeticJordan Niethe1-0/+20
This adds emulation support for the following prefixed Fixed-Point Arithmetic instructions: * Prefixed Add Immediate (paddi) Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Reviewed-by: Balamuruhan S <bala24@linux.ibm.com> [mpe: Squash in get_op() usage] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-31-jniethe5@gmail.com
2020-05-19powerpc sstep: Add support for prefixed load/storesJordan Niethe2-2/+166
This adds emulation support for the following prefixed integer load/stores: * Prefixed Load Byte and Zero (plbz) * Prefixed Load Halfword and Zero (plhz) * Prefixed Load Halfword Algebraic (plha) * Prefixed Load Word and Zero (plwz) * Prefixed Load Word Algebraic (plwa) * Prefixed Load Doubleword (pld) * Prefixed Store Byte (pstb) * Prefixed Store Halfword (psth) * Prefixed Store Word (pstw) * Prefixed Store Doubleword (pstd) * Prefixed Load Quadword (plq) * Prefixed Store Quadword (pstq) the follow prefixed floating-point load/stores: * Prefixed Load Floating-Point Single (plfs) * Prefixed Load Floating-Point Double (plfd) * Prefixed Store Floating-Point Single (pstfs) * Prefixed Store Floating-Point Double (pstfd) and for the following prefixed VSX load/stores: * Prefixed Load VSX Scalar Doubleword (plxsd) * Prefixed Load VSX Scalar Single-Precision (plxssp) * Prefixed Load VSX Vector [0|1] (plxv, plxv0, plxv1) * Prefixed Store VSX Scalar Doubleword (pstxsd) * Prefixed Store VSX Scalar Single-Precision (pstxssp) * Prefixed Store VSX Vector [0|1] (pstxv, pstxv0, pstxv1) Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Reviewed-by: Balamuruhan S <bala24@linux.ibm.com> [mpe: Use CONFIG_PPC64 not __powerpc64__, use get_op()] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-30-jniethe5@gmail.com
2020-05-19powerpc: Support prefixed instructions in alignment handlerJordan Niethe1-1/+18
If a prefixed instruction results in an alignment exception, the SRR1_PREFIXED bit is set. The handler attempts to emulate the responsible instruction and then increment the NIP past it. Use SRR1_PREFIXED to determine by how much the NIP should be incremented. Prefixed instructions are not permitted to cross 64-byte boundaries. If they do the alignment interrupt is invoked with SRR1 BOUNDARY bit set. If this occurs send a SIGBUS to the offending process if in user mode. If in kernel mode call bad_page_fault(). Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Alistair Popple <alistair@popple.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-29-jniethe5@gmail.com
2020-05-19powerpc/kprobes: Don't allow breakpoints on suffixesJordan Niethe1-0/+13
Do not allow inserting breakpoints on the suffix of a prefix instruction in kprobes. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-28-jniethe5@gmail.com
2020-05-19powerpc/xmon: Don't allow breakpoints on suffixesJordan Niethe1-2/+25
Do not allow placing xmon breakpoints on the suffix of a prefix instruction. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> [mpe: Don't split printf strings across lines] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-27-jniethe5@gmail.com
2020-05-19powerpc: Test prefixed instructions in feature fixupsJordan Niethe2-0/+144
Expand the feature-fixups self-tests to includes tests for prefixed instructions. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> [mpe: Use CONFIG_PPC64 not __powerpc64__, add empty inlines] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-26-jniethe5@gmail.com
2020-05-19powerpc: Test prefixed code patchingJordan Niethe3-1/+42
Expand the code-patching self-tests to includes tests for patching prefixed instructions. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> [mpe: Use CONFIG_PPC64 not __powerpc64__] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-25-jniethe5@gmail.com
2020-05-19powerpc: Add prefixed instructions to instruction data typeJordan Niethe14-17/+175
For powerpc64, redefine the ppc_inst type so both word and prefixed instructions can be represented. On powerpc32 the type will remain the same. Update places which had assumed instructions to be 4 bytes long. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Reviewed-by: Alistair Popple <alistair@popple.id.au> [mpe: Rework the get_user_inst() macros to be parameterised, and don't assign to the dest if an error occurred. Use CONFIG_PPC64 not __powerpc64__ in a few places. Address other comments from Christophe. Fix some sparse complaints.] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200506034050.24806-24-jniethe5@gmail.com
2020-05-19powerpc/optprobes: Add register argument to patch_imm64_load_insns()Jordan Niethe1-17/+17
Currently patch_imm32_load_insns() is used to load an instruction to r4 to be emulated by emulate_step(). For prefixed instructions we would like to be able to load a 64bit immediate to r4. To prepare for this make patch_imm64_load_insns() take an argument that decides which register to load an immediate to - rather than hardcoding r3. Signed-off-by: Jordan Niethe <jniethe5@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200516115449.4168796-1-mpe@ellerman.id.au
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.