diff options
Diffstat (limited to 'gitlab/issues/target_i386/host_x86')
14 files changed, 0 insertions, 870 deletions
diff --git a/gitlab/issues/target_i386/host_x86/accel_KVM/1151.toml b/gitlab/issues/target_i386/host_x86/accel_KVM/1151.toml deleted file mode 100644 index b26fba89f..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_KVM/1151.toml +++ /dev/null @@ -1,59 +0,0 @@ -id = 1151 -title = "when guest unexpect shutdown,can't enter system,the terminal has a black screen" -state = "opened" -created_at = "2022-08-12T06:34:17.125Z" -closed_at = "n/a" -labels = ["accel: KVM", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1151" -host-os = "centos8" -host-arch = "x86" -qemu-version = "6.2.0" -guest-os = "Windows 7" -guest-arch = "x86" -description = """""" -reproduce = """1.guest unexpect shutdown - -2.when start again,cpu usage is high and can't enter the guest system - -3.restart guest can recovery - -**libvirt print：** - -`2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: high-privileges - -2022-08-11 14:39:58.080+0000: 1942: warning : qemuDomainObjTaint:6079 : Domain id=117 name='GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d' uuid=99d2578e-f06e-4fbe-88dd-7d9dd56fd02d is tainted: custom-argv - -2022-08-11 14:40:28.792+0000: 741037: warning : qemuDomainObjBeginJobInternal:946 : Cannot start job (modify, none, none) for domain GDT99d2578e-f06e-4fbe-88dd-7d9dd56fd02d; current job is (none, none, migration in) owned by (0 <null>, 0 <null>, 0 remoteDispatchDomainMigratePrepare3Params (flags=0x203)) for (0s, 0s, 30s) - -2022-08-11 14:40:28.792+0000: 741037: error : qemuDomainObjBeginJobInternal:968 : Timed out during operation: cannot acquire state change lock (held by monitor=remoteDispatchDomainMigratePrepare3Params) -` - - -**user perf to analyse:** - -\\#top -d 3 -Hp 1311519 - - - -\\#perf record -a -g -p 1311519 sleep 20 - -\\#report -n --header --stdio - - - - -**query kvm stat:** - - \\# perf stat -e 'kvm:*' -a -p 1311519 sleep 20 - - - - -kvm vmexit stat: - -\\#perf kvm stat record -a -p 1311519 sleep 10 - -\\#perf kvm stat report --event=vmexit - -""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml b/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml deleted file mode 100644 index a81178c00..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_KVM/1152.toml +++ /dev/null @@ -1,36 +0,0 @@ -id = 1152 -title = "Windows crashes on resuming from sleep if hv-tlbflush is enabled" -state = "opened" -created_at = "2022-08-12T09:17:41.461Z" -closed_at = "n/a" -labels = ["accel: KVM", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1152" -host-os = "Arch Linux" -host-arch = "x86_64 Intel i9-12900K" -qemu-version = "7.0.0" -guest-os = "Windows 10 21H2" -guest-arch = "x86_64" -description = """The above steps cause my Windows VM to BSOD immediately upon waking up (even before restarting the display driver in my case).""" -reproduce = """1. Boot Windows -2. Tell Windows to go to sleep (observe that qemu's state switches to suspended) -3. Cause windows to wake up (e.g. using the `system_wakeup` HMP command)""" -additional = """Looking at the crash dumps always shows the "ATTEMPTED WRITE TO READONLY MEMORY" error, and always with this stack trace: - -``` -nt!KeBugCheckEx -nt!MiRaisedIrqlFault+0x1413a6 -nt!MmAccessFault+0x4ef -nt!KiPageFault+0x35e -nt!MiIncreaseUsedPtesCount+0x12 -nt!MiBuildForkPte+0xc6 -nt!MiCloneVads+0x4ab -nt!MiCloneProcessAddressSpace+0x261 -nt!MmInitializeProcessAddressSpace+0x1cb631 -nt!PspAllocateProcess+0x1d13 -nt!PspCreateProcess+0x242 -nt!NtCreateProcessEx+0x85 -nt!KiSystemServiceCopyEnd+0x25 -ntdll!NtCreateProcessEx+0x14 -``` - -However, the process that is being created here is always `WerFault.exe`, i.e. the crash reporter. The crashing process is seemingly random. Removing `hv-tlbflush` from the command line resolves the problem. Hence, my hypothesis is that due to improper TLB flushing during wakeup, a random application on the core will crash, which spawns `WerFault.exe` which then immediately crashes again inside the kernel (also because of bad/stale TLB contents) and causes the BSOD. Perhaps one core wakes up first, requests a TLB flush, which is then *not* propagated to sleeping cores due to hv-tlbflush. Then one of those cores wakes up without the TLB flush?""" diff --git a/gitlab/issues/target_i386/host_x86/accel_KVM/2574.toml b/gitlab/issues/target_i386/host_x86/accel_KVM/2574.toml deleted file mode 100644 index 7685fe45b..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_KVM/2574.toml +++ /dev/null @@ -1,57 +0,0 @@ -id = 2574 -title = "VM hang: 'error: kvm run failed Bad address' with some AMD GPUs since kernel 6.7" -state = "opened" -created_at = "2024-09-16T20:43:20.431Z" -closed_at = "n/a" -labels = ["accel: KVM", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2574" -host-os = "Debian unstable" -host-arch = "x86 (AMD 5600G)" -qemu-version = "9.1.0 (Debian 1:9.1.0+ds-3+b1)" -guest-os = "Debian unstable" -guest-arch = "x86" -description = """The Debian ROCm Team runs GPU-utilizing test workloads in QEMU VMs into which we pass through AMD GPUs attached to PCIe x16 slots on the host. We do this to quickly test various Debian distributions/kernels/firmwares on a single physical host per GPU, and to isolate the host as much as possible from potentially hostile code. - -Starting with kernel 6.7 in the **guest**, with Navi 31 GPUs (eg: RX 7900 XT), as soon as anything triggers access to the GPU's memory, the VM hangs with `error: kvm run failed Bad address` and dumps its state. - -I gather that [this](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3046-L3048) is where this message originates from. It would seem that the preceding [ioctl](https://gitlab.com/qemu-project/qemu/-/blob/ea9cdbcf3a0b8d5497cddf87990f1b39d8f3bb0a/accel/kvm/kvm-all.c#L3025) runs into `EFAULT` which eventually leads to a break out of the surrounding loop. - -Since we can reliably reproduce this starting with 6.7, our assumption is that this is caused by a change in the kernel and/or the `amdgpu` driver. However, as the error originates from kvm *on the host*, we could not rule out that this might also be a emulation issue. In particular, it was only 9.1 [c15e568](c15e568) where the handling of the `EFAULT` and `KVM_EXIT_MEMORY_FAULT` case was added, so perhaps we ran into something that is still incomplete. - -I'd appreciate any advice you could give us for further debugging. We will bisect 6.7 to see what could have triggered this on the guest side, but is there something that we can do on the host to further track this down, in particular which `-trace`s might be helpful? - -Other notes: -- The VM boots and runs fine, GPU initializes fine according to `dmesg`. The issue is only triggered on GPU utilization -- The problematic GPU in question worked fine with kernels 6.3 - 6.6 -- All other GPU architectures that we test this way (eg: Navi 2x) do not experience this issue, they work fine with all kernels we tested -- We have checked with more than one GPU, to rule out a physical defect""" -reproduce = """Reproducing the issue requires -1. A suitable image -2. Access to a Navi 3x card. Remote access can be arranged, if necessary. - -Building a suitable image can be rather complicated and requires a Debian host. If needed, it would be easier for me to just share a pre-built image.""" -additional = """This is dumped just before the VM hangs: -``` -ROCk module is loaded -error: kvm run failed Bad address -RAX=00000000000035c8 RBX=00000000000006ba RCX=0003000108b08073 RDX=00000000000006b9 -RSI=ffff9994b00035c8 RDI=ffff899403c80000 RBP=ffff899408b285e0 RSP=ffff9994816ab620 -R8 =0003000000000073 R9 =ffff9994b0000000 R10=ffff899403c8fb18 R11=ffff899408b065b8 -R12=ffff899403c80000 R13=0003000000000073 R14=ffff9994b0000000 R15=00000000000006ba -RIP=ffffffffc11d8f93 RFL=00000282 [--S----] CPL=0 II=0 A20=1 SMM=0 HLT=0 -ES =0000 0000000000000000 00000000 00000000 -CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] -SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] -DS =0000 0000000000000000 00000000 00000000 -FS =0000 00007faa76aea780 00000000 00000000 -GS =0000 ffff899f0dd80000 00000000 00000000 -LDT=0000 0000000000000000 00000000 00000000 -TR =0040 fffffe41c66fc000 00004087 00008b00 DPL=0 TSS64-busy -GDT= fffffe41c66fa000 0000007f -IDT= fffffe0000000000 00000fff -CR0=80050033 CR2=000055bd5a5d8598 CR3=000000010342c000 CR4=00750ef0 -DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 -DR6=00000000ffff0ff0 DR7=0000000000000400 -EFER=0000000000000d01 -Code=ff ff 00 00 48 21 c1 8d 04 d5 00 00 00 00 4c 09 c1 48 01 c6 <48> 89 0e 31 c0 e9 6e b1 92 d2 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 -```""" diff --git a/gitlab/issues/target_i386/host_x86/accel_KVM/2609.toml b/gitlab/issues/target_i386/host_x86/accel_KVM/2609.toml deleted file mode 100644 index 13a33780f..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_KVM/2609.toml +++ /dev/null @@ -1,21 +0,0 @@ -id = 2609 -title = "Blue screen in Windows XP" -state = "closed" -created_at = "2024-10-05T09:30:01.873Z" -closed_at = "2024-10-20T12:21:16.168Z" -labels = ["accel: KVM", "guest: Windows", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2609" -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 when using a virtioblk device you immediately get a bluescreen: `STOP: 0x000000A5 (0x00000002, 0x8A1A6008, 0xE1018808, 0x8A1B7F00)`. I think this happens even before it loads the SATA drivers that are slipstreamed in the ISO. - -After a lot of Googling about this error 0x000000A5 I found some posts suggesting that changing the machine type from `q35` to `pc-q35-2.10` solves the issue. And it worked. Anything above 2.10 (for example 2.11) and the bluescreens return. - -So I always used this solution, but in QEMU 9.1.0 it warns that `pc-q35-2.10` will be removed soon. This would mean there is no way anymore to install XP to a SATA disk unattendly.""" -reproduce = """1. Use a virtioblk disk and SATA drivers -2. Start the Windows XP installer -3. Bluescreen will appear""" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_x86/accel_TCG/1846.toml b/gitlab/issues/target_i386/host_x86/accel_TCG/1846.toml deleted file mode 100644 index 6850e89bc..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_TCG/1846.toml +++ /dev/null @@ -1,33 +0,0 @@ -id = 1846 -title = "Regression in q35 avocado tests due to fix for misaligned IO access" -state = "closed" -created_at = "2023-08-25T14:42:44.886Z" -closed_at = "2023-08-30T16:22:37.487Z" -labels = ["Closed::Fixed", "accel: TCG", "host: x86", "kind::Bug", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/1846" -host-os = "Ubuntu" -host-arch = "x64" -qemu-version = "8.1" -guest-os = "Linux" -guest-arch = "x86_64 (under TCG)" -description = """Generally I'm seeing intermittent hangs, somewhere after the clock initialisation. - -``` -[ 4.137020] ALSA device list: -[ 4.137861] No soundcards found. -[ 4.634128] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 -[ 24.085574] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: -[ 24.085712] rcu: 0-...!: (0 ticks this GP) idle=4d18/0/0x0 softirq=54/54 fqs=0 (false positive?) -[ 24.085712] (detected by 1, t=21004 jiffies, g=-1003, q=2151 ncpus=2) -[ 24.085712] Sending NMI from CPU 1 to CPUs 0: -[ 4.647507] NMI backtrace for cpu 0 -[ 4.647507] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0.11 #5 -[ 4.647507] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 -[ 4.647507] RIP: 0010:amd_e400_idle+0x39/0x40 -[ 4.647507] Code: 00 e8 fb ab 0d 00 eb 07 0f 00 2d c2 7d 1d 01 fb f4 fa 31 ff e8 e8 ab 0d 00 fb c3 cc cc cc cc eb 07 0f 00 2d a9 7d 1d 01 fb f4 <c3> cc cc cc cc 66 90 bf -01 00 00 00 e8 a6 e4 06 00 65 48 8b 04 25 -``` - -In avocado the hang generally times out and the test fails.""" -reproduce = """See above command line. It's racy.""" -additional = """""" diff --git a/gitlab/issues/target_i386/host_x86/accel_TCG/2159.toml b/gitlab/issues/target_i386/host_x86/accel_TCG/2159.toml deleted file mode 100644 index 9350d2bc5..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_TCG/2159.toml +++ /dev/null @@ -1,185 +0,0 @@ -id = 2159 -title = "qemu-system-x86_64 crashes in temp_load (tcg) on i686 host" -state = "closed" -created_at = "2024-02-11T04:35:08.344Z" -closed_at = "2024-02-14T15:45:11.333Z" -labels = ["Closed::Fixed", "accel: TCG", "host: x86", "host:32bit", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2159" -host-os = "Slackware 15.0 i586" -host-arch = "x86_64" -qemu-version = "QEMU emulator version 8.2.50" -guest-os = "Slackel 7.7.1" -guest-arch = "x86_64" -description = """qemu crashes early""" -reproduce = """1. compile qemu git (commit commit 5d1fc614413b10dd94858b07a1b2e26b1aa0296c (origin/master, origin/HEAD) -) with line -../configure --prefix=/usr --enable-virglrenderer --libdir=lib --audio-drv-list=alsa,oss --enable-opengl --extra-cflags="-I/usr/X11R7/include -O2 -march=i686 -mtune=native -m32 -Wno-maybe-uninitialized -Wno-nested-externs -Wno-implicit-function-declaration" --disable-werror - -2. setarch i686 ninja (kernel is x86_64 on host) -3. try to boot 64-bit x86 Salix/Slackel (Slackware live images)""" -additional = """``` - gdb x86_64-softmmu/qemu-system-x86_64 -GNU gdb (GDB) 11.2 -Copyright (C) 2022 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. -Type "show copying" and "show warranty" for details. -This GDB was configured as "i586-slackware-linux". -Type "show configuration" for configuration details. -For bug reporting instructions, please see: -<https://www.gnu.org/software/gdb/bugs/>. -Find the GDB manual and other documentation resources online at: - <http://www.gnu.org/software/gdb/documentation/>. - -For help, type "help". -Type "apropos word" to search for commands related to "word"... -Reading symbols from x86_64-softmmu/qemu-system-x86_64... -warning: File "/dev/shm/qemu/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". -To enable execution of this file add - add-auto-load-safe-path /dev/shm/qemu/.gdbinit -line to your configuration file "/root/.config/gdb/gdbinit". -To completely disable this security protection add - set auto-load safe-path / -line to your configuration file "/root/.config/gdb/gdbinit". -For more information about this security protection see the ---Type <RET> for more, q to quit, c to continue without paging-- -"Auto-loading safe path" section in the GDB manual. E.g., run from the shell: - info "(gdb)Auto-loading safe path" -(gdb) r -m 1000 -cdrom /home/guest/ISO/sla -slackellive64-openbox-7.7.1.iso slackware-8.0-install-d1.iso -(gdb) r -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso -Starting program: /dev/shm/qemu/build/x86_64-softmmu/qemu-system-x86_64 -m 1000 -cdrom /home/guest/ISO/slackellive64-openbox-7.7.1.iso -[Thread debugging using libthread_db enabled] -Using host libthread_db library "/lib/libthread_db.so.1". -[New Thread 0xf3e79b00 (LWP 27354)] -[New Thread 0xf2f09b00 (LWP 27355)] -[New Thread 0xb1917b00 (LWP 27356)] -[New Thread 0xaf60cb00 (LWP 27357)] -[Thread 0xaf60cb00 (LWP 27357) exited] -[New Thread 0xaf60cb00 (LWP 27358)] -[New Thread 0xaec86b00 (LWP 27359)] -[Thread 0xaf60cb00 (LWP 27358) exited] -[Thread 0xaec86b00 (LWP 27359) exited] -[New Thread 0xaec86b00 (LWP 27360)] -[New Thread 0xaf60cb00 (LWP 27361)] -[Thread 0xaec86b00 (LWP 27360) exited] -[Thread 0xaf60cb00 (LWP 27361) exited] -[Thread 0xf2f09b00 (LWP 27355) exited] - -Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. -[Switching to Thread 0xb1917b00 (LWP 27356)] -0x56d08a95 in temp_load (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 -4441 tcg_out_ld(s, ts->type, reg, ts->mem_base->reg, ts->mem_offset); -(gdb) bt full -#0 0x56d08a95 in temp_load - (s=0xb1000610, ts=ts@entry=0xb1001f40, desired_regs=<optimized out>, allocated_regs=2097200, preferred_regs=0) at ../tcg/tcg.c:4441 - reg = TCG_REG_ECX - __func__ = "temp_load" -#1 0x56d0fe23 in tcg_reg_alloc_op (op=<optimized out>, s=<optimized out>) - at ../tcg/tcg.c:4881 - i_required_regs = <optimized out> - copyto_new_reg = false - ts2 = <optimized out> - i1 = <optimized out> - i_preferred_regs = <optimized out> - allocate_new_reg = <optimized out> - i2 = <optimized out> - i = 0 - new_args = - {1, 5, 2852, 0, 64, 0, 0, 1467284236, 4149882880, 2829350448, 1, 1456305553, 4149882880, 2969568784, 2969568920, 2969568944} - arg_life = <optimized out> - i_allocated_regs = <optimized out> - nb_oargs = <optimized out> - arg = <optimized out> - const_args = ---Type <RET> for more, q to quit, c to continue without paging-- - {0, 0, 0, 0, 1, 1, 1467284236, -1315870200, 1487331864, -1069806704, 0, 1467284236, 1456520351, 1489883472, 2, -1325347776} - k = <optimized out> - arg_ct = <optimized out> - o_allocated_regs = <optimized out> - nb_iargs = <optimized out> - reg = <optimized out> - ts = 0xb1001f40 - op_cond = <optimized out> - opc = <optimized out> - i = <optimized out> - start_words = <optimized out> - num_insns = <optimized out> - op = <optimized out> - __PRETTY_FUNCTION__ = "tcg_gen_code" -#2 tcg_gen_code - (s=<optimized out>, tb=<optimized out>, pc_start=<optimized out>) - at ../tcg/tcg.c:6216 - opc = <optimized out> - i = <optimized out> - start_words = <optimized out> - num_insns = <optimized out> - op = <optimized out> ---Type <RET> for more, q to quit, c to continue without paging-- - __PRETTY_FUNCTION__ = "tcg_gen_code" -#3 0x56af0118 in setjmp_gen_code - (env=env@entry=0x57afab90, tb=tb@entry=0xf0b7d580 <code_gen_buffer+8389982>, pc=18446744072243800976, host_pc=0xc03c0b90, max_insns=0xb1916acc, ti=<optimized out>) at ../accel/tcg/translate-all.c:284 - ret = <optimized out> - __PRETTY_FUNCTION__ = "setjmp_gen_code" -#4 0x56af06e2 in tb_gen_code - (cpu=0x57af8860, pc=18446744072243800976, cs_base=0, flags=4244144, cflags=<optimized out>) at ../accel/tcg/translate-all.c:359 - env = 0x57afab90 - tb = 0xf0b7d580 <code_gen_buffer+8389982> - existing_tb = <optimized out> - phys_pc = 245525392 - phys_p2 = <optimized out> - gen_code_buf = 0xf0b7d600 <code_gen_buffer+8390110> "‹]ш…Ы\\017Њр" - gen_code_size = <optimized out> - search_size = <optimized out> - max_insns = 64 - host_pc = 0xc03c0b90 - __PRETTY_FUNCTION__ = "tb_gen_code" - __func__ = "tb_gen_code" -#5 0x56ae75bd in cpu_exec_loop ---Type <RET> for more, q to quit, c to continue without paging-- - (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) - at ../accel/tcg/cpu-exec.c:982 - jc = <optimized out> - h = <optimized out> - tb = 0x0 - flags = <optimized out> - cflags = 4278321152 - pc = <optimized out> - cs_base = <optimized out> - last_tb = <optimized out> - tb_exit = 0 - ret = <optimized out> -#6 0x56ae7a70 in cpu_exec_setjmp - (cpu=cpu@entry=0x57af8860, sc=sc@entry=0xb1916c24) - at ../accel/tcg/cpu-exec.c:1028 -#7 0x56ae83a8 in cpu_exec (cpu=<optimized out>) - at ../accel/tcg/cpu-exec.c:1054 - ret = <optimized out> - sc = {diff_clk = 0, last_cpu_icount = 0, realtime_clock = 0} - _rcu_read_auto = 0x1 -#8 0x56b0ff5e in tcg_cpu_exec (cpu=0x57af8860) - at ../accel/tcg/tcg-accel-ops.c:76 - ret = <optimized out> ---Type <RET> for more, q to quit, c to continue without paging-- - __PRETTY_FUNCTION__ = "tcg_cpu_exec" -#9 0x56b10a47 in rr_cpu_thread_fn (arg=<optimized out>) - at ../accel/tcg/tcg-accel-ops-rr.c:261 - r = <optimized out> - cpu_budget = <optimized out> - force_rcu = - {notify = 0x56b106e0 <rr_force_rcu>, node = {le_next = 0x0, le_prev = 0xb19179b0}} - cpu = 0x57af8860 - __PRETTY_FUNCTION__ = "rr_cpu_thread_fn" -#10 0x56cc77e5 in qemu_thread_start (args=0x57b51ce0) - at ../util/qemu-thread-posix.c:541 - __cancel_buf = - {__cancel_jmp_buf = {{__cancel_jmp_buf = {1467284236, 1471487200, 1471152128, -1315869272, 1617656260, -631423478}, __mask_was_saved = 0}}, __pad = {0xb1916d64, 0x0, 0x0, 0x0}} - __cancel_routine = 0x56cc7840 <qemu_thread_atexit_notify> - __not_first_call = <optimized out> - start_routine = 0x56b10818 <rr_cpu_thread_fn> - arg = 0x57af8860 - r = <optimized out> -#11 0xf63d5328 in start_thread () at /lib/libpthread.so.0 -#12 0xf604ef06 in clone () at /lib/libc.so.6 -```""" diff --git a/gitlab/issues/target_i386/host_x86/accel_TCG/2413.toml b/gitlab/issues/target_i386/host_x86/accel_TCG/2413.toml deleted file mode 100644 index 81ab6eb8a..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_TCG/2413.toml +++ /dev/null @@ -1,41 +0,0 @@ -id = 2413 -title = "Use of TSTEQ/TSTNE has regressed the cdrom test when running a 32 bit build of qemu-system-x86_64 using TCG" -state = "closed" -created_at = "2024-06-28T12:00:52.273Z" -closed_at = "2024-07-03T22:35:50.145Z" -labels = ["Closed::Fixed", "accel: TCG", "host: x86", "kind::Bug", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2413" -host-os = "Debian Bookworm" -host-arch = "x86_64" -qemu-version = "15957eb9efe2da67c796612cead95cba28ba9bda" -guest-os = "n/a" -guest-arch = "qtest-x86_64/cdrom-test (/x86_64/cdrom/boot/lsi53c895a)" -description = """The test freezes, eventually timing out. The bisect was confused by other SEV related things so I had to whittle down the config to --disable-kvm.""" -reproduce = """1. '../../configure' '--disable-docs' '--disable-user' '--cross-prefix=i686-linux-gnu-' '--target-list=x86_64-softmmu' '--enable-debug' '--disable-kvm' -2. ninja -3. meson test -t 0.05 qtest-x86_64/cdrom-test V=1""" -additional = """Bisect run pointed at: - -``` -commit 15957eb9efe2da67c796612cead95cba28ba9bda -Author: Paolo Bonzini <pbonzini@redhat.com> -Date: Fri Oct 27 05:57:31 2023 +0200 - - target/i386: use TSTEQ/TSTNE to test low bits - - When testing the sign bit or equality to zero of a partial register, it - is useful to use a single TSTEQ or TSTNE operation. It can also be used - to test the parity flag, using bit 0 of the population count. - - Do not do this for target_ulong-sized values however; the optimizer would - produce a comparison against zero anyway, and it avoids shifts by 64 - which are undefined behavior. - - Reviewed-by: Richard Henderson <richard.henderson@linaro.org> - Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> - - target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- - target/i386/tcg/emit.c.inc | 5 ++--- - 2 files changed, 22 insertions(+), 11 deletions(-) -bisect found first bad commit⏎ -```""" diff --git a/gitlab/issues/target_i386/host_x86/accel_TCG/2784.toml b/gitlab/issues/target_i386/host_x86/accel_TCG/2784.toml deleted file mode 100644 index cb8b72f44..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_TCG/2784.toml +++ /dev/null @@ -1,227 +0,0 @@ -id = 2784 -title = "SIGILL during DPDK e1000e device initialization - VMOVD instruction fails in QEMU" -state = "opened" -created_at = "2025-01-19T16:25:19.971Z" -closed_at = "n/a" -labels = ["accel: TCG", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2784" -host-os = "Ubuntu 22.04.4 LTS" -host-arch = "x86" -qemu-version = "qemu-9.2.0" -guest-os = "Ubuntu 24.04.1 LTS" -guest-arch = "x86" -description = """I think it's a QEMU issue, but it could be rather a DPDK issue. -When using DPDK with QEMU's e1000e device, the initialization fails with SIGILL (Illegal Instruction) during the LED initialization phase. The issue occurs specifically with the e1000e device and not with other network devices. - -Output from GDB: -``` -Starting DPDK initialization... -EAL: Detected CPU lcores: 4 -EAL: Detected NUMA nodes: 1 -EAL: Auto-detected process type: PRIMARY -EAL: Detected shared linkage of DPDK -EAL: Multi-process socket /var/run/dpdk/rte/mp_socket -EAL: Selected IOVA mode 'PA' -EAL: VFIO support initialized -EAL: Using IOMMU type 1 (Type 1) -EAL: Ignore mapping IO port bar(2) -EAL: Probe PCI driver: net_e1000_em (8086:10d3) device: 0000:01:00.0 (socket -1) - -Thread 1 "hello" received signal SIGILL, Illegal instruction. -0x00007ffff1d4f63e in e1000_id_led_init_generic () - from /usr/local/lib/x86_64-linux-gnu/dpdk/pmds-24.0/librte_net_e1000.so.24.0 - -1: x/i $pc -=> 0x7ffff1d4f63e <e1000_id_led_init_generic+94>:\tvmovd 0xe00(%rax),%xmm0 -``` - -PCI device information: -``` -01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection - Subsystem: Intel Corporation 82574L Gigabit Network Connection - Physical Slot: 0 - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- - Interrupt: pin A routed to IRQ 22 - IOMMU group: 6 - Region 0: Memory at fe840000 (32-bit, non-prefetchable) [size=128K] - Region 1: Memory at fe860000 (32-bit, non-prefetchable) [size=128K] - Region 2: I/O ports at c000 [size=32] - Region 3: Memory at fe880000 (32-bit, non-prefetchable) [size=16K] - Expansion ROM at fe800000 [disabled] [size=256K] -``` - -GDB Analysis: -The crash occurs during LED initialization when attempting to execute a VMOVD instruction. The register RAX contains value 0x1 at the time of crash, which appears incorrect as it should contain the base address of the device's memory-mapped region (around 0xfe840000 based on PCI info). - -Both host and guest have AVX/AVX2 support -- The issue appears to be related to memory mapping or address translation -- The SIGILL occurs consistently at the same point during device initialization -- This issue only occurs with e1000e device; other network devices work correctly - -Please let me know if you need any additional information.""" -reproduce = "n/a" -additional = """Test program: -```c -#include <rte_eal.h> -#include <rte_debug.h> -#include <rte_lcore.h> -#include <rte_memory.h> -#include <rte_log.h> -#include <rte_dev.h> -#include <rte_bus.h> -#include <rte_ethdev.h> -#include <rte_kvargs.h> - -// Callback function for memory segment walking -static int dump_memseg(const struct rte_memseg_list *msl, - const struct rte_memseg *ms, void *arg) { - size_t *total_mem = arg; - *total_mem += ms->len; - return 0; -} - -static void print_device_info(uint16_t port_id) { - struct rte_eth_dev_info dev_info; - int ret = rte_eth_dev_info_get(port_id, &dev_info); - if (ret != 0) { - printf("Error getting device info for port %u: %s\\n", - port_id, rte_strerror(-ret)); - return; - } - - printf("\\nDevice Info for Port %u:\\n", port_id); - printf(" Driver name: %s\\n", dev_info.driver_name); - - // Get device capabilities - printf(" Capabilities:\\n"); - printf(" Maximum RX queues: %u\\n", dev_info.max_rx_queues); - printf(" Maximum TX queues: %u\\n", dev_info.max_tx_queues); - printf(" Maximum MTU: %u\\n", dev_info.max_mtu); - printf(" Minimum RX buffers: %u\\n", dev_info.min_rx_bufsize); - printf(" Maximum RX descriptors: %u\\n", dev_info.rx_desc_lim.nb_max); - printf(" Maximum TX descriptors: %u\\n", dev_info.tx_desc_lim.nb_max); - - // Get and print link status - struct rte_eth_link link; - ret = rte_eth_link_get_nowait(port_id, &link); - if (ret < 0) { - printf(" Link status: unknown\\n"); - } else { - printf(" Link status: %s\\n", link.link_status ? "up" : "down"); - if (link.link_status) { - printf(" Speed: %u Mbps\\n", link.link_speed); - printf(" Duplex: %s\\n", - link.link_duplex == RTE_ETH_LINK_FULL_DUPLEX ? - "full" : "half"); - } - } - - // Get and print MAC address - struct rte_ether_addr mac_addr; - ret = rte_eth_macaddr_get(port_id, &mac_addr); - if (ret < 0) { - printf(" MAC address: unknown\\n"); - } else { - printf(" MAC address: %02X:%02X:%02X:%02X:%02X:%02X\\n", - mac_addr.addr_bytes[0], mac_addr.addr_bytes[1], - mac_addr.addr_bytes[2], mac_addr.addr_bytes[3], - mac_addr.addr_bytes[4], mac_addr.addr_bytes[5]); - } - - // Get statistics - struct rte_eth_stats stats; - ret = rte_eth_stats_get(port_id, &stats); - if (ret == 0) { - printf(" Statistics:\\n"); - printf(" RX packets: %" PRIu64 "\\n", stats.ipackets); - printf(" TX packets: %" PRIu64 "\\n", stats.opackets); - printf(" RX bytes: %" PRIu64 "\\n", stats.ibytes); - printf(" TX bytes: %" PRIu64 "\\n", stats.obytes); - printf(" RX errors: %" PRIu64 "\\n", stats.ierrors); - printf(" TX errors: %" PRIu64 "\\n", stats.oerrors); - } -} - -// Print runtime configurations -void print_runtime_config(void) { - // Core and NUMA information - printf("\\n=== CPU and Memory Configuration ===\\n"); - printf("Main lcore ID: %u\\n", rte_get_main_lcore()); - printf("Number of available lcores: %u\\n", rte_lcore_count()); - - // Print available lcores and their status - printf("\\nLcore status:\\n"); - unsigned int lcore_id; - RTE_LCORE_FOREACH(lcore_id) { - printf(" Lcore %u - Role: %s, Socket: %d\\n", - lcore_id, - lcore_id == rte_get_main_lcore() ? "Main" : "Worker", - rte_lcore_to_socket_id(lcore_id)); - } - - // Memory and NUMA information - printf("\\n=== Memory Configuration ===\\n"); - printf("Number of NUMA nodes: %u\\n", rte_socket_count()); - printf("IOVA mode: %s\\n", rte_eal_iova_mode() == RTE_IOVA_PA ? "PA" : "VA"); - - // Service and Process information - printf("\\n=== Process Information ===\\n"); - printf("Process type: %s\\n", - rte_eal_process_type() == RTE_PROC_PRIMARY ? "Primary" : - rte_eal_process_type() == RTE_PROC_SECONDARY ? "Secondary" : "Invalid"); - - // Runtime options - printf("\\n=== Runtime Options ===\\n"); - printf("Current log level: %d\\n", rte_log_get_global_level()); - - // Memory allocation policy - printf("Hugepage info: %s\\n", - rte_eal_has_hugepages() ? "Using hugepages" : "Not using hugepages"); - - // Memory segments info - printf("\\n=== Memory Segments ===\\n"); - size_t total_memory = 0; - - // Walk through all memory segments - int ret = rte_memseg_walk(dump_memseg, &total_memory); - if (ret < 0) { - printf("Failed to walk memory segments\\n"); - } else { - printf("Total memory: %zu MB\\n", total_memory >> 20); - } -} - -int main(int argc, char **argv) { - printf("Starting DPDK initialization...\\n"); - - // Set log level to debug - rte_log_set_global_level(RTE_LOG_DEBUG); - - int ret = rte_eal_init(argc, argv); - if (ret < 0) { - rte_panic("Cannot init EAL: %s\\n", rte_strerror(-ret)); - } - printf("EAL initialization successful\\n"); - - // Get number of available ports - uint16_t nb_ports = rte_eth_dev_count_avail(); - printf("\\nNumber of available ethernet ports: %u\\n", nb_ports); - - // Print info for each port - uint16_t port_id; - RTE_ETH_FOREACH_DEV(port_id) { - print_device_info(port_id); - } - - printf("\\nProceeding with runtime configuration...\\n"); - print_runtime_config(); - - printf("\\nCleaning up...\\n"); - rte_eal_cleanup(); - return 0; -} -``` -Compile command: `gcc -o hello hello.c $(pkg-config --cflags libdpdk) $(pkg-config --libs libdpdk) -DRTE_LOG_LEVEL=RTE_LOG_DEBUG` - -Launch command: `sudo gdb --args ./hello -l 0 -n 1 --proc-type=auto -m 256 --iova-mode=pa --log-level=8 --match-allocations -a 0000:01:00.0`""" diff --git a/gitlab/issues/target_i386/host_x86/accel_WHPX/2287.toml b/gitlab/issues/target_i386/host_x86/accel_WHPX/2287.toml deleted file mode 100644 index b68617e36..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_WHPX/2287.toml +++ /dev/null @@ -1,37 +0,0 @@ -id = 2287 -title = "whpx, on booting win98, qemu crashes with Failed to emulate PortIO access with EmulatorReturnStatus: 2" -state = "opened" -created_at = "2024-04-16T13:57:51.843Z" -closed_at = "n/a" -labels = ["accel: WHPX", "host: x86", "kind::Bug", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2287" -host-os = "Windows 10 22H2" -host-arch = "x86-64" -qemu-version = "QEMU emulator version 8.2.91 (v9.0.0-rc1-12050-gb494cb57ce)" -guest-os = "Win98SE" -guest-arch = "x86_64" -description = """Q) What is the correct command line arguments to boot win98se with ```accel whpx``` - -The above given command line crashes partway through the win98se boot process before the desktop shows up -``` -Windows Hypervisor Platform accelerator is operational -C:\\vol\\scoop_01\\SCOOPG\\apps\\qemu\\current\\qemu-system-x86_64.exe: warning: GLib-GIO: Failed to open application manifest `C:\\Windows\\SystemApps\\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\\AppxManifest.xml' for package #34 (`Microsoft.MicrosoftEdge_44.19041.1266.0_neutral__8wekyb3d8bbwe'): error code 0x2 -C:\\vol\\scoop_01\\SCOOPG\\apps\\qemu\\current\\qemu-system-x86_64.exe: WHPX: Failed to emulate PortIO access with EmulatorReturnStatus: 2 -C:\\vol\\scoop_01\\SCOOPG\\apps\\qemu\\current\\qemu-system-x86_64.exe: WHPX: Failed to exec a virtual processor -```""" -reproduce = """1. Finish a complete win98 install using ```-machine type=pc,accel=tcg -cpu qemu64``` - ```qemu-system-x86_64 -machine type=pc,accel=tcg -cpu qemu64 -smp "sockets=1,cores=1,threads=1" -m 512 -nodefaults -bios bios-256k.bin -rtc base=localtime -display sdl,gl=on -device VGA,vgamem_mb=128 -audiodev dsound,id=snd1 -device adlib,audiodev=snd1 -audiodev dsound,id=snd2 -device ac97,audiodev=snd2 -boot c -drive index=0,if=ide,media=disk,format=vhdx,file="F:\\Win98m40_sys.vhdx" -drive index=1,if=ide,media=disk,format=vhdx,file="F:\\Win98m40_data_01.vhdx" -drive index=3,if=ide,media=disk,format=vhdx,file="F:\\Win98m40_data_02.vhdx"``` - With all guestos-win98-drivers installed the win98 seems to work satisfactorily. - Using vga driver from https://github.com/JHRobotics/vmdisp9x/releases -2. now change processor to ```-cpu core2duo```, it boots . This does not seem to matter, bug exists even with qemu64 -3. now change accel to ```-machine type=pc,accel=whpx ```, qemu crashes partway into boot before bringing up desktop. - with or without ```kernel-irqchip=off``` does not matter - with or without cpu arguments ```,hv-relaxed,hv-vapic,hv-spinlocks=0x1fff,hv-time``` also does not matter -4. Setting back to ```-machine type=pc,accel=tcg -cpu core2duo``` restores bootable win98se.""" -additional = """- [target/i386/whpx/whpx-all.c#L920](https://gitlab.com/qemu-project/qemu/-/blob/a12214d1c4204d2f51d8724993b8dfcf50dd7d94/target/i386/whpx/whpx-all.c#L920) -- The part of the OS bootsequence, which includes the Win98/DOS boot menu, scandisk, etc. works fine. Its possible to boot to DOS mode and run DOS commands. The crash happens when into the win.com Win98SE boot sequence just before it can bring up the GUI desktop. -- qemu crashes even if in the win98/DOS bootmenu, selection is made to boot into ```safe-mode```, which is supposed to boot a vanilla 16-color VGA desktop loading minimal drivers. As before, crash happens before GUI desktop is loaded. -- 20220623 Learn.Microsoft WHvEmulatorTryIoEmulation and WHvEmulatorTryMmioEmulation - https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatortryemulation -- 20220426 Learn.Microsoft WHV_EMULATOR_STATUS - https://learn.microsoft.com/en-us/virtualization/api/hypervisor-instruction-emulator/funcs/whvemulatorstatus""" diff --git a/gitlab/issues/target_i386/host_x86/accel_WHPX/2887.toml b/gitlab/issues/target_i386/host_x86/accel_WHPX/2887.toml deleted file mode 100644 index 1e70c93b5..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_WHPX/2887.toml +++ /dev/null @@ -1,15 +0,0 @@ -id = 2887 -title = "Qemu VM WHPX Startup Error with OVMF Code and VARS UEFI Files" -state = "closed" -created_at = "2025-03-29T06:30:59.441Z" -closed_at = "2025-04-01T19:22:14.630Z" -labels = ["accel: WHPX", "host: x86", "target: i386"] -url = "https://gitlab.com/qemu-project/qemu/-/issues/2887" -host-os = "n/a" -host-arch = "n/a" -qemu-version = "n/a" -guest-os = "n/a" -guest-arch = "n/a" -description = "n/a" -reproduce = "n/a" -additional = "n/a" diff --git a/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml b/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml deleted file mode 100644 index 783fd1a6d..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_missing/1910.toml +++ /dev/null @@ -1,70 +0,0 @@ -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 deleted file mode 100644 index 8e795c3bd..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_missing/1926.toml +++ /dev/null @@ -1,32 +0,0 @@ -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 deleted file mode 100644 index 93bc8a1f8..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_missing/1946.toml +++ /dev/null @@ -1,38 +0,0 @@ -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.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 deleted file mode 100644 index 67d66438d..000000000 --- a/gitlab/issues/target_i386/host_x86/accel_missing/2608.toml +++ /dev/null @@ -1,19 +0,0 @@ -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" |