On 2 October 2018 at 17:46, Paolo Bonzini <pbonz...@redhat.com> wrote: > On 02/10/2018 12:34, Peter Maydell wrote: >> Maybe I just don't understand what you're suggesting should be >> done via run-on-cpu. But it seems to me that the problem here >> is that cpu_stop_current() should not call qemu_cpu_stop() >> immediately, but instead arrange that this vCPU calls qemu_cpu_stop() >> when it gets back out of the execution loop. > > It will already do it in qemu_wait_io_event_common. So perhaps it's > enough to do cpu_exit(cpu) in pause_all_vcpus() and cpu_stop_current(), > instead of cpu_stop_current() which incorrectly sets cpu->stopped to true?
Sounds plausible in the cpu_stop_current() case, but for pause_all_vcpus(), we need to (continue to) do something that makes the current CPU immediately set cpu->stopped to true, because the second part of the function is going to wait until all cpus (including this one) have cpu->stopped set. (That is, if the vcpu thread calls pause_all_vcpus() then we can't say "wait for this thread to get back out to the main loop": that's a deadlock. We could leave pause_all_vcpus() as it is, or if we cared we'd need to rewrite all the places that call pause_all_vcpus() from the vcpu thread to do something else instead. That's basically kvmvapic.c -- which could probably be rewritten to do something else than its current pause_all_vcpus/do stuff/resume_all_vcpus sequence -- plus vm_stop(), which has a related FIXME comment in it already.) thanks -- PMM
