On 8/30/25 09:05, Paolo Bonzini wrote:
On Fri, Aug 29, 2025 at 11:57 PM Richard Henderson
<richard.hender...@linaro.org> wrote:

On 8/30/25 01:31, Paolo Bonzini wrote:
@@ -624,8 +624,7 @@ static target_ulong h_confer(PowerPCCPU *cpu, 
SpaprMachineState *spapr,
       }

       cs->exception_index = EXCP_YIELD;
-    qatomic_set(&cs->exit_request, true);
-    cpu_loop_exit(cs);
+    cpu_exit(cs);

       return H_SUCCESS;
   }

cpu_loop_exit does a longjmp; cpu_exit does not.

This may be a bug fix, but it's hard to tell.
If it is a bug fix, it should be separated.

The longjmp is overkill but works. Not doing the longjmp also works
because gen_sc() finishes the TB and then you go all the way (check
interrupt_request -> check exit_request -> write exception_index ->
cpu_exec_end) out of tcg_cpu_exec().

Ok.


I like cpu_loop_exit() to signify that I am in the middle of the TB.

Agreed. I suspect we over-use longjmp and could perhaps do better at simply returning up the call-stack.


That said, I'm always conflicted between renaming badly-named
functions and keeping historical names. qemu_wait_io_event() is also
horrible.

...


+++ b/system/cpu-timers.c
@@ -246,14 +246,14 @@ void qemu_timer_notify_cb(void *opaque, QEMUClockType 
type)

      if (qemu_in_vcpu_thread()) {
          /*
-         * A CPU is currently running; kick it back out to the
+         * A CPU is currently running; kick it back out of the
           * tcg_cpu_exec() loop so it will recalculate its
           * icount deadline immediately.
           */
-        qemu_cpu_kick(current_cpu);
+        cpu_exit(current_cpu);

where the comment still says kick and we're replacing kick with exit.

I guess the root of this problem is that "kick" isn't a precise term, we ought 
to name it
something else, and we should paint the bike shed green.

Yes, I agree. "send it out of" can work too in this case, I'll chanbge it.

I was actually talking about renaming qemu_cpu_kick.
But per above, that's hard.  :-)

I guess just updating the comment is fine for now.


r~

Reply via email to