qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] racing between pause_all_vcpus() and qemu_cpu_stop()


From: Peter Maydell
Subject: Re: [Qemu-devel] racing between pause_all_vcpus() and qemu_cpu_stop()
Date: Tue, 2 Oct 2018 17:57:58 +0100

On 2 October 2018 at 17:46, Paolo Bonzini <address@hidden> 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



reply via email to

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