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

["Alex Bennée" <alex.bennee@linaro.org>]

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.

> 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?

--
Alex Bennée