Hi, Philippe
On Tue, Feb 17, 2026 at 11:01 AM Philippe Mathieu-Daudé
<[email protected]> wrote:
>
> Hi Akihiko,
>
> On 17/2/26 07:34, Akihiko Odaki wrote:
> > alpha_cpu_realizefn() did not properly call cpu_reset(), which
...skipping...
> >
>
> We ought to rework the CPU reset paths, it is too confuse.
> Peter / Alex / myself have been there. I started some work in the
> area, fixing few inconsistencies, but it isn't a priority so never
> got over it.
>
> We really shouldn't manually call cpu_reset() in DeviceRealize
> handlers, thus not add more calls, rather remove. I appreciate this
> is a temporary kludge until we sort the cpu reset logic.
>
> At a glance, since this is an icount issue, instead of adding
> cpu_reset() all over, I wonder about this surgical kludge instead
> (untested):
>
> -- >8 --
> diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
> index ad94f96b252..0577c25e3e8 100644
> --- a/accel/tcg/cpu-exec.c
> +++ b/accel/tcg/cpu-exec.c
> @@ -1071,2 +1071,3 @@ bool tcg_exec_realizefn(CPUState *cpu, Error **errp)
> tcg_iommu_init_notifier_list(cpu);
> + cpu->cc->tcg_ops->cpu_exec_reset(cpu);
> #endif /* !CONFIG_USER_ONLY */
> ---
>
I'm getting a regression in mips64el malta with the above; not sure why:
meson test --setup qemu:thorough -t 1 \
--num-processes 1 func-mips64el-malta
ERRORs out.
I like the idea of reworking the CPU reset paths; please Cc me on
related work you submit so that I may test it out (though, I'll keep an
eye out for it anyway even if you forget :))
Thanks,
Yodel
P.S. I actually sent this email out from my other address over an hour ago,
but just now realized that my SMTP relay had blocked it due to too many
recipients (I guess that number's 10 then), hence the switch to this account.
