device: 0.798
performance: 0.731
other: 0.640
files: 0.606
permissions: 0.580
graphic: 0.506
vnc: 0.475
boot: 0.461
network: 0.418
semantic: 0.418
PID: 0.406
socket: 0.398
debug: 0.393
KVM: 0.238

CPU fetch from unpopulated ROM on reset

Some architectures fetch the $PC/$SP register as vectors in memory, usually ROM.
The CPU reset() handler is called before the ROM code is populated, resulting in fetching incorrect PC/SP.

Architectures affected:
- M68K
- RX
- ARM M-profile

Different comments from Peter Maydell regarding this issue:

- https://<email address hidden>/msg683768.html

"We should be able to do this with the new 3-phase
reset API : the rom loader reset should happen in phase 2,
and the Arm CPU should only load the new PC and SP in
phase 3."

- https://<email address hidden>/msg686480.html

"The expectation at the moment is that the board code should
register a reset function with qemu_register_reset() which
calls cpu_reset(). Relying on doing a reset in realize won't
work for the case where there's a QEMU system reset, because
we don't re-init/realize everything, we just call all the
reset hooks.

If m68k reads pc/sp from memory on reset you'll probably run
into the same reset-ordering vs hw/cpu/loader.c that Arm M-profile
has; we currently work around that in the arm reset function."

- https://<email address hidden>/msg683856.html

Related (invalidated thus rejected) series:

- https://<email address hidden>/msg683763.html

"Support device reset handler priority configuration"

This series adds support for configuring device reset handler priority, and 
uses it to ensure that the ARMv7-M CPU reset handler is invoked after the ROM 
reset handler.

- https://<email address hidden>/msg686413.html

"Avoid latent bug calling cpu_reset() on uninitialized vCPU"

cpu_reset() might modify architecture-specific fields allocated
by qemu_init_vcpu(). To avoid bugs similar to the one fixed in
commit 00d0f7cb66 when introducing new architectures, move the
cpu_reset() calls after qemu_init_vcpu().

I had an initial look at fixing this for arm via 3-phase reset, but ran into the problem that currently CPU reset is triggered via a qemu_register_reset() hook, and qemu_register_reset() itself does not have a 3-phase reset API, so the reset hook for resetting the CPUs will end up doing all 3 phases of reset for the CPU before the reset hook for reset-from-sysbus-root does all 3 phases for other devices. (I forget whether rom-data-copy happens via sysbus reset or is its own qemu_register_reset hook, but either way the same issue applies.)

One approach to this would be to add 3-phase support to qemu_register_reset(), I guess.



This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/236