On Thu, 19 Feb 2026 at 17:18, Alex Bennée <[email protected]> wrote:
>
> We don't need to re-create the architectural reset behaviour now it is
> handled in the core m68k CPU reset code. We do however need to add
> support for direct kernel booting so we stash that value in
> env->direct_kernel_boot_pc and enhance m68k_cpu_reset_exit() to use it
> if set.
>
> Signed-off-by: Alex Bennée <[email protected]>
>
> ---
> v2
> - re-write to use proper 3-phase logic, so dropped all tags
> - favour cpu_reset over resettable_reset(cs)
The commit message says it's doing three-phase reset, but
the actual code is not:
> +static void virt_machine_reset(MachineState *ms, ResetType type)
> +{
> + CPUState *cs = first_cpu;
> +
> + qemu_devices_reset(type);
> + cpu_reset(cs);
This first resets the whole system (going through its
three phases) and then the CPU (which does its phases
separately). Three-phase support would imply having the
CPU do its enter phase at the same time as the other devices,
its hold phase with the others, and so on.
If you wanted that you could do it by using
qemu_register_resettable(OBJECT(cpu)) instead of having
a MachineClass::reset method, given that the only two
things you're doing in it are the default thing and a
cpu_reset() call.
> @@ -315,6 +300,7 @@ static void virt_machine_class_init(ObjectClass *oc,
> const void *data)
> MachineClass *mc = MACHINE_CLASS(oc);
> mc->desc = "QEMU M68K Virtual Machine";
> mc->init = virt_init;
> + mc->reset = virt_machine_reset;
> mc->default_cpu_type = M68K_CPU_TYPE_NAME("m68040");
> mc->max_cpus = 1;
> mc->no_floppy = 1;
I did have a plan to look at making MachineClass a subset of
Device so that it could be three-phase-reset aware rather than
having its own special-snowflake reset method.
thanks
-- PMM
