Hi Mark,
On 2026-08-20 11:26, Mark Cave-Ayland wrote:
On 19/08/2026 15:56, Philippe Mathieu-Daudé wrote:
Hi Phil,
No objections to the idea of the patch, however I do have a couple of
questions:
This series was inspired by a previous thread on the list [*].
Refactor the CPU halt-to-execution transition logic in TCG as
something more explicit and composable.
Core problem: TCGCPUOps::cpu_exec_halt callback mixed concerns,
it checked for work, processed async events, and handled state
transitions all in one place.
Solution: introduces two dedicated callbacks:
* process_async_events(): Process target-specific async events
before checking for work. Called early in cpu_exec().
Can you explain exactly what you mean by async events here in the
context of TCG? Looking at the thread indicated below suggests this is
terminology borrowed from KVM with which I am less familiar.
"asynchronous interrupts/events that arrive (from timers, other threads)
while a vCPU is halted"?
* transition_halt_to_exec(): Perform target-specific state updates
when transitioning from halt to execution.
That's quite a name :) Would something like cpu_exec_resume() be more
descriptive here (as well as keeping the cpu_exec_ prefix used by other
callbacks)?
Naming is hard, I rather something self-explaining when reading the
code; we transition the state but do not resume yet. Anyway what about
.resume_halted/resume_from_halt/resume_from_sleep/resume_execution
instead of .transition_halt_to_exec?
This separation allows the generic cpu_exec() code to orchestrate
the flow cleanly (process events, check for work, transition state).
