summary refs log tree commit diff stats
path: root/gitlab/issues/target_i386/host_x86/accel_missing
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-05-21 21:21:26 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-05-21 21:21:26 +0200
commit4b927bc37359dec23f67d3427fc982945f24f404 (patch)
tree245449ef9146942dc7fffd0235b48b7e70a00bf2 /gitlab/issues/target_i386/host_x86/accel_missing
parentaa8bd79cec7bf6790ddb01d156c2ef2201abbaab (diff)
downloadqemu-analysis-4b927bc37359dec23f67d3427fc982945f24f404.tar.gz
qemu-analysis-4b927bc37359dec23f67d3427fc982945f24f404.zip
add gitlab issues in toml format
Diffstat (limited to 'gitlab/issues/target_i386/host_x86/accel_missing')
-rw-r--r--gitlab/issues/target_i386/host_x86/accel_missing/1910.toml70
-rw-r--r--gitlab/issues/target_i386/host_x86/accel_missing/1926.toml32
-rw-r--r--gitlab/issues/target_i386/host_x86/accel_missing/1946.toml38
-rw-r--r--gitlab/issues/target_i386/host_x86/accel_missing/2608.toml19
4 files changed, 159 insertions, 0 deletions
diff --git a/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml b/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml
new file mode 100644
index 000000000..783fd1a6d
--- /dev/null
+++ b/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml
@@ -0,0 +1,70 @@
+id = 1910
+title = "Signal handlers in x86_64 userspace have wrongly aligned stack"
+state = "closed"
+created_at = "2023-09-28T08:17:08.602Z"
+closed_at = "2023-09-29T14:53:31.357Z"
+labels = ["Closed::Duplicate", "host: x86", "linux-user", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1910"
+host-os = "openSUSE Tumbleweed"
+host-arch = "x86_64"
+qemu-version = "8.1.0"
+guest-os = "Linux"
+guest-arch = "x86_64"
+description = """Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause.
+
+```plaintext
+> qemu-x86_64 /usr/bin/ruby -e '`true`'
+-e:1: [BUG] Segmentation fault at 0x0000000000000000
+ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu]
+
+-- Control frame information -----------------------------------------------
+c:0003 p:---- s:0011 e:000010 CFUNC  :`
+c:0002 p:0005 s:0006 e:000005 EVAL   -e:1 [FINISH]
+c:0001 p:0000 s:0003 E:0015b0 DUMMY  [FINISH]
+
+-- Ruby level backtrace information ----------------------------------------
+-e:1:in `<main>'
+-e:1:in ``'
+
+-- Machine register context ------------------------------------------------
+ RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98
+ RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000
+ RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000
+  R8: 0x00002aaaab2aaa50  R9: 0x0000000000000050 R10: 0x0000000000000008
+ R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310
+ R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246
+
+-- C level backtrace information -------------------------------------------
+```
+
+```plaintext
+(gdb) x/i $pc
+=> 0x2aaaab50f98a:      movaps %xmm0,(%rsp)
+(gdb) p/x $rsp
+$3 = 0x2aaaab2a9998
+```"""
+reproduce = """1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'```"""
+additional = """The x86_64 psABI says:
+
+> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point.
+
+However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`.
+
+The relevant kernel code:
+
+https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123
+
+```plaintext
+\tsp -= frame_size;
+
+\tif (ia32_frame)
+\t\t/*
+\t\t * Align the stack pointer according to the i386 ABI,
+\t\t * i.e. so that on function entry ((sp + 4) & 15) == 0.
+\t\t */
+\t\tsp = ((sp + 4) & -FRAME_ALIGNMENT) - 4;
+\telse
+\t\tsp = round_down(sp, FRAME_ALIGNMENT) - 8;
+```
+
+CC @lvivier @bonzini @rth7680"""
diff --git a/gitlab/issues/target_i386/host_x86/accel_missing/1926.toml b/gitlab/issues/target_i386/host_x86/accel_missing/1926.toml
new file mode 100644
index 000000000..8e795c3bd
--- /dev/null
+++ b/gitlab/issues/target_i386/host_x86/accel_missing/1926.toml
@@ -0,0 +1,32 @@
+id = 1926
+title = "Spice: handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed (DoS via assert failure)"
+state = "closed"
+created_at = "2023-10-09T11:52:41.324Z"
+closed_at = "2025-01-13T09:42:59.989Z"
+labels = ["Fuzzer", "host: x86", "spice", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1926"
+host-os = "Debian 12"
+host-arch = "x86_64"
+qemu-version = "version 8.1.50 (v8.1.0-1353-g 2f3913f4b2-dirty), commit 2f3913f4b2"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """Assert failure in libspice-server was found during fuzzing qxl-vga device.
+
+```plaintext
+qemu-system-x86_64: Spice: ../server/red-worker.cpp:367:handle_dev_destroy_surface_wait: condition `msg->surface_id == 0' failed
+Аварийный останов
+```"""
+reproduce = """1. This bug can be reroduced with 
+
+   ```plaintext
+   cat << EOF | ./qemu-system-x86_64 -display none -machine accel=qtest, -m 512M -M \\
+   pc -nodefaults -vga qxl -qtest stdio
+   outl 0xcf8 0x8000101c
+   outl 0xcfc 0xc000
+   outl 0xcf8 0x80001004
+   outw 0xcfc 0x01
+   outl 0xc00b 0x01000000
+   EOF
+   ```
+2. This bug is in another place from https://gitlab.com/qemu-project/qemu/-/issues/1829, please pay attention to it. It has to be solved, because it interferes with further fuzzing process"""
+additional = """As I mentioned, I really need this bug to be solved, because fuzzing qxl-vga device gets less efficient. I suggested to report it here, not in spice-server, because this bug can be on the QEMU side."""
diff --git a/gitlab/issues/target_i386/host_x86/accel_missing/1946.toml b/gitlab/issues/target_i386/host_x86/accel_missing/1946.toml
new file mode 100644
index 000000000..93bc8a1f8
--- /dev/null
+++ b/gitlab/issues/target_i386/host_x86/accel_missing/1946.toml
@@ -0,0 +1,38 @@
+id = 1946
+title = "High CPU Load after QEMU 8.1.1"
+state = "closed"
+created_at = "2023-10-16T15:19:44.051Z"
+closed_at = "2023-10-17T08:33:48.630Z"
+labels = ["host: x86", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1946"
+host-os = "IPFire 2.27 (x86_64) - core180"
+host-arch = "x86_64"
+qemu-version = "8.1.1-40 (libvirt-8.10.0-33)"
+guest-os = "Ubuntu Server 20.04 LTS, Ubuntu Server 22.04 LTS"
+guest-arch = "n/a"
+description = """Since the update there is a massive CPU load and this affects the CPU load of the router.
+The VMs are partially for about 3min sporadically not accessible.
+The VMs themselves were not adjusted and I have in the console.
+
+Using the VMM, I was able to see the message recorded below.
+
+`watchdog:_ BUG: soft lockup - CPU#0 stuck for 21s! [swapper/0:0]`
+
+I will also add some data like a XML file of a VM."""
+reproduce = "n/a"
+additional = """![webproxy](/uploads/5df86f9adfdd257ca2f43697603567c3/webproxy.PNG)
+[webproxy.log](/uploads/1d428f4c59b2397b9343a62dd8c4bce2/webproxy.log)
+
+[webproxy.xml](/uploads/04221c88956c49d76b4896dd8f6fd1f0/webproxy.xml)
+[Host_Kernel.log](/uploads/f145bf599bf2003b89c17daaabb07143/Host_Kernel.log)
+
+Unfortunately I can't revert to the old QEMU version in the router OS but in the current state all my VM are not really 100% usable anymore.
+
+I would be very grateful if you could take a look at my case.
+
+many thanks in advance.
+
+
+
+
+Paul"""
diff --git a/gitlab/issues/target_i386/host_x86/accel_missing/2608.toml b/gitlab/issues/target_i386/host_x86/accel_missing/2608.toml
new file mode 100644
index 000000000..67d66438d
--- /dev/null
+++ b/gitlab/issues/target_i386/host_x86/accel_missing/2608.toml
@@ -0,0 +1,19 @@
+id = 2608
+title = "Black screen in Windows XP"
+state = "opened"
+created_at = "2024-10-04T17:54:26.882Z"
+closed_at = "n/a"
+labels = ["guest: Windows", "host: x86", "target: i386"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/2608"
+host-os = "Ubuntu 24.04.1 LTS (GNU/Linux )"
+host-arch = "x86_x64"
+qemu-version = "9.1.0"
+guest-os = "n/a"
+guest-arch = "n/a"
+description = """When starting the installation of Windows XP (or Windows 2003) the screen in VNC stays black while the installer is in text-mode. During the second half of the installation, where it switches to graphical GUI, the display becomes visible again.
+
+This problem never happened on 9.0.1 and below, so is a regression in 9.1.0"""
+reproduce = """1. Start the Windows XP installer
+2. Connect to VNC
+3. Screen stays black"""
+additional = "n/a"