qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [PATCH] cpu: Add starts_halted() method
Date: Wed, 8 Jul 2020 18:09:49 +0100

On Wed, 8 Jul 2020 at 17:03, Eduardo Habkost <ehabkost@redhat.com> wrote:
>
> On Wed, Jul 08, 2020 at 04:32:51PM +0100, Peter Maydell wrote:
> > On Wed, 8 Jul 2020 at 16:25, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > On Wed, Jul 08, 2020 at 02:14:03PM +0100, Peter Maydell wrote:
> > > > 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?
> >
> > I mean "while we're in the middle of the CPU method that's
> > called by cpu_reset()". "halted==1" says "the CPU is halted";
> > that's not the same thing. KVM_RUN happening
> > as a side effect in the middle of that code is a bug
> > whether the CPU happens to be intended to be put into the
> > halted state or not. If the CPU is intended to be created
> > not-halted then KVM_RUN can happen after cpu reset
> > completes, but not before.
>
> Wait, I thought we already had mechanisms to prevent that from
> happening.  Otherwise, it would never be safe for cpu_reset() to
> touch the CPU registers.

Exactly. It appears that there's a bug in our mechanisms,
which is why I'm suggesting that the right thing is
to fix that bug rather than marking the CPU as halted
earlier in the reset process so that the KVM_RUN happens
to do nothing...

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]