Le 09/03/2020 à 14:18, Peter Maydell a écrit : > 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.
Thank you for the hint, I'll have a look. Laurent
