On 7/8/20 11:39 PM, Eduardo Habkost wrote: > 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?
Because starting a virtualized machine with all cores powered-off with TCG accelerator should at least emit a warning? Or change the behavior and start them powered-on? This is machine-specific although.
