On 8/8/25 20:59, Paolo Bonzini wrote:
There is no reason for some accelerators to use qemu_wait_io_event_common (which is specifically separated for round robin). They can also check on the first pass through the loop as well directly, without setting cpu->exit_request for no particular reason.There is also no need to use qatomic_set_mb() because the ordering of the communication between I/O and vCPU threads is always the same. In the I/O thread: (a) store other memory locations that will be checked if cpu->exit_request or cpu->interrupt_request is 1 (for example cpu->stop or cpu->work_list for cpu->exit_request) (b) cpu_exit(): store-release cpu->exit_request, or (b) cpu_interrupt(): store-release cpu->interrupt_requestat this point, cpu->halt_cond is broadcast and the BQL released(c) do the accelerator-specific kick (e.g. write icount_decr for TCG, pthread_kill for KVM, etc.) In the vCPU thread instead the opposite order is respected: (c) the accelerator's execution loop exits thanks to the kick (b) then the inner execution loop checks cpu->interrupt_request and cpu->exit_request. If needed cpu->interrupt_request is converted into cpu->exit_request when work is needed outside the execution loop. (a) then the other memory locations are checked. Some may need to be read under the BQL, and the vCPU thread may also take for the vCPU thread can sleep on cpu->halt_cond; but in principle this step is correct even without the BQL. Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> --- accel/dummy-cpus.c | 2 +- accel/hvf/hvf-accel-ops.c | 2 +- accel/kvm/kvm-accel-ops.c | 3 ++- accel/kvm/kvm-all.c | 2 -- accel/tcg/cpu-exec.c | 1 - accel/tcg/tcg-accel-ops-mttcg.c | 7 ++---- accel/tcg/tcg-accel-ops-rr.c | 38 ++++++++++++++++--------------- accel/tcg/tcg-accel-ops.c | 2 -- system/cpus.c | 1 + target/i386/nvmm/nvmm-accel-ops.c | 6 ++--- target/i386/nvmm/nvmm-all.c | 2 -- target/i386/whpx/whpx-accel-ops.c | 6 ++--- target/i386/whpx/whpx-all.c | 2 -- 13 files changed, 31 insertions(+), 43 deletions(-)
Great! Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
