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. > > 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. What "halfway through reset" means, exactly? Isn't halted==1 enough to indicate the CPU is in that state? -- Eduardo
