summary refs log tree commit diff stats
path: root/gitlab/issues_text/target_missing/host_missing/accel_missing/1520
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-01 21:35:14 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-06-01 21:35:14 +0200
commit3e4c5a6261770bced301b5e74233e7866166ea5b (patch)
tree9379fddaba693ef8a045da06efee8529baa5f6f4 /gitlab/issues_text/target_missing/host_missing/accel_missing/1520
parente5634e2806195bee44407853c4bf8776f7abfa4f (diff)
downloadqemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.tar.gz
qemu-analysis-3e4c5a6261770bced301b5e74233e7866166ea5b.zip
clean up repository
Diffstat (limited to 'gitlab/issues_text/target_missing/host_missing/accel_missing/1520')
-rw-r--r--gitlab/issues_text/target_missing/host_missing/accel_missing/152049
1 files changed, 0 insertions, 49 deletions
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1520 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1520
deleted file mode 100644
index 78abbaa68..000000000
--- a/gitlab/issues_text/target_missing/host_missing/accel_missing/1520
+++ /dev/null
@@ -1,49 +0,0 @@
-x86 TCG acceleration running on s390x with -smp > host cpus slowed down by x10
-Description of problem:
-This boots up a trivial guest using OVMF, when the conditions below are given it runs ~10x slower.
-
-I have found this breaking our tests of qemu 7.2 [(which due to Debian adding the offending change as backport is affected)](https://salsa.debian.org/qemu-team/qemu/-/blob/master/debian/patches/master/acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch) by runnig an order of magnitude slower.
-
-
-I was tracing it down (insert a long strange trip here) and found that it occurs:
-- only with patch dab30fb "acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block" applied
-  - latest master is still affetced
-- only with s390x running emulation of x86
-  - emulating x86 on ppc64 didn't show the same behavior
-- only with -smp > host cpus
-  - smp 2 with 1 host cpu => slow
-  - smp 4 with 2 host cpu => slow
-  - any case where host cpu >= smp => fast
-
-On average good cases are on a 2964 s390x machine taking ~5-6 seconds for the good case.
-The bad case is close to 60s which is the timeout of the automated tests.
-
-We all know -smp shouldn't be >host-cpus, and I totally admit that this is the definition of an edge case.
-But I do not know what else might be affected and this just happened to be what the test does by default - and a slowdown by x10 seems too much even for edge cases to be just ignored.
-And while we could just bump up the timeout (and probably will as an interim workaround) I wanted to file it here for your awareness.
-Steps to reproduce:
-You can recreate the same by using the commandline above and timing things on your own.
-
-Or you can use the [autopkgtest of edk2 in Ubuntu](https://git.launchpad.net/ubuntu/+source/edk2/tree/debian/tests/shell.py#n214) which have [shown this](https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/e/edk2/20230224_094012_c95f4@/log.gz) first.
-Additional information:
-Only signed OVMF cases are affected, while aavmf and other OVMF are more or less on the same speed.
-
-```
-1 CPU / 1GB Memory
-7.0     7.2
-6.54s   58.32s test_ovmf_ms
-6.72s   56.96s test_ovmf_4m_ms
-7.54s   55.47s test_ovmf_4m_secboot
-7.56s   49.88s test_ovmf_secboot
-7.01s   39.79s test_ovmf32_4m_secboot
-7.38s    7.43s  test_aavmf32
-7.27s    7.30s  test_aavmf
-7.26s    7.26s  test_aavmf_snakeoil
-5.83s    5.95s  test_ovmf_4m
-5.61s    5.81s  test_ovmf_q35
-5.51s    5.64s  test_ovmf_pc
-5.26s    5.42s  test_ovmf_snakeoil
-```
-
-Highlighting @cborntra since it is somewhat s390x related and @mjt0k as the patch is applied as backport in Debian.
-I didn't find the handle of Laszlo (Author) to highlight him as well.