| Message ID | 20210908115451.9821-4-mark.cave-ayland@ilande.co.uk |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,01/12] target/sparc: Drop use of gen_io_end() | expand |
diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c index 42e139849e..7f3a7c0027 100644 --- a/hw/sparc/sun4m.c +++ b/hw/sparc/sun4m.c @@ -803,11 +803,11 @@ static void cpu_devinit(const char *cpu_type, unsigned int id, cpu = SPARC_CPU(object_new(cpu_type)); env = &cpu->env; - cpu_sparc_set_id(env, id); qemu_register_reset(sun4m_cpu_reset, cpu); object_property_set_bool(OBJECT(cpu), "start-powered-off", id != 0, &error_fatal); qdev_realize_and_unref(DEVICE(cpu), NULL, &error_fatal); + cpu_sparc_set_id(env, id); *cpu_irqs = qemu_allocate_irqs(cpu_set_irq, cpu, MAX_PILS); env->prom_addr = prom_addr; }
Commit 24f675cd3b ("sparc/sun4m: Use start-powered-off CPUState property") changed the sun4m CPU reset code to use the start-powered-off property and so split the creation of the CPU into separate instantiation and realization phases to enable the new start-powered-off property to be set. This accidentally broke sun4m machines with more than one CPU present since sparc_cpu_realizefn() sets a default CPU id, and now that realization occurs after calling cpu_sparc_set_id() in cpu_devinit() the CPU id gets reset back to the default instead of being uniquely encoded based upon the CPU number. As soon as another CPU is brought online, the OS gets confused between them and promptly panics. Resolve the issue by moving the cpu_sparc_set_id() call in cpu_devinit() to after the point where the CPU device has been realized as before. Fixes: 24f675cd3b ("sparc/sun4m: Use start-powered-off CPUState property") Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210825095100.20180-1-mark.cave-ayland@ilande.co.uk> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> --- hw/sparc/sun4m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)