aboutsummaryrefslogtreecommitdiff
path: root/job-qmp.c
diff options
context:
space:
mode:
authorMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>2021-08-25 10:51:00 +0100
committerMark Cave-Ayland <mark.cave-ayland@ilande.co.uk>2021-09-08 11:09:45 +0100
commite97a8a5926968a1028902318d2f396c4bfc5755b (patch)
tree59fc6b8f8a0a8dafd856dc64178cf4e6e5f7bda2 /job-qmp.c
parentf383eb80f6823663b9b440f779083063ef55aec0 (diff)
downloadqemu-e97a8a5926968a1028902318d2f396c4bfc5755b.zip
qemu-e97a8a5926968a1028902318d2f396c4bfc5755b.tar.gz
qemu-e97a8a5926968a1028902318d2f396c4bfc5755b.tar.bz2
sun4m: fix setting CPU id when more than one CPU is present
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>
Diffstat (limited to 'job-qmp.c')
0 files changed, 0 insertions, 0 deletions