diff options
Diffstat (limited to 'gitlab/issues/target_missing/host_missing/accel_missing/1520.toml')
| -rw-r--r-- | gitlab/issues/target_missing/host_missing/accel_missing/1520.toml | 57 |
1 files changed, 0 insertions, 57 deletions
diff --git a/gitlab/issues/target_missing/host_missing/accel_missing/1520.toml b/gitlab/issues/target_missing/host_missing/accel_missing/1520.toml deleted file mode 100644 index 325ec6f95..000000000 --- a/gitlab/issues/target_missing/host_missing/accel_missing/1520.toml +++ /dev/null @@ -1,57 +0,0 @@ -id = 1520 -title = "x86 TCG acceleration running on s390x with -smp > host cpus slowed down by x10" -state = "closed" -created_at = "2023-02-28T10:56:29.215Z" -closed_at = "2023-03-02T15:50:27.858Z" -labels = [] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1520" -host-os = "Ubuntu 23.04" -host-arch = "s390x" -qemu-version = "latest master v7.2.0-1688-ge1f9f73ba1" -guest-os = "none, just boot into OVMF" -guest-arch = "x86" -description = """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.""" -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 = """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.""" |