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. Alex. 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 include/hw/core/cpu.h | 3 +++ target/m68k/cpu.h | 1 + hw/m68k/an5206.c | 24 +++++++++++++++++------- hw/m68k/mcf5208.c | 25 +++++++++++++++++++------ hw/m68k/next-cube.c | 23 +++++++++++++++++------ hw/m68k/virt.c | 24 +++++++----------------- hw/mips/cps.c | 22 +++++++++++++--------- hw/misc/mips_cmgcr.c | 1 - target/arm/cpu.c | 1 - target/m68k/cpu.c | 1 - target/mips/cpu.c | 1 - target/sh4/cpu.c | 1 - target/tricore/cpu.c | 9 ++++++++- 13 files changed, 85 insertions(+), 51 deletions(-) -- 2.47.3
