Re: [PATCH] cpu: Add starts_halted() method

[Eduardo Habkost <ehabkost@redhat.com>]

On Wed, Jul 08, 2020 at 02:14:03PM +0100, Peter Maydell wrote:
> On Wed, 8 Jul 2020 at 12:12, David Gibson <david@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