Greetings,
My current understanding is that this series is an official dependency of
the riscv-server-ref board, currently on v8:
[PATCH v8 0/7] hw/riscv: Server Platform Reference Board
Because we decided that we want to keep 0.13 and 1.0 instead of deprecating
debug 1.0 (see [1]).
We missed the 11.1 boat with this work and with riscv-server-ref. No big
deal TBH since the server-ref board can use improvements before upstreaming.
But I would like to not miss the 11.2 train in the end of the year.
Nick, I already reviewed a bunch of patches that seems to be fixes that we
can use right away. If you're ok with it I'll pick them all and re-send in
your behalf, rebased and with acks. My hope is that this will reduce
the amount of work needed for the rest of the 0.13/1.0 debug code and
we can get that sorted it out. Then Chao can use the new 1.0 infrastructure
for his 'sdext' patches, and then we can lend the riscv-server-ref board on
top of it all.
Let me know if that works for you. Chao, not sure if you were aware of this
series so feel free to comment.
[1]
https://lore.kernel.org/qemu-devel/[email protected]/
Thanks,
Daniel
On 1/14/2026 1:46 AM, Nicholas Piggin wrote:
Hi,
Sorry for the big series. The Ascalon CPU implements Sdtrig with 2
different types of mcontrol6 trigger and the icount trigger, so in
the course of testing and bringing up OpenSBI and Linux support for
this, I've accumulated quite a lot.
My new year resolution is to start being better upstream contributor,
it's taken me a while with changing jobs and architectures. So I don't
expect others to drop everything to review this! Joel has been
prodding me, and noted there is some other Sdtrig work going on
with the v1.0 support patches.
I think the debug v1.0 patches are somewhat orthogonal to this series,
but both are addressing aspects of a common problem of Sdtrig
implementation specifics. I wonder if these should be reconciled or
left separate. Sdtrig v1.00/v0.13 configuration is a single boolean
which is feasible as a CPU property. Whereas the entire space of
Sdtrig implementation seems like too much to make configurable in that
way.
Any thoughts would be welcome.
Thanks,
Nick
Nicholas Piggin (25):
target/riscv/debug: Check only mcontrol triggers for break/watchpoint
matching
target/riscv/debug: Handle changing trigger types
target/riscv/debug: Implement permissive type unavailable trigger
target/riscv/debug: Fix icount trigger privilege check
target/riscv/debug: Update itrigger_enabled after changing privilege
target/riscv/debug: Implement get_trigger_action for icount type
trigger
target/riscv/debug: Fix migration post_load icount_enabled() test
target/riscv/debug: Fix icount privilege matching icount_enabled()
test
target/riscv/debug: Implement icount trigger textra matching
target/riscv/debug: Maintain itrigger_enabled in
helper_itrigger_match()
target/riscv/debug: Fix breakpoint matching action
target/riscv/debug: Put mcontrol load/store match address into tval
target/riscv/debug: Remove breakpoints on reset
target/riscv/debug: Move debug CPU post_load details into debug.c
target/riscv/debug: Insert breakpoints after migration
target/riscv/debug: Remove itrigger icount-enabled mode
target/riscv/debug: Advertise icount trigger type in tinfo
target/riscv/debug: Reset trigger type to unavailable
target/riscv/debug: Add new debug state format
target/riscv/debug: Migrate mcontext using new sdtrig vmstate
target/riscv/debug: Implementation specific Sdtrig configuration
target/riscv/debug: Support heterogeneous trigger types
target/riscv/debug: Support heterogeneous mcontrol access types
target/riscv/debug: Emulate TT Ascalon Sdtrig
target/riscv/debug: Fix minor comment typos
target/riscv/cpu.c | 65 ++++-
target/riscv/cpu.h | 41 ++-
target/riscv/cpu_helper.c | 10 +-
target/riscv/csr.c | 7 +-
target/riscv/debug.c | 571 ++++++++++++++++++++-----------------
target/riscv/debug.h | 19 +-
target/riscv/machine.c | 96 ++++++-
target/riscv/tcg/tcg-cpu.c | 5 +-
8 files changed, 510 insertions(+), 304 deletions(-)
