On Wed, 8 Jul 2020 at 18:36, Eduardo Habkost <ehabk...@redhat.com> wrote: > > On Wed, Jul 08, 2020 at 06:09:49PM +0100, Peter Maydell wrote: > > 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... > > I agree this is necessary, but it doesn't seem sufficient. > > Having cpu_reset() set halted=0 on spapr (and probably other > machines) is also a bug, as it could still trigger unwanted > KVM_RUN when cpu_reset() returns (and before machine code sets > halted=1).
The Arm handling of starting-halted sets halted=1 within cpu_reset, based on whether the CPU object was created with a "start-powered-off" property. I'm not sure in practice that anything can get in asynchronously and cause a KVM_RUN in between spapr_reset_vcpu() calling cpu_reset() and it setting cs->halted (and the other stuff), though. This function ought to be called with the iothread lock held, so KVM_RUN will only happen if it calls some other function which incorrectly lets the CPU run. thanks -- PMM
