qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] cpu: Do not reset a vCPU before it is created


From: Peter Maydell
Subject: Re: [PATCH 1/2] cpu: Do not reset a vCPU before it is created
Date: Mon, 9 Mar 2020 13:18:18 +0000

On Mon, 9 Mar 2020 at 13:13, Laurent Vivier <address@hidden> wrote:
>
> Le 09/03/2020 à 14:09, Peter Maydell a écrit :
> > On Mon, 9 Mar 2020 at 12:11, Philippe Mathieu-Daudé <address@hidden> 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é <address@hidden>
> >
> > 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]