[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK9=C2X2J4ROJ7nKB0hcD9dVav7ZMFWw2Qy+GEsmYN_Tt8DxPQ@mail.gmail.com>
Date: Mon, 11 Aug 2025 15:11:27 +0530
From: Anup Patel <apatel@...tanamicro.com>
To: Jesse Taube <jesse@...osinc.com>
Cc: linux-riscv@...ts.infradead.org, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alex@...ti.fr>, Oleg Nesterov <oleg@...hat.com>, Kees Cook <kees@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Ian Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>, Shuah Khan <shuah@...nel.org>,
Himanshu Chauhan <hchauhan@...tanamicro.com>, Charlie Jenkins <charlie@...osinc.com>,
Samuel Holland <samuel.holland@...ive.com>, Conor Dooley <conor.dooley@...rochip.com>,
Deepak Gupta <debug@...osinc.com>, Andrew Jones <ajones@...tanamicro.com>,
Atish Patra <atishp@...osinc.com>, Mayuresh Chitale <mchitale@...tanamicro.com>,
Evan Green <evan@...osinc.com>, WangYuli <wangyuli@...ontech.com>,
Huacai Chen <chenhuacai@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Andrew Morton <akpm@...ux-foundation.org>, Luis Chamberlain <mcgrof@...nel.org>,
"Mike Rapoport (Microsoft)" <rppt@...nel.org>, Nam Cao <namcao@...utronix.de>,
Yunhui Cui <cuiyunhui@...edance.com>, Joel Granados <joel.granados@...nel.org>,
Clément Léger <cleger@...osinc.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>, Celeste Liu <coelacanthushex@...il.com>,
Chunyan Zhang <zhangchunyan@...as.ac.cn>, Nylon Chen <nylon.chen@...ive.com>,
Thomas Gleixner <tglx@...utronix.de>, Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
Vincenzo Frascino <vincenzo.frascino@....com>, Joey Gouly <joey.gouly@....com>,
Akihiko Odaki <akihiko.odaki@...nix.com>, Ravi Bangoria <ravi.bangoria@....com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-perf-users@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 5/8] riscv: hw_breakpoint: Use icount for single stepping
Hi Jesse,
On Wed, Aug 6, 2025 at 1:10 AM Jesse Taube <jesse@...osinc.com> wrote:
>
> The Sdtrig RISC-V ISA extension does not have a resume flag for
> returning to and executing the instruction at the breakpoint.
> To avoid skipping the instruction or looping, it is necessary to remove
> the hardware breakpoint and single step. Use the icount feature of
> Sdtrig to accomplish this. Use icount as default with an option to allow
> software-based single stepping when hardware or SBI does not have
> icount functionality, as it may cause unwanted side effects when reading
> the instruction from memory.
>
> Signed-off-by: Jesse Taube <jesse@...osinc.com>
> ---
> OpenSBI implementation of sbi_debug_read_triggers does not return the
> updated CSR values. There needs to be a check for working
> sbi_debug_read_triggers before this works.
>
> https://lists.riscv.org/g/tech-prs/message/1476
>
> RFC -> V1:
> - Add dbtr_mode to rv_init_icount_trigger
> - Add icount_triggered to check which breakpoint was triggered
> - Fix typo: s/affects/effects
> - Move HW_BREAKPOINT_COMPUTE_STEP to Platform type
> ---
> arch/riscv/Kconfig | 11 ++
> arch/riscv/kernel/hw_breakpoint.c | 179 +++++++++++++++++++++++++++---
> 2 files changed, 172 insertions(+), 18 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index fd8b62cdc6f5..37f01ed199f3 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -546,6 +546,17 @@ config RISCV_COMBO_SPINLOCKS
>
> endchoice
>
> +config HW_BREAKPOINT_COMPUTE_STEP
> + bool "Allow computing hardware breakpoint step address"
> + default n
> + depends on HAVE_HW_BREAKPOINT
> + help
> + Select this option if hardware breakpoints are desired, but
> + hardware or SBI does not have icount functionality. This may cause
> + unwanted side effects when reading the instruction from memory.
> +
> + If unsure, say N.
> +
We expect the same kernel image to work on a platform with
icount triggers and without icount triggers.
Please drop this kconfig option. The decision of falling back to
computing hardware breakpoint step address should be at
boot-time and not compile-time.
Regards,
Anup
Powered by blists - more mailing lists