On 8/10/25 01:26, Richard Henderson wrote:
On 8/9/25 04:59, Paolo Bonzini wrote:
+void tcg_kick_vcpu_thread(CPUState *cpu)
+{
+ /*
+ * Ensure cpu_exec will see the reason why the exit request was set.
+ * FIXME: this is not always needed. Other accelerators instead
+ * read interrupt_request and set exit_request on demand from the
+ * CPU thread; see kvm_arch_pre_run() for example.
+ */
+ qatomic_store_release(&cpu->exit_request, 1);
+
+ /* Ensure cpu_exec will see the exit request after TCG has
exited. */
+ qatomic_store_release(&cpu->neg.icount_decr.u16.high, -1);
+}
So, now both cpu_exit and cpu_kick set exit_request.
You ifdef this out again for user-only in patch 7, but this does suggest
that kick and exit are essentially interchangeable. You rearrange
things a bit in patch 6, but it's still not clear to me what the
difference between the two should be. There's certainly nothing at all
in include/hw/core/cpu.h to differentiate them.
Should we instead eliminate one of kick or exit, unifying the paths?
In cpu-exec.c terms, qemu_cpu_kick() *should* go out to
cpu_handle_interrupt() whereas cpu_exit() *should* go out to
cpu_handle_exception(). The difference matters for some accelerators
where qemu_cpu_kick() tries not to take the BQL in the vCPU thread.
Until now TCG's implementation of kick_vcpu_thread set both exit_request
and interrupt_request, and I'm not changing that yet for system
emulation. Patch 7 does that for user-mode emulation, because it's
trivial: neither linux-user not bsd-user use qemu_cpu_kick() directly.
Paolo
