1 files changed, 81 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/other/1881249 b/results/classifier/zero-shot/108/other/1881249
new file mode 100644
index 000000000..a93b1f69b
--- /dev/null
+++ b/results/classifier/zero-shot/108/other/1881249
@@ -0,0 +1,81 @@
+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
+
+