On Mon, 9 Mar 2020 at 13:13, Laurent Vivier <laur...@vivier.eu> wrote: > > Le 09/03/2020 à 14:09, Peter Maydell a écrit : > > On Mon, 9 Mar 2020 at 12:11, Philippe Mathieu-Daudé <phi...@redhat.com> > > wrote: > >> > >> cpu_reset() might modify architecture-specific fields allocated > >> by qemu_init_vcpu(). To avoid bugs similar to the one fixed in > >> commit 00d0f7cb66 when introducing new architectures, move the > >> cpu_reset() calls after qemu_init_vcpu(). > >> > >> Signed-off-by: Philippe Mathieu-Daudé <phi...@redhat.com> > > > > Why do we need to call cpu_reset() from realize anyway? > > Generally for devices this is incorrect as they should be > > being reset by some other mechanism. > > I have this same change in my branch for q800 to set the initial PC and > stack pointer read from memory on cold boot. > > Do we have another way to do that?
The expectation at the moment is that the board code should register a reset function with qemu_register_reset() which calls cpu_reset(). Relying on doing a reset in realize won't work for the case where there's a QEMU system reset, because we don't re-init/realize everything, we just call all the reset hooks. If m68k reads pc/sp from memory on reset you'll probably run into the same reset-ordering vs hw/cpu/loader.c that Arm M-profile has; we currently work around that in the arm reset function. I had hoped that 3-phase reset would resolve this reset order issue, but it has not turned out to be so easy. thanks -- PMM
