[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
[PATCH 2/2] cpu: Assert a vCPU is created before resetting it, Philippe Mathieu-Daudé, 2020/03/09