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.

-- PMM

Reply via email to