Re: [PATCH 00/11] accel/tcg: Make halt-to-exec transition explicit and remove cpu_exec_halt

["Philippe Mathieu-Daudé" <philmd@oss.qualcomm.com>]

Hey Mark,

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"?
> 
>>
>>>    * 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?

> 
>>
>>> This separation allows the generic cpu_exec() code to orchestrate
>>> the flow cleanly (process events, check for work, transition state).
>