[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v15 21/23] hw/core/cpu: call qemu_init_vcpu in cpu_common_rea
From: |
Peter Maydell |
Subject: |
Re: [PATCH v15 21/23] hw/core/cpu: call qemu_init_vcpu in cpu_common_realizefn |
Date: |
Thu, 4 Feb 2021 14:24:51 +0000 |
On Thu, 4 Feb 2021 at 14:18, Claudio Fontana <cfontana@suse.de> wrote:
> If we could consistently move not only qemu_vcpu_init, but also reset in the
> common code in cpu_common_realizefn,
> and force the sequence: qemu_vcpu_init(); cpu_reset(); in there,
>
> and this actually works for all targets, maybe this could actually be an
> improvement.
So my question here would be: what is special about CPUs that
we have to reset them in their realize function? For other
devices, we don't reset them in the init/realize sequence;
we rely on the whole system getting reset and that doing
reset of devices.
There almost certainly *is* a reason here (my guess would be
that it's related to the mess that is reset and in particular
that CPU objects don't get automatically reset on system reset
because they're not on a qbus). But if we're thinking about
aspirational goals, I think the aspiration should be to not
need to reset the CPU in its own realize function at all...
thanks
-- PMM
- [PATCH v15 15/23] cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClass, (continued)
[PATCH v15 21/23] hw/core/cpu: call qemu_init_vcpu in cpu_common_realizefn, Claudio Fontana, 2021/02/01
[PATCH v15 19/23] i386: split cpu accelerators from cpu.c, using AccelCPUClass, Claudio Fontana, 2021/02/01
[PATCH v15 18/23] accel: introduce AccelCPUClass extending CPUClass, Claudio Fontana, 2021/02/01
[PATCH v15 17/23] accel: replace struct CpusAccel with AccelOpsClass, Claudio Fontana, 2021/02/01