On Thu, 9 Jul 2020 07:11:09 +0200 Philippe Mathieu-Daudé <phi...@redhat.com> wrote:
> 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. > FYI, PAPR requires all vCPUs to be "stopped" by default. It is up to the guest to start them explicitly through an RTAS call. The hypervisor is only responsible to start a single vCPU (see spapr_cpu_set_entry_state() called from spapr_machine_reset()) to be able to boot the guest. So I'm not sure to see how that would depend on the accelerator... >