summary refs log tree commit diff stats
path: root/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-05-30 16:52:07 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-05-30 16:52:17 +0200
commit9260319e7411ff8281700a532caa436f40120ec4 (patch)
tree2f6bfe5f3458dd49d328d3a9eb508595450adec0 /gitlab/issues_text/target_missing/host_missing/accel_TCG/1503
parent225caa38269323af1bfc2daadff5ec8bd930747f (diff)
downloadqemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.tar.gz
qemu-analysis-9260319e7411ff8281700a532caa436f40120ec4.zip
gitlab scraper: download in toml and text format
Diffstat (limited to 'gitlab/issues_text/target_missing/host_missing/accel_TCG/1503')
-rw-r--r--gitlab/issues_text/target_missing/host_missing/accel_TCG/150350
1 files changed, 50 insertions, 0 deletions
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503 b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503
new file mode 100644
index 000000000..8ab7691d5
--- /dev/null
+++ b/gitlab/issues_text/target_missing/host_missing/accel_TCG/1503
@@ -0,0 +1,50 @@
+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