Peter Maydell <peter.mayd...@linaro.org> writes:
> On 1 October 2018 at 19:12, Alex Bennée <alex.ben...@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