On Tue, 17 Feb 2026 at 21:42, Philippe Mathieu-Daudé <[email protected]> wrote:
>
> On 17/2/26 20:12, Yodel Eldar wrote:
> > +Philippe
> >
> > Hi,
> >
> > On 17/02/2026 03:21, Peter Maydell wrote:
> >> On Tue, 17 Feb 2026 at 06:35, Akihiko Odaki
> >> <[email protected]> wrote:
> >>>
> >>> alpha_cpu_realizefn() did not properly call cpu_reset(), which
> >>> corrupted icount. Add the missing function call to fix icount.
> >>>
> >>> Signed-off-by: Akihiko Odaki <[email protected]>
> >>> ---
> >
> > So, the real culprit was hiding in plain sight in Alpha-specific code
> > all along? Congrats on finding it!
> >
> >>> target/alpha/cpu.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/target/alpha/cpu.c b/target/alpha/cpu.c
> >>> index 1780db7d1e29..74281ebdb367 100644
> >>> --- a/target/alpha/cpu.c
> >>> +++ b/target/alpha/cpu.c
> >>> @@ -124,6 +124,7 @@ static void alpha_cpu_realizefn(DeviceState *dev,
> >>> Error **errp)
> >>> }
> >>>
> >>> qemu_init_vcpu(cs);
> >>> + cpu_reset(cs);
> >>>
> >>> acc->parent_realize(dev, errp);
> >>> }
> >>
> >> Realize functions shouldn't call reset on themselves.
> >> For CPU objects it is currently the responsibility of the
> >> board code to arrange that the CPU objects get reset.
> > I think the following addresses Peter's remarks; it passed 100
> > repetitions of the Alpha replay test after reapplying the reverted
> > commit:
> >
> > diff --git hw/alpha/dp264.c hw/alpha/dp264.c
> > index 5e64528431..091ffc0085 100644
> > --- hw/alpha/dp264.c
> > +++ hw/alpha/dp264.c
> > @@ -68,5 +68,7 @@ static void clipper_init(MachineState *machine)
> > memset(cpus, 0, sizeof(cpus));
> > for (i = 0; i < smp_cpus; ++i) {
> > - cpus[i] = ALPHA_CPU(cpu_create(machine->cpu_type));
> > + CPUState *cpu = cpu_create(machine->cpu_type);
> > + cpu_reset(cpu);
> > + cpus[i] = ALPHA_CPU(cpu);
>
> Hmm this pattern is used a lot (creating CPUs in board_init without
> manually calling cpu_reset). If this is the simplest fix, maybe
> we could add a cpu_create_resetted() helper and use it where
> appropriate (i.e. not where qemu_register_reset is then called).
Resetting the CPU either in realize or else in the machine
after create causes it to get reset once on startup. But
it doesn't do anything to cause it to be reset when the
user (or the guest) triggers a system reset. If the board
arranges for the CPUs to be reset during system reset then
that also works for the initial startup case.
Reset is unfortunately a bit of a mess: I have periodically
thought about it but still don't have an overview of what
exactly it ought to be doing, let alone a plan (e.g. should
we cascade reset via the QOM tree? or do we need a separate
reset infrastructure that defaults to the QOM tree but that
SoC objects can override if they have more complex reset
requirements? How does this interact with bus-reset (which is
definitely a thing for some buses? And once we've decided what
we want, how do we get from where we are right now to there
without breaking things and ideally without having another
of the long-drawn-out never-completed API transitions we're so
good at?)
thanks
-- PMM
