Re: [PATCH] cpu: Add starts_halted() method

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 7/8/20 5:25 PM, Eduardo Habkost wrote:
> On Wed, Jul 08, 2020 at 02:14:03PM +0100, Peter Maydell wrote:
>> On Wed, 8 Jul 2020 at 12:12, David Gibson <david@gibson.dropbear.id.au> wrote:
>>> On Wed, Jul 08, 2020 at 10:38:29AM +0200, Philippe Mathieu-Daudé wrote:
>>>> Class boolean field certainly sounds better, but I am not sure this
>>>> is a property of the machine. Rather the arch? So move the field
>>>> to CPUClass? Maybe not, let's discuss :)
>>>
>>> It is absolutely a property of the machine.  e.g. I don't think we
>>> want this for powernv.  pseries is a bit of a special case since it is
>>> explicitly a paravirt platform.  But even for emulated hardware, the
>>> board can absolutely strap things so that cpus do or don't start
>>> immediately.
>>
>> It's a property of the individual CPU, I think. One common setup
>> for Arm systems is that the primary CPU starts powered up but
>> the secondaries all start powered down.
> 
> Both statements can be true.  It can be a property of the
> individual CPU (although I'm not convinced it has to), but it
> still needs to be controlled by the machine.

From what said Peter, I understand this is a property of the
chipset. Chipsets are modelled unevenly.

IIUC QEMU started with single-core CPUs.
CPUState had same meaning for 'core' or 'cpu', 1-1 mapping.

Then multicore CPUs could be easily modelled using multiple
single-core CPUs, usually created in the machine code.

Then we moved to SoC models, creating the cores in the SoC.
Some SoCs have array of cores, eventually heterogeneous
(see the ZynqMP). We have containers of CPUState.

On an ARM-based SoC, you might have the first core started
(as said Peter) or not.

BCM2836 / BCM2837 and ZynqMP start will all ARM cores off.
On the BCM chipsets, a DSP core will boot the ARM cores.
On the ZynqMP, a MicroBlaze core boots them.
As QEMU doesn't models heterogeneous architectures, we start
modelling after the unmodelled cores booted us, so either one
or all cores on.

In this case, we narrowed down the 'start-powered-off' field
to the SoC, which happens to be how ARM SoCs are modelled.


Chipsets providing a JTAG interface can have a SRST signal,
the "system reset". When a JTAG probe is attached, it can
keeps the whole chipset in a reset state. This is equivalent
to QEMU '-S' mode (single step mode).


I don't know about pseries hardware, but if this is 'explicit
to paravirt platform', then I expect this to be the same with
other accelerators/architectures.

If paravirtualized -> cores start off by default. Let the
hypervisor start them. So still a property of the CPUState
depending on the accelerator used?


Regards,

Phil.