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().

  * transition_halt_to_exec(): Perform target-specific state updates
    when transitioning from halt to execution.

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

Only 2 targets need to be migrated (x86 and ARM) then we can remove
the redundant cpu_exec_halt() hook.

The changes are expected to be purely refactoring with no functional
impact.

Series structure:

  Patches 1-2: Preparatory refactoring and guard additions
  Patch 3: Introduce the new hooks and orchestration logic
  Patch 4: Refactor cpu_exec() flow to use new infrastructure
  Patches 5-7: x86 extraction and conversion
  Patches 8-9: ARM extraction and conversion
  Patch 10: Remove the now-redundant cpu_exec_halt hook

Testing: CI test suite

[*] https://lore.kernel.org/qemu-devel/CABgObfaDAhrpnVqQaKgG6uxPQe1YDu77YOsUEx9nqrN=3M2cGw@mail.gmail.com/

Philippe Mathieu-Daudé (11):
  accel/tcg: Rename for exception codes named @ret as @excp
  accel/tcg: Restrict EXCP_HALTED handling to system emulation
  accel/tcg: Check %halted field in cpu_handle_halt() caller
  accel/tcg: Refactor halt-to-execution flow in cpu_exec()
  accel/tcg: Introduce .process_async_events and
    .transition_halt_to_exec
  target/arm: Extract halt-to-exec transition out of arm_cpu_exec_halt()
  target/arm: Convert cpu_exec_halt() to transition_halt_to_exec()
  target/i386: Extract async event processing out of x86_cpu_exec_halt()
  target/i386: Extract halt-to-exec transition out of
    x86_cpu_exec_halt()
  target/i386: Convert cpu_exec_halt() to transition_halt_to_exec()
  accel/tcg: Remove the now redundant cpu_exec_halt() hook

 include/accel/tcg/cpu-ops.h         | 30 +++++++-------
 target/arm/internals.h              |  3 --
 target/i386/tcg/helper-tcg.h        |  3 +-
 accel/tcg/cpu-exec.c                | 63 ++++++++++++++++-------------
 accel/tcg/tcg-accel-ops-mttcg.c     |  7 ++--
 accel/tcg/tcg-accel-ops-rr.c        |  8 ++--
 accel/tcg/tcg-accel-ops.c           |  7 ++--
 target/alpha/cpu.c                  |  1 -
 target/arm/cpu.c                    | 22 +++++-----
 target/arm/tcg/cpu-v7m.c            |  1 -
 target/avr/cpu.c                    |  1 -
 target/hexagon/cpu.c                |  1 -
 target/hppa/cpu.c                   |  1 -
 target/i386/tcg/system/seg_helper.c | 14 ++++---
 target/i386/tcg/tcg-cpu.c           |  3 +-
 target/loongarch/tcg/tcg_cpu.c      |  1 -
 target/m68k/cpu.c                   |  1 -
 target/microblaze/cpu.c             |  1 -
 target/mips/cpu.c                   |  1 -
 target/or1k/cpu.c                   |  1 -
 target/ppc/cpu_init.c               |  1 -
 target/riscv/tcg/tcg-cpu.c          |  1 -
 target/rx/cpu.c                     |  1 -
 target/s390x/cpu.c                  |  1 -
 target/sh4/cpu.c                    |  1 -
 target/sparc/cpu.c                  |  1 -
 target/tricore/cpu.c                |  1 -
 target/xtensa/cpu.c                 |  1 -
 28 files changed, 84 insertions(+), 94 deletions(-)

-- 
2.53.0

On 19/8/26 16:56, Philippe Mathieu-Daudé wrote:

> Philippe Mathieu-Daudé (11):
>    accel/tcg: Rename for exception codes named @ret as @excp
>    accel/tcg: Restrict EXCP_HALTED handling to system emulation
>    accel/tcg: Check %halted field in cpu_handle_halt() caller
Queueing uncontroversial first 3 patches (reviewed).

On 9/3/26 11:56, Philippe Mathieu-Daudé wrote:
> On 19/8/26 16:56, Philippe Mathieu-Daudé wrote:
> 
>> Philippe Mathieu-Daudé (11):
>>    accel/tcg: Rename for exception codes named @ret as @excp
>>    accel/tcg: Restrict EXCP_HALTED handling to system emulation
>>    accel/tcg: Check %halted field in cpu_handle_halt() caller
> Queueing uncontroversial first 3 patches (reviewed).
No objections other than bikeshedding names:

- process_async_events -> poll_during_halt

- transition_halt_to_exec -> leaving_halt

?

Thanks,

Paolo

