On Wed, Jul 08, 2020 at 06:45:57PM +0200, Philippe Mathieu-Daudé wrote: > 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 <da...@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.
I was not aware of the start-powered-off property. If we make it generic, we can just let spapr use it. > > > 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? I don't understand this part. Why would this depend on the accelerator? -- Eduardo
