diff options
author | Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> | 2021-08-25 10:51:00 +0100 |
---|---|---|
committer | Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> | 2021-09-08 11:09:45 +0100 |
commit | e97a8a5926968a1028902318d2f396c4bfc5755b (patch) | |
tree | 59fc6b8f8a0a8dafd856dc64178cf4e6e5f7bda2 /.gitlab-ci.yml | |
parent | f383eb80f6823663b9b440f779083063ef55aec0 (diff) | |
download | qemu-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 '.gitlab-ci.yml')
0 files changed, 0 insertions, 0 deletions