[Top][All Lists]

[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: Laurent Vivier
Subject: Re: [PATCH 1/2] cpu: Do not reset a vCPU before it is created
Date: Mon, 9 Mar 2020 14:28:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Le 09/03/2020 à 14:18, Peter Maydell a écrit :
> 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.

Thank you for the hint, I'll have a look.


reply via email to

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