1 files changed, 126 insertions, 0 deletions
diff --git a/results/classifier/118/review/1881249 b/results/classifier/118/review/1881249
new file mode 100644
index 000000000..e1ec09a18
--- /dev/null
+++ b/results/classifier/118/review/1881249
@@ -0,0 +1,126 @@
+architecture: 0.890
+device: 0.798
+register: 0.763
+performance: 0.731
+arm: 0.661
+ppc: 0.658
+mistranslation: 0.652
+files: 0.606
+permissions: 0.580
+peripherals: 0.563
+kernel: 0.531
+assembly: 0.510
+graphic: 0.506
+hypervisor: 0.485
+vnc: 0.475
+boot: 0.461
+network: 0.418
+semantic: 0.418
+PID: 0.406
+risc-v: 0.404
+socket: 0.398
+debug: 0.393
+x86: 0.392
+user-level: 0.373
+virtual: 0.275
+TCG: 0.273
+VMM: 0.257
+KVM: 0.238
+i386: 0.216
+--------------------
+arm: 0.951
+architecture: 0.738
+hypervisor: 0.435
+kernel: 0.396
+KVM: 0.234
+TCG: 0.123
+virtual: 0.077
+files: 0.070
+register: 0.067
+VMM: 0.035
+debug: 0.027
+PID: 0.020
+boot: 0.019
+device: 0.015
+socket: 0.014
+semantic: 0.009
+assembly: 0.007
+network: 0.007
+performance: 0.005
+vnc: 0.005
+user-level: 0.004
+permissions: 0.003
+peripherals: 0.003
+risc-v: 0.002
+graphic: 0.001
+mistranslation: 0.001
+ppc: 0.000
+x86: 0.000
+i386: 0.000
+
+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
+
+