On 24/08/2026 22:31, Philippe Mathieu-Daudé wrote:
Hey Mark,
Hi Phil,
On 20/8/26 11:56, Philippe Mathieu-Daudé wrote:
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"?
That helps a bit, but if I were looking to implement this function for a
CPU then I'd need help with the detail.
For example, can we assume that a CPU kick or timer is just the
mechanism by which event processing can be forced? In that case is the
purpose of process_async_events() to respond to the current state of
cpu_interrupt, respond accordingly, clear the interrupt, and then ensure
that cpu_has_work() will return an appropriate value afterwards?
* 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?
WDYT?
Can we ever call resume from a non-halted state? If so,
resume_from_halt() seems clearest to me, otherwise I guess it's just a
plain resume.
This separation allows the generic cpu_exec() code to orchestrate
the flow cleanly (process events, check for work, transition state).
ATB,
Mark.
