On 8/1/26 15:34, Alex Bennée wrote:
We tend to apply cpu_reset inconsistently throughout our various
models which leads to unintended ordering dependencies. This got in
the way in my last plugins series:
https://patchew.org/QEMU/[email protected]/
where I needed to shuffle things around to ensure that gdb register
creation was done after dependant peripherals had created their cpu
interfaces.
Regardless of that we do have a proper reset interface now and most
architectures have moved to it. This series attempts to clean-up the
remaining cases with proper qemu_register_reset() calls so reset is
called when we intend to.
Last time I was blocked at this comment:
https://lore.kernel.org/qemu-devel/[email protected]/
Alex Bennée (12):
target/sh4: drop cpu_reset from realizefn
target/m68k: introduce env->reset_pc
hw/m68k: register a nextcube_cpu_reset handler
hw/m68k: register a mcf5208evb_cpu_reset handler
hw/m68k: register a an5206_cpu_reset handler
hw/m68k: just use reset_pc for virt platform
target/m68k: drop cpu_reset on realizefn
hw/mips: defer finalising gcr_base until reset time
hw/mips: drop cpu_reset in mips_cpu_realizefn
target/tricore: move cpu_reset from tricore_cpu_realizefn
target/arm: remove extraneous cpu_reset from realizefn
include/hw: expand cpu_reset function docs
