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. The original bug as described in the commit message sounds to me like something we should look to fix in the implementation of async_run_on_cpu() -- it shouldn't cause a CPU that's halfway through reset to do a KVM_RUN or otherwise run guest code, whether that CPU is going to start powered-up or powered-down. thanks -- PMM
