1 files changed, 47 insertions, 0 deletions
diff --git a/results/classifier/118/boot/997 b/results/classifier/118/boot/997
new file mode 100644
index 000000000..adbb05c80
--- /dev/null
+++ b/results/classifier/118/boot/997
@@ -0,0 +1,47 @@
+boot: 0.873
+virtual: 0.856
+performance: 0.853
+device: 0.846
+architecture: 0.783
+graphic: 0.705
+hypervisor: 0.696
+semantic: 0.678
+vnc: 0.662
+PID: 0.619
+ppc: 0.579
+network: 0.568
+permissions: 0.561
+peripherals: 0.556
+kernel: 0.530
+risc-v: 0.528
+TCG: 0.524
+files: 0.485
+register: 0.477
+x86: 0.469
+VMM: 0.465
+arm: 0.448
+debug: 0.448
+mistranslation: 0.425
+i386: 0.402
+socket: 0.372
+user-level: 0.322
+assembly: 0.304
+KVM: 0.204
+
+Iothread is stuck at 100% CPU usage with virtio-scsi on QEMU 7.0.0
+Description of problem:
+Starting with QEMU 7.0.0, the iothread associated attached to a virtio-scsi controller is stuck at 100% CPU usage. Bisected to: https://gitlab.com/qemu-project/qemu/-/commit/826cc32423db2a99d184dbf4f507c737d7e7a4ae
+
+- Works as expected without the iothread
+- No issue with virtio-blk + iothread
+- Same behavior regardless of io=threads/native/io_uring
+- Same behavior with default vs increased queue count
+- The issue is triggered when the guest OS initializes the virtio driver
+Steps to reproduce:
+1. Add virtio-scsi controller with iothread
+2. Boot VM
+3. Check per-thread CPU usage such as in htop
+Additional information:
+[fedora.log](/uploads/776fbf8e5b823d0ab326946684ef9022/fedora.log)
+
+[fedora.xml](/uploads/54879e5adfb227ddef79d382e86fc608/fedora.xml)