2 files changed, 101 insertions, 0 deletions
diff --git a/results/classifier/108/other/1503 b/results/classifier/108/other/1503
new file mode 100644
index 000000000..50063d34d
--- /dev/null
+++ b/results/classifier/108/other/1503
@@ -0,0 +1,65 @@
+device: 0.792
+other: 0.656
+semantic: 0.535
+graphic: 0.496
+vnc: 0.492
+socket: 0.472
+files: 0.459
+PID: 0.360
+debug: 0.300
+boot: 0.282
+permissions: 0.254
+performance: 0.233
+network: 0.151
+KVM: 0.100
+
+Writing to readonly memory should call cpu_transaction_failed
+Description of problem:
+Currently if a guest writes to ROM memory on a system that doesn't have some other form of memory protection enabled, QEMU will silently ignore the write (https://gitlab.com/qemu-project/qemu/-/blob/master/accel/tcg/cputlb.c#L2432). Instead, it should call cpu_transaction_failed (similar to what happens when a MMIO operation fails in `io_writex` and other places). For CPUs that don't care, it'll continue to be ignored, but for other CPUs the user will get a warning (with `-d guest_errors`) or an exception as appropriate.
+Steps to reproduce:
+N/A
+Additional information:
+The documentation for do_transaction_failed says:
+
+```
+@do_transaction_failed: Callback for handling failed memory transactions
+(ie bus faults or external aborts; not MMU faults)
+```
+
+which seems reasonably well suited for this case. Here's an overview of what different CPUs currently do if do_transaction_failed is called:
+
+alpha_cpu_do_transaction_failed:
+
+* raises a EXCP_MCHK
+
+arm_cpu_do_transaction_failed:
+
+* raises ARMFault_SyncExternal with EXCP_DATA_ABORT
+
+loongarch_cpu_do_transaction_failed:
+
+* raises EXCCODE_ADEM
+
+m68k_cpu_transaction_failed:
+
+* raises EXCP_ACCESS (M68040 only)
+
+mb_cpu_transaction_failed:
+
+* raises EXCP_HW_EXCP with ESR_EC_DATA_BUS
+
+mips_cpu_do_transaction_failed:
+
+* raises EXCP_DBE (data bus error)
+
+riscv_cpu_do_transaction_failed:
+
+* raises RISCV_EXCP_STORE_AMO_ACCESS_FAULT
+
+sparc_cpu_do_transaction_failed:
+
+* raises an MMU fault
+
+xtensa_cpu_do_transaction_failed
+
+* raises LOAD_STORE_PIF_ADDR_ERROR_CAUSE
diff --git a/results/classifier/108/other/1503031 b/results/classifier/108/other/1503031
new file mode 100644
index 000000000..a008e19d0
--- /dev/null
+++ b/results/classifier/108/other/1503031
@@ -0,0 +1,36 @@
+permissions: 0.744
+semantic: 0.698
+device: 0.682
+socket: 0.665
+graphic: 0.655
+other: 0.651
+performance: 0.626
+network: 0.599
+files: 0.588
+vnc: 0.525
+PID: 0.502
+debug: 0.467
+boot: 0.431
+KVM: 0.303
+
+32-to-64-bit call gate unsupported in IA32e mode
+
+In particular, the lcall implementation doesn't support the 64-bit TSS.
+
+helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS.  In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS.  Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted).
+
+This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss().
+
+I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have).
+
+Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago.
+
+I also suspect that qemu will incorrectly allow calls through 32-bit call gates in compatibility mode (rather than raising a GP fault --- see Intel manuals volume 3A 5-21).  And I doubt 64-to-64-bit call gates work either.  I haven't actually tested either of those scenarios, though, this is just from reading the code.
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+Looking at the commit log it looks like Andrew fixed this in commit 0aca060526d3ff9632aaed in 2018 ?
+
+
+That looks like the corresponding fix, indeed. Let's close this ticket.
+