On 4/9/26 11:53, Paolo Bonzini wrote:
> On 9/3/26 11:56, Philippe Mathieu-Daudé wrote:
>> On 19/8/26 16:56, Philippe Mathieu-Daudé wrote:
>>
>>> Philippe Mathieu-Daudé (11):
>>>    accel/tcg: Rename for exception codes named @ret as @excp
>>>    accel/tcg: Restrict EXCP_HALTED handling to system emulation
>>>    accel/tcg: Check %halted field in cpu_handle_halt() caller
>> Queueing uncontroversial first 3 patches (reviewed).
> No objections other than bikeshedding names:
> 
> - process_async_events -> poll_during_halt
> 
> - transition_halt_to_exec -> leaving_halt

Thanks, if Mark is satisfied with these, I'll respin.

However the main issue is the one raised by Peter here:
https://lore.kernel.org/qemu-devel/7766d96b-4065-4917-9d7d-094bd6d1f29c@oss.qualcomm.com/
Could you have a look?

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.

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

> This separation allows the generic cpu_exec() code to orchestrate
> the flow cleanly (process events, check for work, transition state).
> 
> Only 2 targets need to be migrated (x86 and ARM) then we can remove
> the redundant cpu_exec_halt() hook.
> 
> The changes are expected to be purely refactoring with no functional
> impact.
> 
> Series structure:
> 
>    Patches 1-2: Preparatory refactoring and guard additions
>    Patch 3: Introduce the new hooks and orchestration logic
>    Patch 4: Refactor cpu_exec() flow to use new infrastructure
>    Patches 5-7: x86 extraction and conversion
>    Patches 8-9: ARM extraction and conversion
>    Patch 10: Remove the now-redundant cpu_exec_halt hook
> 
> Testing: CI test suite
> 
> [*] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_qemu-2Ddevel_CABgObfaDAhrpnVqQaKgG6uxPQe1YDu77YOsUEx9nqrN-3D3M2cGw-40mail.gmail.com_&d=DwIDaQ&c=s883GpUCOChKOHiocYtGcg&r=c23RpsaH4D2MKyD3EPJTDa0BAxz6tV8aUJqVSoytEiY&m=sBca7couYmrH5p0nURqPPrh51jIPm0xJ4Tk5aHPSTzVFUbwS1-pc6webrznl259Y&s=eDmByvd3KnM-OoPHj78lDNqJAdxt6w0rKnaJOuyWJbM&e=
> 
> Philippe Mathieu-Daudé (11):
>    accel/tcg: Rename for exception codes named @ret as @excp
>    accel/tcg: Restrict EXCP_HALTED handling to system emulation
>    accel/tcg: Check %halted field in cpu_handle_halt() caller
>    accel/tcg: Refactor halt-to-execution flow in cpu_exec()
>    accel/tcg: Introduce .process_async_events and
>      .transition_halt_to_exec
>    target/arm: Extract halt-to-exec transition out of arm_cpu_exec_halt()
>    target/arm: Convert cpu_exec_halt() to transition_halt_to_exec()
>    target/i386: Extract async event processing out of x86_cpu_exec_halt()
>    target/i386: Extract halt-to-exec transition out of
>      x86_cpu_exec_halt()
>    target/i386: Convert cpu_exec_halt() to transition_halt_to_exec()
>    accel/tcg: Remove the now redundant cpu_exec_halt() hook
> 
>   include/accel/tcg/cpu-ops.h         | 30 +++++++-------
>   target/arm/internals.h              |  3 --
>   target/i386/tcg/helper-tcg.h        |  3 +-
>   accel/tcg/cpu-exec.c                | 63 ++++++++++++++++-------------
>   accel/tcg/tcg-accel-ops-mttcg.c     |  7 ++--
>   accel/tcg/tcg-accel-ops-rr.c        |  8 ++--
>   accel/tcg/tcg-accel-ops.c           |  7 ++--
>   target/alpha/cpu.c                  |  1 -
>   target/arm/cpu.c                    | 22 +++++-----
>   target/arm/tcg/cpu-v7m.c            |  1 -
>   target/avr/cpu.c                    |  1 -
>   target/hexagon/cpu.c                |  1 -
>   target/hppa/cpu.c                   |  1 -
>   target/i386/tcg/system/seg_helper.c | 14 ++++---
>   target/i386/tcg/tcg-cpu.c           |  3 +-
>   target/loongarch/tcg/tcg_cpu.c      |  1 -
>   target/m68k/cpu.c                   |  1 -
>   target/microblaze/cpu.c             |  1 -
>   target/mips/cpu.c                   |  1 -
>   target/or1k/cpu.c                   |  1 -
>   target/ppc/cpu_init.c               |  1 -
>   target/riscv/tcg/tcg-cpu.c          |  1 -
>   target/rx/cpu.c                     |  1 -
>   target/s390x/cpu.c                  |  1 -
>   target/sh4/cpu.c                    |  1 -
>   target/sparc/cpu.c                  |  1 -
>   target/tricore/cpu.c                |  1 -
>   target/xtensa/cpu.c                 |  1 -
>   28 files changed, 84 insertions(+), 94 deletions(-)


ATB,

Mark.

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).

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).
> 

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.