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

[Peter Maydell <peter.maydell@linaro.org>]

On 2 October 2018 at 11:00, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On 1 October 2018 at 19:12, Alex Bennée <alex.bennee@linaro.org> wrote:
>>> I would have thought the reset code should be scheduled via safe async
>>> work to run in the vCPU context. Why should the main loop get involved
>>> at all here?
>>
>> The reset code is much older than the safe-async support for
>> running things in the vCPU context... Also, does the safe
>> async support work with KVM/HAX/Hypervisor.Framework? The
>> reset code has to handle all those, not just TCG.
>
> the *_run_on_cpu functions should be safe for all users although KVM
> stuff seems to use the direct run_on_cpu stuff more. The events are
> consumed in the wait_io logic that all accelerators share - in the outer
> loop in cpus-common.c
>
>> Plus, which vCPU thread would you use?
>
> Each vCPU should reset it's own data. For one thing it avoids issue
> with barriers across threads.

That seems a very long way from where we are at the moment,
where the semantics are that a CPU is just another kind of
device, and we should ensure that nothing in the system is
executing before we try to reset any of it. (Otherwise
you get into all kinds of nasty conditions where a vCPU
is still running and executes writes to devices that have
already reset, or causes calls into a different vCPU
that again is in the process of resetting).

>> We're resetting
>> the entire system, so privileging an arbitrary vCPU
>> thread to do that doesn't seem any less odd than using
>> the main loop thread.
>
> Sure - but they do give predictable semantics. If in this case the cpu
> sourcing the request scheduled async tasks to stop the cpu to everything
> else and a safe task to it's own thread it can be assured everyone has
> done their "work" (stopping in this case) and is in a known state.
>
> Does qemu_system_reset_request() make any particular promises of what
> order things should happen in?

AIUI the promise is that when the reset occurs the entire
system should end up in the state as if QEMU had just
been started. There is no guarantee about ordering between
different reset methods/functions (which is a bit of a
can of worms of its own), but any device can assume that
nobody else is going to call into it during the reset
process (either before its reset function runs, or after).

Basically it should be like:
 * whole VM pauses
 * we do all the reset work
 * start the VM

thanks
-- PMM