Hi, Philippe
On 17/02/2026 11:01, Philippe Mathieu-Daudé 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
