add 18th iteration of classifier

author: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:00 +0000
committer: Christian Krinitsin <mail@krinitsin.com> 2025-06-16 16:59:33 +0000
commit: 9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree: b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/KVM
parent: b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download: qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz
qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip
79 files changed, 6675 insertions, 0 deletions
diff --git a/results/classifier/118/KVM/1002 b/results/classifier/118/KVM/1002
new file mode 100644
index 000000000..e013424c7
--- /dev/null
+++ b/results/classifier/118/KVM/1002
@@ -0,0 +1,31 @@
+architecture: 0.959
+KVM: 0.953
+performance: 0.824
+device: 0.785
+network: 0.681
+debug: 0.633
+graphic: 0.617
+hypervisor: 0.403
+arm: 0.362
+socket: 0.304
+virtual: 0.290
+boot: 0.227
+semantic: 0.164
+files: 0.160
+register: 0.146
+permissions: 0.117
+PID: 0.113
+peripherals: 0.079
+mistranslation: 0.071
+vnc: 0.067
+ppc: 0.064
+assembly: 0.053
+user-level: 0.052
+VMM: 0.030
+TCG: 0.024
+risc-v: 0.015
+kernel: 0.014
+x86: 0.003
+i386: 0.001
+
+qemu-system-aarch64: Synchronous Exception with smp > 1 (on M1 running Asahi Linux with KVM)
diff --git a/results/classifier/118/KVM/1009 b/results/classifier/118/KVM/1009
new file mode 100644
index 000000000..86bf1461c
--- /dev/null
+++ b/results/classifier/118/KVM/1009
@@ -0,0 +1,53 @@
+KVM: 0.990
+network: 0.984
+virtual: 0.983
+graphic: 0.959
+performance: 0.951
+ppc: 0.941
+VMM: 0.927
+kernel: 0.921
+architecture: 0.913
+PID: 0.892
+device: 0.888
+peripherals: 0.875
+hypervisor: 0.863
+user-level: 0.842
+debug: 0.839
+boot: 0.824
+semantic: 0.814
+register: 0.796
+assembly: 0.794
+mistranslation: 0.791
+permissions: 0.781
+x86: 0.776
+socket: 0.760
+vnc: 0.759
+files: 0.751
+arm: 0.670
+risc-v: 0.648
+i386: 0.637
+TCG: 0.593
+
+Nested KVM Networking Issue (OpenStack)
+Description of problem:
+Hi, 
+
+Inside openstack i have an instance of Ubuntu 20.04 and i have installed KVM ( using virt-manager ) to setup a Virtual Machine ... i have done that and i created a VM of ubuntu 20.04 inside the Openstack Instance but there are networking issue while i set the default parameter as setting up the VM ( i mean the networking is as default to NAT ) , So when the VM is up and running the PING to 8.8.8.8 is available and also ping to google.com is also valid which shows that the DNS is correctly working ... but there is not connectivity with packages while i do sudo apt update, it will not get any package update and also the wget to google.com is shows that its connected to it but it wont able to download!!! the same happen with curl to any other websites...
+
+
+I'm confirming that the openstack instance has full access to the internet including ping and wget , .... but the VM is not working correctly!
+
+P.S. I have set the ip forwarding, Iptables , ... also disabled firewals but notting changed!!
+
+
+Would you please fix this ?
+Steps to reproduce:
+1. creating an openstack instance from ubuntu 20.04 server image
+2. updating and upgrading packages setting ip forwarding to 1 ( Enabled), firewall
+3. and kernel to 5.13.0.40 and installing virt-manager then reboot 
+3. creating a VM with default KVM networking ( NAT ) using ubuntu 20.04 server image
+4. trying ping, wget, curl , ...
+
+
+Thanks
+Best regards
diff --git a/results/classifier/118/KVM/1012 b/results/classifier/118/KVM/1012
new file mode 100644
index 000000000..2c5b26b1e
--- /dev/null
+++ b/results/classifier/118/KVM/1012
@@ -0,0 +1,71 @@
+KVM: 0.858
+permissions: 0.849
+hypervisor: 0.847
+virtual: 0.843
+graphic: 0.842
+peripherals: 0.824
+user-level: 0.810
+performance: 0.806
+debug: 0.805
+network: 0.804
+vnc: 0.801
+TCG: 0.788
+x86: 0.788
+ppc: 0.785
+mistranslation: 0.783
+register: 0.781
+risc-v: 0.781
+device: 0.774
+architecture: 0.754
+files: 0.743
+boot: 0.739
+arm: 0.730
+semantic: 0.729
+VMM: 0.719
+assembly: 0.693
+kernel: 0.680
+socket: 0.678
+i386: 0.667
+PID: 0.645
+
+9p: newfstatat behaves differently than fstat causing ENOENT for here-documents
+Description of problem:
+After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error.
+Steps to reproduce:
+1. I have file `a` with:
+```
+cat <<EOF
+x
+EOF
+```
+2. User visible error inside VM:
+```
+root@x86_64:~# grep 9p /proc/mounts
+/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0
+root@x86_64:~# bash a
+cat: -: No such file or directory
+```
+3. `strace -fyv bash a` shows:
+```
+  [pid   291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */,
+st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0
+  [pid   291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
+  [pid   291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5
+  [pid   291] write(2</dev/ttyS0>, "-", 1-) = 1
+  [pid   291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27
+  [pid   291] write(2</dev/ttyS0>, "\n", 1
+```
+Additional information:
+In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows:
+```
+  [pid   283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204,
+st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0
+  [pid   283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */,
+st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0
+  [pid   283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
+  [pid   283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000
+  [pid   283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2
+  [pid   283] write(1</dev/ttyS0>, "x\n", 2x
+```
+
+So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently.
diff --git a/results/classifier/118/KVM/1045 b/results/classifier/118/KVM/1045
new file mode 100644
index 000000000..c4a9d31ac
--- /dev/null
+++ b/results/classifier/118/KVM/1045
@@ -0,0 +1,56 @@
+KVM: 0.818
+mistranslation: 0.788
+virtual: 0.774
+graphic: 0.763
+hypervisor: 0.744
+debug: 0.738
+semantic: 0.695
+i386: 0.610
+device: 0.570
+ppc: 0.550
+kernel: 0.516
+performance: 0.488
+x86: 0.460
+peripherals: 0.437
+architecture: 0.433
+vnc: 0.431
+socket: 0.424
+network: 0.421
+PID: 0.404
+boot: 0.374
+permissions: 0.365
+risc-v: 0.348
+register: 0.340
+files: 0.340
+VMM: 0.327
+arm: 0.281
+TCG: 0.234
+user-level: 0.233
+assembly: 0.122
+
+When a break point is set, nested virtualization sees "kvm_queue_exception: Assertion `!env->exception_has_payload' failed."
+Description of problem:
+I am debugging XMHF and LHV using QEMU + KVM. I found that if I set a break point using GDB, QEMU will crash when LHV is booting. The message is
+```
+qemu-system-i386: ../../../target/i386/kvm/kvm.c:678: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+```
+
+The address of the break point is arbitrary. The break point does not need to hit. So I chose 0 as the address in this bug report.
+Steps to reproduce:
+1. Start QEMU using `qemu-system-i386 -m 512M -gdb tcp::1234 -smp 2 -cpu Haswell,vmx=yes -enable-kvm -serial stdio -drive media=disk,file=1.img,index=1 -drive media=disk,file=2.img,index=2 -S`
+2. In another shell, start GDB using `gdb --ex 'target remote :::1234' --ex 'hb *0' --ex c`
+3. See many serial output lines. The tail of the output is
+    ```
+    CPU #0: vcpu_vaddr_ptr=0x01e06080, esp=0x01e11000
+    CPU #1: vcpu_vaddr_ptr=0x01e06540, esp=0x01e15000
+    BSP(0x00): Rallying APs...
+    BSP(0x00): APs ready, doing DRTM...
+    LAPIC base and status=0xfee00900
+    Sending INIT IPI to all APs...
+    ```
+4. See assertion error in QEMU
+    ```
+    qemu-system-i386: ../target/i386/kvm/kvm.c:645: kvm_queue_exception: Assertion `!env->exception_has_payload' failed.
+    ```
+Additional information:
+This bug was first incorrectly filed in KVM's bug tracker at <https://bugzilla.kernel.org/show_bug.cgi?id=216002>.
diff --git a/results/classifier/118/KVM/1073952 b/results/classifier/118/KVM/1073952
new file mode 100644
index 000000000..de0e6db28
--- /dev/null
+++ b/results/classifier/118/KVM/1073952
@@ -0,0 +1,64 @@
+KVM: 0.943
+device: 0.893
+performance: 0.807
+files: 0.767
+graphic: 0.675
+vnc: 0.663
+boot: 0.652
+semantic: 0.617
+register: 0.551
+network: 0.550
+user-level: 0.550
+peripherals: 0.493
+socket: 0.485
+ppc: 0.467
+x86: 0.465
+kernel: 0.430
+debug: 0.419
+PID: 0.404
+virtual: 0.369
+permissions: 0.359
+risc-v: 0.339
+hypervisor: 0.324
+mistranslation: 0.302
+i386: 0.293
+architecture: 0.270
+arm: 0.232
+TCG: 0.226
+VMM: 0.213
+assembly: 0.180
+
+data sent to serial interface gets truncated after 64kb
+
+When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear.
+
+I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5).
+
+You can reproduce it as follows:
+
+1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. 
+
+     $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432
+     or
+     $ cat <TESTFILE> | nc -l 127.0.0.1 65432
+
+2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux.
+
+     $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432
+
+3. When the testsystem is booted, read from the serial device and write it to a file.
+
+     $ dd if=/dev/ttyS0 of=/tmp/testFile
+     or
+     $ cat /dev/ttyS0 > /tmp/testFile
+
+
+The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs.
+
+I hope my explanation is exactly enough for you to reproduce it.
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/110 b/results/classifier/118/KVM/110
new file mode 100644
index 000000000..08c47650a
--- /dev/null
+++ b/results/classifier/118/KVM/110
@@ -0,0 +1,31 @@
+KVM: 0.996
+virtual: 0.984
+peripherals: 0.970
+device: 0.910
+hypervisor: 0.791
+network: 0.763
+architecture: 0.739
+performance: 0.706
+arm: 0.523
+risc-v: 0.492
+debug: 0.435
+PID: 0.434
+register: 0.425
+graphic: 0.382
+VMM: 0.344
+boot: 0.331
+semantic: 0.301
+ppc: 0.276
+socket: 0.260
+permissions: 0.250
+vnc: 0.245
+TCG: 0.174
+files: 0.171
+i386: 0.160
+mistranslation: 0.099
+assembly: 0.069
+user-level: 0.067
+kernel: 0.060
+x86: 0.058
+
+KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on
diff --git a/results/classifier/118/KVM/1136 b/results/classifier/118/KVM/1136
new file mode 100644
index 000000000..4bee36169
--- /dev/null
+++ b/results/classifier/118/KVM/1136
@@ -0,0 +1,31 @@
+KVM: 0.995
+hypervisor: 0.972
+ppc: 0.857
+architecture: 0.812
+device: 0.754
+performance: 0.687
+network: 0.667
+virtual: 0.645
+arm: 0.501
+graphic: 0.442
+files: 0.417
+debug: 0.412
+register: 0.404
+peripherals: 0.350
+semantic: 0.275
+boot: 0.271
+permissions: 0.249
+vnc: 0.233
+PID: 0.211
+mistranslation: 0.157
+socket: 0.146
+VMM: 0.145
+TCG: 0.093
+user-level: 0.058
+assembly: 0.045
+kernel: 0.024
+risc-v: 0.015
+x86: 0.010
+i386: 0.005
+
+qemu-system-ppc64: KVM HPT guest sometimes fails to migrate
diff --git a/results/classifier/118/KVM/1156632 b/results/classifier/118/KVM/1156632
new file mode 100644
index 000000000..df1442bc7
--- /dev/null
+++ b/results/classifier/118/KVM/1156632
@@ -0,0 +1,66 @@
+KVM: 0.966
+socket: 0.940
+performance: 0.830
+device: 0.806
+semantic: 0.731
+graphic: 0.726
+debug: 0.726
+ppc: 0.718
+kernel: 0.649
+user-level: 0.575
+network: 0.541
+architecture: 0.500
+x86: 0.482
+virtual: 0.479
+arm: 0.458
+permissions: 0.426
+hypervisor: 0.417
+mistranslation: 0.401
+i386: 0.396
+vnc: 0.391
+register: 0.382
+peripherals: 0.364
+boot: 0.326
+risc-v: 0.324
+PID: 0.310
+assembly: 0.291
+files: 0.195
+TCG: 0.175
+VMM: 0.172
+
+not receiving RESET event after system_reset command causes QMP connection to die
+
+I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection:
+
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) close socket
+7) Connect to socket -> connection refused
+
+However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events:
+1) Connect to QMP 
+2) Sent qmp_capabilities
+3) Receive reply
+4) Send system_reset
+5) Receive reply
+6) Receive reply (is a RESET event)
+7) Receive reply (is a RESET event)
+8) close socket
+9) Connect to socket -> ok
+
+I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU?
+
+For what its worth, i'm using Ubuntu 12.10:
+kvm --version
+QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard
+
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1198 b/results/classifier/118/KVM/1198
new file mode 100644
index 000000000..b3ab0ef0f
--- /dev/null
+++ b/results/classifier/118/KVM/1198
@@ -0,0 +1,83 @@
+KVM: 0.907
+peripherals: 0.892
+x86: 0.878
+risc-v: 0.867
+graphic: 0.859
+register: 0.854
+semantic: 0.850
+device: 0.833
+ppc: 0.828
+debug: 0.819
+arm: 0.816
+performance: 0.808
+permissions: 0.807
+VMM: 0.804
+mistranslation: 0.798
+TCG: 0.792
+assembly: 0.777
+i386: 0.777
+user-level: 0.770
+hypervisor: 0.763
+PID: 0.746
+architecture: 0.746
+kernel: 0.727
+files: 0.727
+vnc: 0.724
+boot: 0.724
+virtual: 0.696
+socket: 0.665
+network: 0.590
+
+Windows 11 Guest keeps crashing with abort in cpu_asidx_from_attrs
+Steps to reproduce:
+1. Create Windows 11 guest, SWTPM, SECBOOT (haven't tested without since this is not an option for installing Windows 11)
+2. Use OS
+3. Will eventually crash. Have tried across multiple kernels 5.17, 5.18, 5.19
+Additional information:
+```
+
+               Stack trace of thread 76223:
+                #0  0x00007f24072d44dc n/a (libc.so.6 + 0x884dc)
+                #1  0x00007f2407284998 raise (libc.so.6 + 0x38998)
+                #2  0x00007f240726e53d abort (libc.so.6 + 0x2253d)
+                #3  0x00007f240726e45c n/a (libc.so.6 + 0x2245c)
+                #4  0x00007f240727d4c6 __assert_fail (libc.so.6 + 0x314c6)
+                #5  0x0000555681a35101 cpu_asidx_from_attrs (qemu-system-x86_64 + 0x572101)
+                #6  0x0000555681c6531e cpu_memory_rw_debug (qemu-system-x86_64 + 0x7a231e)
+                #7  0x0000555681bfb54a x86_cpu_dump_state (qemu-system-x86_64 + 0x73854a)
+                #8  0x0000555681d84a65 kvm_cpu_exec (qemu-system-x86_64 + 0x8c1a65)
+                #9  0x0000555681d85e48 kvm_vcpu_thread_fn (qemu-system-x86_64 + 0x8c2e48)
+                #10 0x0000555681fed0a8 qemu_thread_start (qemu-system-x86_64 + 0xb2a0a8)
+                #11 0x00007f24072d278d n/a (libc.so.6 + 0x8678d)
+                #12 0x00007f24073538e4 __clone (libc.so.6 + 0x1078e4)
+```
+
+
+```
+KVM: entry failed, hardware error 0x80000021
+
+If you're running a guest on an Intel machine without unrestricted mode
+support, the failure can be most likely due to the guest entering an invalid
+state for Intel VT. For example, the guest maybe running in big real mode
+which is not supported on less recent Intel processors.
+
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=04c6d3e0
+ESI=12af7eb0 EDI=9e55d420 EBP=821b5aa0 ESP=10db0fb0
+EIP=00008000 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
+ES =0000 00000000 ffffffff 00809300
+CS =b500 7ffb5000 ffffffff 00809300
+SS =0000 00000000 ffffffff 00809300
+DS =0000 00000000 ffffffff 00809300
+FS =0000 00000000 ffffffff 00809300
+GS =0000 00000000 ffffffff 00809300
+LDT=0000 00000000 000fffff 00000000
+TR =0040 10d97000 00000067 00008b00
+GDT=     10d98fb0 00000057
+IDT=     00000000 00000000
+CR0=00050032 CR2=f80ff80c CR3=e47e7000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=qemu-system-x86_64: ../qemu-7.0.0/hw/core/cpu-sysemu.c:77: cpu_asidx_from_attrs: Assertion `ret < cpu->num_ases && ret >= 0' failed.
+2022-09-06 14:48:15.392+0000: shutting down, reason=crashed
+```
diff --git a/results/classifier/118/KVM/1288259 b/results/classifier/118/KVM/1288259
new file mode 100644
index 000000000..d9ef0982a
--- /dev/null
+++ b/results/classifier/118/KVM/1288259
@@ -0,0 +1,82 @@
+KVM: 0.863
+virtual: 0.650
+graphic: 0.620
+mistranslation: 0.495
+hypervisor: 0.487
+device: 0.439
+VMM: 0.385
+performance: 0.348
+kernel: 0.342
+socket: 0.341
+architecture: 0.330
+vnc: 0.324
+ppc: 0.299
+PID: 0.297
+peripherals: 0.284
+assembly: 0.276
+debug: 0.275
+risc-v: 0.267
+semantic: 0.261
+user-level: 0.243
+network: 0.223
+register: 0.199
+arm: 0.182
+permissions: 0.181
+boot: 0.179
+TCG: 0.169
+i386: 0.163
+x86: 0.160
+files: 0.115
+
+KVM vms are paused and cannot be deleted due to hardware error 0x0
+
+Upon creation of instances via OpenStack nova api instances got stuck in spawning state. Then, after trying to delete instances they got stuck in deleting state. After investigation the following error was found:
+
+KVM: entry failed, hardware error 0x0
+EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000623
+ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
+EIP=0000fff0 EFL=00000002 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
+ES =0000 00000000 0000ffff 00009300
+CS =f000 000f0000 0000ffff 0000f300
+SS =0000 00000000 0000ffff 0000f300
+DS =0000 00000000 0000ffff 00009300
+FS =0000 00000000 0000ffff 00009300
+GS =0000 00000000 0000ffff 00009300
+LDT=0000 00000000 0000ffff 00008200
+TR =0000 00000000 0000ffff 00008b00
+GDT=     00000000 0000ffff
+IDT=     00000000 0000ffff
+CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=28 95 66 ba 01 4a 03 00 66 89 d8 66 5b 66 5e e9 15 79 66 c3 <ea> 5b e0 00 f0 30 36 2f 32 33 2f 39 39 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+All instances were in paused state:
+root@node-7:~# virsh list
+setlocale: No such file or directory
+ Id    Name                           State
+----------------------------------------------------
+ 4     instance-00000004              paused
+ 5     instance-00000005              paused
+ 6     instance-00000006              paused
+ 7     instance-00000007              paused
+ 8     instance-00000008              paused
+ 9     instance-00000009              paused
+
+The only way to delete VM is to reset it and then resume it. After this, VM is deleted properly. 
+OpenStack version: Havana on Ubuntu 12.04
+KVM version: QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu7.12.10, Debian), Copyright (c) 2003-2008 Fabrice Bellard
+
+
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Thanks Thomas for reassigning this to Ubuntu.
+That would look like an issue with the KVM HW support, but is too long ago for anything reasonable to be done.
+
+If this still is an issue please describe what you encounter and add current logs.
+Marking incomplete for now.
+
+[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1312668 b/results/classifier/118/KVM/1312668
new file mode 100644
index 000000000..81098fabd
--- /dev/null
+++ b/results/classifier/118/KVM/1312668
@@ -0,0 +1,88 @@
+x86: 0.970
+KVM: 0.936
+architecture: 0.931
+performance: 0.915
+hypervisor: 0.910
+kernel: 0.909
+device: 0.908
+i386: 0.907
+ppc: 0.898
+graphic: 0.873
+socket: 0.829
+register: 0.815
+files: 0.813
+risc-v: 0.810
+boot: 0.807
+VMM: 0.793
+PID: 0.787
+peripherals: 0.762
+vnc: 0.756
+mistranslation: 0.732
+virtual: 0.703
+permissions: 0.693
+arm: 0.681
+debug: 0.668
+network: 0.638
+semantic: 0.623
+user-level: 0.582
+TCG: 0.574
+assembly: 0.343
+
+x86 cpu nx feature: guest reboots  after migrate exec
+
+Using instruction on 
+http://www.linux-kvm.org/page/Migration
+I save VM state to external file and try load it, but VM starts, shows saved screen and reboots immediatly.
+
+Cmdline for vm state saving:
+
+$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm  -m 512 -hda image.raw -vga std -net none  -M pc -monitor stdio -cpu SandyBridge 
+(or  -cpu "n270" , or "kvm32,+sse2,+pae,+nx")
+
+Monitor cmd:
+(qemu) stop
+(qemu) migrate_set_speed 4095m
+(qemu) migrate "exec:gzip -c > STATEFILE.gz"  
+(qemu) q
+
+Cmdline for vm state loading:
+
+$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm  -m 512 -hda image.raw -vga std -net none  -M pc -monitor stdio -cpu SandyBridge -incoming "exec: gzip -c -d STATEFILE.gz"
+(or  -cpu "n270" , or "kvm32,+sse2,+pae,+nx")
+
+If I do the same without NX cpu feature (-cpu option "n270,-nx" / "SandyBridge,-nx" / "kvm32,+pae,+sse2") or on qemu-system-x86_64, VM save/load works correctly. 
+
+Log kvm-all.c, DEBUG_KVM=y:
+
+QEMU 2.0.0 monitor - type 'help' for more information
+(qemu) kvm_init_vcpu
+...handle_io.../...handle_mmio...
+kvm_cpu_exec()
+shutdown
+kvm_cpu_exec()
+interrupt exit requested
+io window exit
+kvm_cpu_exec()
+
+Host:
+
+ $ lsb_release -rd
+ Description:	Ubuntu 12.04.4 LTS
+ Release:	12.04
+
+ $ uname -a
+ Linux <username> 3.8.0-38-generic #56~precise1 SMP Tue Apr 22 12:46:44 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux
+
+Guest:
+ 1. Ubuntu 12.04 32bit 
+ 2. WIndows 8 32bit
+
+Qemu: v2.0.0
+commit a9e8aeb3755bccb7b51174adcf4a3fc427e0d147
+Author: Peter Maydell <email address hidden>
+Date:   Thu Apr 17 13:41:45 2014 +0100
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1344 b/results/classifier/118/KVM/1344
new file mode 100644
index 000000000..1763e6b4d
--- /dev/null
+++ b/results/classifier/118/KVM/1344
@@ -0,0 +1,31 @@
+KVM: 0.977
+kernel: 0.911
+virtual: 0.793
+debug: 0.682
+device: 0.674
+graphic: 0.650
+semantic: 0.648
+architecture: 0.609
+hypervisor: 0.596
+mistranslation: 0.550
+boot: 0.393
+performance: 0.348
+arm: 0.342
+ppc: 0.301
+permissions: 0.248
+risc-v: 0.225
+PID: 0.193
+i386: 0.188
+register: 0.175
+x86: 0.151
+vnc: 0.147
+network: 0.119
+peripherals: 0.074
+user-level: 0.069
+TCG: 0.033
+files: 0.027
+socket: 0.025
+VMM: 0.008
+assembly: 0.005
+
+custom kernel give me KVM internal error. Suberror: 4
diff --git a/results/classifier/118/KVM/1353149 b/results/classifier/118/KVM/1353149
new file mode 100644
index 000000000..3bbc50f49
--- /dev/null
+++ b/results/classifier/118/KVM/1353149
@@ -0,0 +1,69 @@
+KVM: 0.969
+mistranslation: 0.956
+x86: 0.953
+performance: 0.918
+socket: 0.898
+semantic: 0.896
+i386: 0.893
+virtual: 0.879
+hypervisor: 0.825
+architecture: 0.821
+ppc: 0.805
+PID: 0.711
+user-level: 0.702
+kernel: 0.695
+graphic: 0.680
+peripherals: 0.669
+debug: 0.665
+device: 0.657
+register: 0.655
+permissions: 0.597
+VMM: 0.596
+vnc: 0.563
+boot: 0.553
+files: 0.532
+network: 0.515
+risc-v: 0.463
+TCG: 0.398
+assembly: 0.393
+arm: 0.387
+
+qemu 2.1.0 fails to start if number of cores is greater than 1.
+
+qemu (kvm) 2.1.0 (built from sources) fails to start if number of cores is greater than 1.
+
+relevant part of commandline arguments:
+
+/usr/bin/qemu-system-x86_64 -name test3 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Westmere -m 4096 -realtime mlock=off -smp 1,maxcpus=4,sockets=1,cores=4,threads=1
+
+the error reported is:
+
+qemu-system-x86_64: /home/asavah/pkgbuild/qemu-2.1.0/hw/i386/smbios.c:825: smbios_get_tables: Assertion `smbios_smp_sockets >= 1' failed.
+2014-08-05 21:45:35.825+0000: shutting down
+
+however setting 4 sockets with 1 core each allows me to start the machine just fine.
+
+the system is debian wheezy
+Linux hostname 3.16.0-hostname2 #2 SMP Mon Aug 4 17:02:16 EEST 2014 x86_64 GNU/Linux
+
+libvirt 1.2.7 (built from sources)
+
+-smp 1,maxcpus=4,sockets=1,cores=4,threads=1
+
+should be
+
+-smp 4,maxcpus=4,sockets=1,cores=4,threads=1
+
+although more human-friendly error is more appropriate there (better than a silent fallback to either 1- or 4- core topology)
+
+I forgot to mention that VM was created and managed remotely via virt-manager 0.9.5 from another host.
+I used custom cpu topology.
+
+however this config worked fine on qemu 2.0.0 with virt-manager 0.9.5
+
+just tried virt-manager 1.0.1 - it creates the proper argument -smp 4,maxcpus=4,sockets=1,cores=4,threads=1
+
+so this was a virt-manager bug already fixed upstream.
+
+this bug can be closed :)
+
diff --git a/results/classifier/118/KVM/1383857 b/results/classifier/118/KVM/1383857
new file mode 100644
index 000000000..2a01c6929
--- /dev/null
+++ b/results/classifier/118/KVM/1383857
@@ -0,0 +1,228 @@
+KVM: 0.888
+virtual: 0.788
+device: 0.787
+user-level: 0.779
+VMM: 0.773
+peripherals: 0.754
+vnc: 0.752
+hypervisor: 0.730
+register: 0.730
+TCG: 0.730
+files: 0.717
+boot: 0.715
+ppc: 0.711
+architecture: 0.711
+arm: 0.700
+assembly: 0.694
+permissions: 0.691
+semantic: 0.688
+network: 0.687
+graphic: 0.678
+risc-v: 0.676
+debug: 0.675
+mistranslation: 0.674
+kernel: 0.666
+performance: 0.657
+socket: 0.644
+x86: 0.635
+PID: 0.623
+i386: 0.520
+
+aarch64: virtio disks don't show up in guest (neither blk nor scsi)
+
+kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
+qemu from git today
+
+When I create a guest with virtio-scsi disks, they don't show up inside the guest.
+Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
+no messages about disks, and of course nothing else works.
+
+Really long command line (generated by libvirt):
+
+HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none TMPDIR=/home/rjones/d/libguestfs/tmp /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-reboot -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000 no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-serial0 -usb -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -serial unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -msg timestamp=on
+
+There are no kernel messages about the disks, they just are not seen.
+
+Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
+qemu bug, but I've no idea where to report those.
+
+On 21 October 2014 20:07, Richard Jones <email address hidden> wrote:
+> Public bug reported:
+>
+> kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
+> qemu from git today
+>
+> When I create a guest with virtio-scsi disks, they don't show up inside the guest.
+> Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
+> no messages about disks, and of course nothing else works.
+
+> There are no kernel messages about the disks, they just are not seen.
+>
+> Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
+> qemu bug, but I've no idea where to report those.
+
+Yeah, "regressed with this newer kernel" sounds more like a kernel
+bug than a QEMU bug to me, especially if all the other virt devices
+still work.
+
+-- PMM
+
+
+I have now also tried virtio-blk and that doesn't work either.  Same symptoms: no log messages at all (even with ignore_loglevel), and no disks appear.
+
+> Yeah, "regressed with this newer kernel" sounds more like a kernel
+> bug than a QEMU bug to me, especially if all the other virt devices
+> still work.
+
+It seems like no virtio drivers work, but it's very hard to tell when your guest has no disks and therefore no operating system.  How can I debug this further?
+
+On 21 October 2014 22:15, Richard Jones <email address hidden> wrote:
+> I have now also tried virtio-blk and that doesn't work either.  Same
+> symptoms: no log messages at all (even with ignore_loglevel), and no
+> disks appear.
+>
+>> Yeah, "regressed with this newer kernel" sounds more like a kernel
+>> bug than a QEMU bug to me, especially if all the other virt devices
+>> still work.
+>
+> It seems like no virtio drivers work, but it's very hard to tell when
+> your guest has no disks and therefore no operating system.  How can I
+> debug this further?
+
+Oh. I assumed from the fact your commandline had other virtio
+devices and you were only complaining about virtio-scsi that it
+was a single-backend issue.
+
+Suggestions:
+ * bisect the kernel to find out when it broke
+ * add a bunch of debug printks to the kernel to find out why
+   it's not finding the disks. The logging here is terrible IMHO:
+   the kernel usually detects a specific problem and then throws
+   all this info away in favour of just silently deciding there's
+   no hardware there
+
+thanks
+-- PMM
+
+
+On 21 October 2014 22:33, Peter Maydell <email address hidden> wrote:
+> Suggestions:
+
+...you might also try asking on <email address hidden>, which
+is where the KVM/ARM kernel devs hang out, to see if somebody
+else has seen this.
+
+-- PMM
+
+
+Finally finished the git bisect (of the guest kernel, not qemu):
+
+421520ba98290a73b35b7644e877a48f18e06004 is the first bad commit
+commit 421520ba98290a73b35b7644e877a48f18e06004
+Author: Yalin Wang <email address hidden>
+Date:   Fri Sep 26 03:07:09 2014 +0100
+
+    ARM: 8167/1: extend the reserved memory for initrd to be page aligned
+    
+    This patch extends the start and end address of initrd to be page aligned,
+    so that we can free all memory including the un-page aligned head or tail
+    page of initrd, if the start or end address of initrd are not page
+    aligned, the page can't be freed by free_initrd_mem() function.
+    
+    Signed-off-by: Yalin Wang <email address hidden>
+    Acked-by: Catalin Marinas <email address hidden>
+    Signed-off-by: Russell King <email address hidden>
+
+:040000 040000 23bd54d302533c173a4ae592969dd2868794e9ed f1833b44ee7a389902f6f9d2fb55f4b89ba0de16 M	arch
+
+Now might be a good time to mention that Fedora has very recently switched to using 64k pages.
+
+I'll continue this on the mailing list you suggested.
+
+Still happening with latest upstream kernel.  It seems to involve using the -initrd option at all, with any cpio file, even a tiny one.  More results posted here:
+
+https://lists.cs.columbia.edu/pipermail/kvmarm/2014-December/012557.html
+
+Finally found the problem, patch posted:
+https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html
+
+I was just about to get to testing this stuff, but thanks for working
+through it on your own, and apologies I didn't get to it before.
+
+Cc'ing Marc so he's aware of the progress.
+
+-Christoffer
+
+On Mon, Dec 1, 2014 at 3:46 PM, Richard Jones <email address hidden> wrote:
+> Finally found the problem, patch posted:
+> https://lists.gnu.org/archive/html/qemu-devel/2014-12/msg00034.html
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1383857
+>
+> Title:
+>   aarch64: virtio disks don't show up in guest (neither blk nor scsi)
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   kernel-3.18.0-0.rc1.git0.1.rwmj5.fc22.aarch64 (3.18 rc1 + some hardware enablement)
+>   qemu from git today
+>
+>   When I create a guest with virtio-scsi disks, they don't show up inside the guest.
+>   Literally after the virtio_mmio.ko and virtio_scsi.ko modules are loaded, there are
+>   no messages about disks, and of course nothing else works.
+>
+>   Really long command line (generated by libvirt):
+>
+>   HOME=/home/rjones USER=rjones LOGNAME=rjones QEMU_AUDIO_DRV=none
+>   TMPDIR=/home/rjones/d/libguestfs/tmp
+>   /home/rjones/d/qemu/aarch64-softmmu/qemu-system-aarch64 -name guestfs-
+>   oqv29um3jp03kpjf -S -machine virt,accel=tcg,usb=off -cpu cortex-a57 -m
+>   500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid
+>   a5f1a15d-2bc7-46df-9974-1d1f643b2449 -nographic -no-user-config
+>   -nodefaults -chardev
+>   socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib
+>   /guestfs-oqv29um3jp03kpjf.monitor,server,nowait -mon
+>   chardev=charmonitor,id=monitor,mode=control -rtc
+>   base=utc,driftfix=slew -no-reboot -boot strict=on -kernel
+>   /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/kernel -initrd
+>   /home/rjones/d/libguestfs/tmp/.guestfs-1000/appliance.d/initrd -append
+>   panic=1 console=ttyAMA0 earlyprintk=pl011,0x9000000 ignore_loglevel
+>   efi-rtc=noprobe udevtimeout=6000 udev.event-timeout=6000
+>   no_timer_check lpj=500000 acpi=off printk.time=1 cgroup_disable=memory
+>   root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device
+>   virtio-scsi-device,id=scsi0 -device virtio-serial-device,id=virtio-
+>   serial0 -usb -drive
+>   file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/scratch.1,if=none,id
+>   =drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-
+>   hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-
+>   scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive
+>   file=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/overlay2,if=none,id
+>   =drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-
+>   hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-
+>   scsi0-0-1-0,id=scsi0-0-1-0 -serial
+>   unix:/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/console.sock
+>   -chardev
+>   socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs4GxfQ9/guestfsd.sock
+>   -device virtserialport,bus=virtio-
+>   serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0
+>   -msg timestamp=on
+>
+>   There are no kernel messages about the disks, they just are not seen.
+>
+>   Worked with kernel 3.16 so I suspect this could be a kernel bug rather than a
+>   qemu bug, but I've no idea where to report those.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1383857/+subscriptions
+
+
+Richard -- I assume we fixed this one way or another, right?
+
+
+Oh yes, long fixed.
+
diff --git a/results/classifier/118/KVM/139 b/results/classifier/118/KVM/139
new file mode 100644
index 000000000..3c71531fa
--- /dev/null
+++ b/results/classifier/118/KVM/139
@@ -0,0 +1,31 @@
+KVM: 0.905
+network: 0.865
+mistranslation: 0.807
+device: 0.795
+kernel: 0.750
+performance: 0.692
+architecture: 0.577
+semantic: 0.489
+arm: 0.464
+files: 0.453
+peripherals: 0.434
+register: 0.396
+graphic: 0.383
+virtual: 0.364
+permissions: 0.344
+boot: 0.341
+debug: 0.327
+vnc: 0.323
+VMM: 0.309
+socket: 0.286
+hypervisor: 0.258
+x86: 0.216
+i386: 0.196
+PID: 0.182
+risc-v: 0.159
+ppc: 0.155
+TCG: 0.059
+assembly: 0.042
+user-level: 0.035
+
+kvm rbd driver (and maybe others, i.e. qcow2, qed and so on)  does not report DISCARD-ZERO flag
diff --git a/results/classifier/118/KVM/1398 b/results/classifier/118/KVM/1398
new file mode 100644
index 000000000..af8c69515
--- /dev/null
+++ b/results/classifier/118/KVM/1398
@@ -0,0 +1,36 @@
+KVM: 0.979
+kernel: 0.950
+device: 0.901
+architecture: 0.859
+graphic: 0.696
+x86: 0.638
+boot: 0.519
+mistranslation: 0.486
+debug: 0.479
+register: 0.433
+semantic: 0.402
+PID: 0.380
+arm: 0.373
+permissions: 0.366
+virtual: 0.317
+vnc: 0.252
+risc-v: 0.239
+user-level: 0.192
+socket: 0.164
+performance: 0.158
+VMM: 0.157
+hypervisor: 0.133
+TCG: 0.131
+files: 0.089
+assembly: 0.069
+ppc: 0.062
+network: 0.052
+i386: 0.015
+peripherals: 0.007
+
+Kernel Fault in primary space mode while using user ASCE emulating s390x with AlmaLinux release 9.1 (Lime Lynx)
+Description of problem:
+Happens twice during startup, however the system keeps running.
+Steps to reproduce:
+1. Install Alma Linux s390x on in KVM on x86_64
+2. Start KVM
diff --git a/results/classifier/118/KVM/1405385 b/results/classifier/118/KVM/1405385
new file mode 100644
index 000000000..7701bd34b
--- /dev/null
+++ b/results/classifier/118/KVM/1405385
@@ -0,0 +1,295 @@
+KVM: 0.826
+peripherals: 0.818
+ppc: 0.817
+vnc: 0.765
+user-level: 0.760
+x86: 0.758
+hypervisor: 0.749
+virtual: 0.713
+TCG: 0.698
+VMM: 0.676
+mistranslation: 0.663
+device: 0.635
+permissions: 0.631
+register: 0.629
+network: 0.600
+graphic: 0.598
+kernel: 0.594
+PID: 0.592
+performance: 0.582
+boot: 0.577
+files: 0.577
+debug: 0.574
+arm: 0.568
+architecture: 0.545
+socket: 0.544
+semantic: 0.536
+assembly: 0.500
+i386: 0.496
+risc-v: 0.437
+
+QEMU crashes when virtio network cards are used together with e1000 network cards
+
+QEMU version: QEMU emulator version 2.2.50, Copyright (c) 2003-2008 Fabrice Bellard
+QEMU GIT version: ab0302ee764fd702465aef6d88612cdff4302809
+Configure flags: ./configure --enable-kvm --prefix=/opt/qemu-devel
+Linux version: Ubuntu 14.04.1 LTS
+Kernel version: 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
+
+Problem:
+
+	QEMU crashes when using one (or more) virtio network cards together with one (or more) e1000 (and possibly others) network cards when those cards are bound to a linux bridge. When the cards are *not* bound to a bridge QEMU does not crash.
+
+Bridge configuration:
+
+	iface bridge0 inet dhcp
+	bridge_ports eth1
+	bridge_stp off
+	bridge_fd 0
+
+Start-up command (including binding the network cards to the bridge + strace logging):
+
+./qemu-system-x86_64 -daemonize -smp 1 -m 128 -vnc 0.0.0.0:0 \
+-netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on \
+-device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA \
+-netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 \
+-device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB; \
+brctl addif bridge0 net_1_1; \
+brctl addif bridge0 net_1_2; \
+ifconfig net_1_1 0.0.0.0 up; \
+ifconfig net_1_2 0.0.0.0 up; \
+sleep 2; \
+strace -p `ps x |grep qemu-system-x86_64 |grep -v grep|awk '{print $1}'` -o /tmp/qemu-devel-trace.txt 
+
+Kernel log:
+
+Dec 24 11:12:08 bramws kernel: [12466.885581] device net_1_1 entered promiscuous mode
+Dec 24 11:12:08 bramws kernel: [12466.886238] device net_1_2 entered promiscuous mode
+Dec 24 11:12:08 bramws kernel: [12466.887084] bridge0: port 2(net_1_1) entered forwarding state
+Dec 24 11:12:08 bramws kernel: [12466.887089] bridge0: port 2(net_1_1) entered forwarding state
+Dec 24 11:12:08 bramws kernel: [12466.888940] bridge0: port 3(net_1_2) entered forwarding state
+Dec 24 11:12:08 bramws kernel: [12466.888947] bridge0: port 3(net_1_2) entered forwarding state
+Dec 24 11:12:29 bramws kernel: [12488.026376] bridge0: port 2(net_1_1) entered disabled state
+Dec 24 11:12:29 bramws kernel: [12488.026820] device net_1_1 left promiscuous mode
+Dec 24 11:12:29 bramws kernel: [12488.026832] bridge0: port 2(net_1_1) entered disabled state
+Dec 24 11:12:29 bramws kernel: [12488.049636] bridge0: port 3(net_1_2) entered disabled state
+Dec 24 11:12:29 bramws kernel: [12488.050058] device net_1_2 left promiscuous mode
+Dec 24 11:12:29 bramws kernel: [12488.050074] bridge0: port 3(net_1_2) entered disabled state
+
+Strace log: (full log attached)
+
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 28646613}, NULL, 8) = 0 (Timeout)
+write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 10899760}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 10895457})
+write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
+read(5, "\1\0\0\0\0\0\0\0", 512)        = 8
+write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0})
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0})
+read(6, "\2\0\0\0\0\0\0\0", 16)         = 8
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout)
+read(6, 0x7fff697320e0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 9570429}, NULL, 8) = 0 (Timeout)
+futex(0x7f011c8ef094, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 224) = 1
+write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
+write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
+futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 54463396}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 54459649})
+tgkill(7779, 7784, SIGUSR1)             = 0
+futex(0x7f011aaa0824, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0x7f011aaa0860, 1650) = 1
+write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
+read(5, "\2\0\0\0\0\0\0\0", 512)        = 8
+write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0})
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 0})
+read(6, "\2\0\0\0\0\0\0\0", 16)         = 8
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 0}, NULL, 8) = 0 (Timeout)
+read(6, 0x7fff697320e0, 16)             = -1 EAGAIN (Resource temporarily unavailable)
+futex(0x7f011aaa0860, FUTEX_WAKE_PRIVATE, 1) = 1
+ppoll([{fd=13, events=POLLIN|POLLERR|POLLHUP}, {fd=7, events=POLLIN|POLLERR|POLLHUP}, {fd=12, events=POLLIN|POLLERR|POLLHUP}, {fd=3, events=POLLIN|POLLERR|POLLHUP}, {fd=6, events=POLLIN}, {fd=5, events=POLLIN}], 6, {0, 53843633}, NULL, 8 <unfinished ...>
++++ killed by SIGABRT +++
+
+
+
+What does qemu say when aborting?
+
+Hm. I guess it says nothing, as else some write(2) should be seen by strace.  So it is like abort() not assert().  And we have about 800 abort() calls in the code.  Oh well.
+
+Indeed, it does not say anything, it simply crashes. Besides the strace log I created I can't find any other usefull information in other logfiles.
+
+a backtrace from a coredump or gdb would be better; it'll tell us the line the abort is on and the state at that point.
+Run it under gdb and do
+
+bt full
+
+and paste the result.
+
+I can't reproduce this, no matter how hard I try. Tried 4 virtio devices and 4 e1000 devices (8 network devices in total).  Tried 2.1 and 2.2 and current git.  It all Just Works (tm).  What I'm doing wrong? :)
+
+I think your just not trying hard enough ;-)
+
+I have reproduced this on four different (bare metal) machines. I used the default ubuntu QEMU (2.0.0) and the latest GIT version. All machines where running ubuntu 14.04. I also tried to reproduce it on a virtualbox VM and I could only get it to crash when I put the network card of my virtual machine (the virtualbox one) in promiscuous modus. If I would set promiscuous modus to "deny all" in virtual box QEMU would not crash.
+
+I will do the gdb debug trace when I get back at work, I don't have a suitable system available at home to test this with.
+
+I have a hard time getting a full backtrace. I recompiled qemu with --enable-debug. Running QEMU with -s -S and then using GDB with debug using: attach remote localhost:1234 works but when QEMU has crashed the command "bt full" always gives back:
+
+(gdb) bt full
+No stack.
+
+I then ran QEMU directly from GDB using: run -nographic -smp 1 -m 128 -vnc 0.0.0.0:0 -netdev tap,id=tap_1,script=no,downscript=no,ifname=net_1_1,vhost=on -device virtio-net-pci,bootindex=1,id=nic_1,netdev=tap_1,mac=02:16:3F:00:00:FA -netdev tap,id=tap_2,script=no,downscript=no,ifname=net_1_2 -device e1000,bootindex=2,id=nic_2,netdev=tap_2,mac=02:16:3F:00:00:FB
+
+I have to press a key continuously to get QEMU "running" (otherwise it halts). Right before QEMU crashes I get this error in gdb:
+
+Program received signal SIGUSR1, User defined signal 1.
+spin_lock (lock=0x5a4f072640e15f00) at /home/bram/git/qemu/include/exec/spinlock.h:42
+42	{
+(gdb) 
+Continuing.
+qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000074f0a5f9
+
+EAX=00000000 EBX=0001939c ECX=00009cf3 EDX=00001c79
+ESI=f81ac248 EDI=0009bd70 EBP=0009bd20 ESP=0009bd14
+EIP=6d016c49 EFL=00000083 [--S---C] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS   [-WA]
+CS =0008 07ef39b0 ffffffff 00cf9f00 DPL=0 CS32 [CRA]
+SS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS   [-WA]
+DS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS   [-WA]
+FS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS   [-WA]
+GS =0010 07ef39b0 ffffffff 00cf9300 DPL=0 DS   [-WA]
+LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
+GDT=     0009cf40 00000037
+IDT=     07f8df10 00006deb
+CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+CCS=000193bc CCD=ffffffe0 CCO=SUBL    
+EFER=0000000000000000
+FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
+FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
+FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
+FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
+FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
+XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
+XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
+XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
+XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
+
+Program received signal SIGABRT, Aborted.
+0x00007ffff2797bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
+(gdb) 
+Continuing.
+[Thread 0x7fffdadff700 (LWP 27991) exited]
+[Thread 0x7ffff7fa8980 (LWP 27930) exited]
+
+Program terminated with signal SIGABRT, Aborted.
+
+If I run bt full right after that I get the exact same "No stack." error.  I then created a core dump and ran the bt full on that, giving me this output:
+
+#0  0x00007f038ec86bb9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+        resultvar = 0
+        pid = 29457
+        selftid = 29462
+#1  0x00007f038ec89fc8 in __GI_abort () at abort.c:89
+        save_stage = 2
+        act = {__sigaction_handler = {sa_handler = 0x4c425553, sa_sigaction = 0x4c425553}, sa_mask = {__val = {139653355451349, 893353197568, 139653355450960, 139653355450970, 
+              15179618306775321344, 1, 139653029951232, 0, 0, 139653029951936, 139653029951232, 139653029947664, 139653353918150, 1688849860263936, 139653257249376, 
+              139653260837312}}, sa_flags = -1760754560, sa_restorer = 0x7f039708a7e0}
+        sigs = {__val = {32, 0 <repeats 15 times>}}
+#2  0x00007f039459377f in cpu_abort (cpu=0x7f03970d0480, fmt=0x7f03949f2830 "Trying to execute code outside RAM or ROM at 0x%016lx\n") at /home/bram/git/qemu/exec.c:805
+        ap = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}}
+        ap2 = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7f03813dea30, reg_save_area = 0x7f03813de970}}
+#3  0x00007f03945f4d20 in get_page_addr_code (env1=0x7f03970d86d0, addr=1961928185) at /home/bram/git/qemu/cputlb.c:357
+        cc = 0x7f039708a7e0
+        mmu_idx = 2
+        page_index = 10
+        pd = 0
+        p = 0x7ef5000
+        mr = 0x7f0394e79620 <io_mem_unassigned>
+        cpu = 0x7f03970d0480
+        __func__ = "get_page_addr_code"
+#4  0x00007f039459c38e in tb_find_slow (env=0x7f03970d86d0, pc=1961928185, cs_base=133118384, flags=244) at /home/bram/git/qemu/cpu-exec.c:243
+        cpu = 0x7f03970d0480
+        tb = 0x4fb813deb00
+        ptb1 = 0x7f0394a03680
+        h = 32515
+        phys_pc = 139653395842176
+        phys_page1 = 139653029948228
+        virt_page2 = 139653029948232
+#5  0x00007f039459c63c in tb_find_fast (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:300
+        cpu = 0x7f03970d0480
+        tb = 0x0
+        cs_base = 133118384
+        pc = 1961928185
+        flags = 244
+#6  0x00007f039459cade in cpu_x86_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpu-exec.c:456
+        cpu = 0x7f03970d0480
+        cc = 0x7f039708a7e0
+        __func__ = "cpu_x86_exec"
+        x86_cpu = 0x7f03970d0480
+        ret = 65536
+        interrupt_request = 2
+        tb = 0x7f038166b6d8
+        tc_ptr = 0x7f0383576ad0 "A\213n\364\205\355\017\205\245"
+        next_tb = 0
+        sc = {diff_clk = 139653029948416, last_cpu_icount = 139653351987455, realtime_clock = 139653029948448}
+        have_tb_lock = true
+#7  0x00007f03945ca913 in tcg_cpu_exec (env=0x7f03970d86d0) at /home/bram/git/qemu/cpus.c:1363
+        cpu = 0x7f03970d0480
+        ret = 32515
+#8  0x00007f03945caa28 in tcg_exec_all () at /home/bram/git/qemu/cpus.c:1396
+        cpu = 0x7f03970d0480
+        env = 0x7f03970d86d0
+        r = 32515
+#9  0x00007f03945c9d47 in qemu_tcg_cpu_thread_fn (arg=0x7f03970d0480) at /home/bram/git/qemu/cpus.c:1042
+        cpu = 0x0
+#10 0x00007f038f01e182 in start_thread (arg=0x7f03813df700) at pthread_create.c:312
+        __res = <optimized out>
+        pd = 0x7f03813df700
+        now = <optimized out>
+        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139653029951232, 5823000673722110008, 0, 0, 139653029951936, 139653029951232, -5852297728485158856, -5852310887850110920}, 
+              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
+        not_first_call = <optimized out>
+        pagesize_m1 = <optimized out>
+        sp = <optimized out>
+        freesize = <optimized out>
+        __PRETTY_FUNCTION__ = "start_thread"
+#11 0x00007f038ed4aefd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
+No locals.
+
+
+Im not sure if this is all the information needed? I attached the core dump.
+
+On 29 December 2014 at 08:29, Bram Klein Gunnewiek
+<email address hidden> wrote:
+> Right before QEMU crashes I get this error in gdb:
+>
+> Program received signal SIGUSR1, User defined signal 1.
+
+SIGUSR1 is used internally by QEMU. You can tell gdb not to
+bother you about it:
+
+ handle SIGUSR1 pass noprint nostop
+
+before running.
+
+-- PMM
+
+
+I'm not sure if there is more information required from my side? I can still reproduce this and have no clue where to look for more information.
+
+On Fri, Jan 09, 2015 at 07:30:05AM -0000, Bram Klein Gunnewiek wrote:
+> I'm not sure if there is more information required from my side? I can
+> still reproduce this and have no clue where to look for more
+> information.
+
+I cannot reproduce a crash from your command-line with qemu.git/master
+(3e5f6234b4f45a11b7c357dde2d6da36641bc6f6).
+
+
+Looking through old bug tickets... Bram, can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1441443 b/results/classifier/118/KVM/1441443
new file mode 100644
index 000000000..634c4ef5c
--- /dev/null
+++ b/results/classifier/118/KVM/1441443
@@ -0,0 +1,70 @@
+KVM: 0.988
+network: 0.963
+device: 0.936
+performance: 0.878
+virtual: 0.858
+peripherals: 0.852
+hypervisor: 0.847
+architecture: 0.841
+ppc: 0.815
+socket: 0.809
+mistranslation: 0.781
+user-level: 0.763
+VMM: 0.711
+graphic: 0.690
+kernel: 0.687
+register: 0.664
+vnc: 0.644
+semantic: 0.626
+PID: 0.626
+permissions: 0.599
+boot: 0.563
+x86: 0.549
+risc-v: 0.487
+assembly: 0.441
+TCG: 0.414
+i386: 0.380
+arm: 0.368
+files: 0.365
+debug: 0.307
+
+Is there a way to create a 10G network interface for VMs in KVM2.0?
+
+
+
+We have installed & configured the KVM 2.0 (qemu-kvm 2.0.0+dfsg-2ubuntu1.10) on Ubuntu 14.04. The physical server is connected to 10G network, KVM is configured in Bridged mode But the issue is, when we create Network interface on VMs, we have only 1G device as an options for vmhosts. Is this the limit of the KVM or is there a way to create a 10G network interface for VMs? Available device models
+
+E1000
+Ne2k_pci
+Pcnet
+Rtl8139
+virtio
+
+Please find the network configuration details
+
+Source device : Host device vnet1 (Bridge ‘br0’)
+Device model : virtio 
+
+Network configuration in the host /etc/network/interfaces
+
+auto br0
+iface br0 inet static
+        address 10.221.x.10
+        netmask 255.255.255.0
+        network 10.221.x.0
+        broadcast 10.221.x.255
+        gateway 10.221.x.1
+        # dns-* options are implemented by the resolvconf package, if installed
+        dns-nameservers X.X.X.X
+        dns-search XXX.NET
+        bridge_ports em1
+        bridge_fd 0
+        bridge_stp off
+        bridge_maxwait 0
+
+Looking through old bug tickets ... have you already tried to use vhost-net? That should be one of the fastest ways of networking with QEMU as far as I know...
+
+Unless you are using SRIOV or DPDK which both need hardware support. If could support SRIOV, then using IOMMU+VFIO, and pass-through to VM, this will get a close number. Or DPDK, using a user-space driver + vhost-net, will also get a pretty good value. 
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1463143 b/results/classifier/118/KVM/1463143
new file mode 100644
index 000000000..9e9f6681b
--- /dev/null
+++ b/results/classifier/118/KVM/1463143
@@ -0,0 +1,143 @@
+KVM: 0.843
+user-level: 0.798
+register: 0.740
+mistranslation: 0.738
+risc-v: 0.737
+virtual: 0.731
+permissions: 0.719
+device: 0.717
+graphic: 0.712
+TCG: 0.710
+architecture: 0.706
+performance: 0.696
+peripherals: 0.684
+semantic: 0.681
+hypervisor: 0.678
+arm: 0.678
+kernel: 0.674
+vnc: 0.665
+debug: 0.664
+boot: 0.648
+assembly: 0.647
+x86: 0.645
+PID: 0.643
+network: 0.641
+VMM: 0.631
+files: 0.626
+ppc: 0.615
+socket: 0.577
+i386: 0.551
+
+Kernel Panic on Guest VM
+
+Hi,
+
+I've recently attempted to move a stack to qemu vm's that I have run successfully on both hard metal and ec2.
+
+I'm not sure where to even begin debugging, could someone please point me in the right direction?
+
+
+
+
+  [781785.483343] RIP: 0010:[<ffffffff81511830>]  [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780
+[781785.483345] RSP: 0000:ffff88007fd03dd0  EFLAGS: 00010097
+[781785.483346] RAX: 0000000000000000 RBX: ffff8800374d0000 RCX: 0000000000000050
+[781785.483347] RDX: 0000000000000006 RSI: ffff8800374d0158 RDI: ffff8800374d0000
+[781785.483348] RBP: ffff88007fd03e20 R08: 0000000000000086 R09: ffff88007cc00000
+[781785.483349] R10: 0000000000000011 R11: 000000000000000b R12: ffff8800374d0158
+[781785.483350] R13: 0000000000000000 R14: ffff8800374d0158 R15: ffff8800374d0208
+[781785.483356] FS:  00007f3882e75700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
+[781785.483357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[781785.483358] CR2: 00007f37df39a000 CR3: 000000000b7a5000 CR4: 00000000000006e0
+[781785.483369] Stack:
+[781785.483373]  ffff8800373cb000 ffff88007fd03e60 ffffffff8108d7d2 ffff88007fd03e28
+[781785.483375]  ffff8800374d2140 ffff8800374d0000 ffff8800374d0158 0000000000000000
+[781785.483378]  0000000000000050 0000000000000000 ffff88007fd03e50 ffffffff81511e96
+[781785.483378] Call Trace:
+[781785.483382]  <IRQ> 
+[781785.483396]  [<ffffffff8108d7d2>] ? run_posix_cpu_timers+0x42/0x5c0
+[781785.483400]  [<ffffffff81511e96>] __ata_sff_port_intr+0x96/0x120
+[781785.483403]  [<ffffffff815121ed>] ata_bmdma_port_intr+0x2d/0x120
+[781785.483405]  [<ffffffff81512ba3>] ata_bmdma_interrupt+0x183/0x1e0
+[781785.483414]  [<ffffffff810bf8be>] handle_irq_event_percpu+0x3e/0x1d0
+[781785.483433]  [<ffffffff810bfa8d>] handle_irq_event+0x3d/0x60
+[781785.483437]  [<ffffffff810c2517>] handle_edge_irq+0x77/0x130
+[781785.483455]  [<ffffffff81015cde>] handle_irq+0x1e/0x30
+[781785.483472]  [<ffffffff817312cd>] do_IRQ+0x4d/0xc0
+[781785.483476]  [<ffffffff81726a6d>] common_interrupt+0x6d/0x6d
+[781785.483478]  <EOI> 
+[781785.483480]  [<ffffffff8172efad>] ? system_call_fastpath+0x1a/0x1f
+[781785.483498] Code: f9 ff ff 41 0f b6 46 28 3c 06 0f 84 0b 03 00 00 3c 07 0f 84 e3 02 00 00 3c 05 0f 84 c3 02 00 00 0f 0b 66 0f 1f 84 00 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 f6 c1 08 0f 84 19 05 00 00 f6 c1 21 0f 
+[781785.483501] RIP  [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780
+[781785.483501]  RSP <ffff88007fd03dd0>
+[781785.484009] ---[ end trace 1b6ef3497a5641b3 ]---
+[781785.484009] Kernel panic - not syncing: Fatal exception in interrupt
+[781785.484009] Shutting down cpus with NMI
+
+
+Thanks for any pointers.
+
+Ryan
+
+On Mon, Jun 08, 2015 at 07:13:56PM -0000, ryan wrote:
+> Public bug reported:
+> 
+> Hi,
+> 
+> I've recently attempted to move a stack to qemu vm's that I have run
+> successfully on both hard metal and ec2.
+> 
+> I'm not sure where to even begin debugging, could someone please point
+> me in the right direction?
+> 
+> 
+>   [781785.483343] RIP: 0010:[<ffffffff81511830>]  [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780
+> [781785.483345] RSP: 0000:ffff88007fd03dd0  EFLAGS: 00010097
+> [781785.483346] RAX: 0000000000000000 RBX: ffff8800374d0000 RCX: 0000000000000050
+> [781785.483347] RDX: 0000000000000006 RSI: ffff8800374d0158 RDI: ffff8800374d0000
+> [781785.483348] RBP: ffff88007fd03e20 R08: 0000000000000086 R09: ffff88007cc00000
+> [781785.483349] R10: 0000000000000011 R11: 000000000000000b R12: ffff8800374d0158
+> [781785.483350] R13: 0000000000000000 R14: ffff8800374d0158 R15: ffff8800374d0208
+> [781785.483356] FS:  00007f3882e75700(0000) GS:ffff88007fd00000(0000) knlGS:0000000000000000
+> [781785.483357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+> [781785.483358] CR2: 00007f37df39a000 CR3: 000000000b7a5000 CR4: 00000000000006e0
+> [781785.483369] Stack:
+> [781785.483373]  ffff8800373cb000 ffff88007fd03e60 ffffffff8108d7d2 ffff88007fd03e28
+> [781785.483375]  ffff8800374d2140 ffff8800374d0000 ffff8800374d0158 0000000000000000
+> [781785.483378]  0000000000000050 0000000000000000 ffff88007fd03e50 ffffffff81511e96
+> [781785.483378] Call Trace:
+> [781785.483382]  <IRQ> 
+> [781785.483396]  [<ffffffff8108d7d2>] ? run_posix_cpu_timers+0x42/0x5c0
+> [781785.483400]  [<ffffffff81511e96>] __ata_sff_port_intr+0x96/0x120
+> [781785.483403]  [<ffffffff815121ed>] ata_bmdma_port_intr+0x2d/0x120
+> [781785.483405]  [<ffffffff81512ba3>] ata_bmdma_interrupt+0x183/0x1e0
+> [781785.483414]  [<ffffffff810bf8be>] handle_irq_event_percpu+0x3e/0x1d0
+> [781785.483433]  [<ffffffff810bfa8d>] handle_irq_event+0x3d/0x60
+> [781785.483437]  [<ffffffff810c2517>] handle_edge_irq+0x77/0x130
+> [781785.483455]  [<ffffffff81015cde>] handle_irq+0x1e/0x30
+> [781785.483472]  [<ffffffff817312cd>] do_IRQ+0x4d/0xc0
+> [781785.483476]  [<ffffffff81726a6d>] common_interrupt+0x6d/0x6d
+> [781785.483478]  <EOI> 
+> [781785.483480]  [<ffffffff8172efad>] ? system_call_fastpath+0x1a/0x1f
+> [781785.483498] Code: f9 ff ff 41 0f b6 46 28 3c 06 0f 84 0b 03 00 00 3c 07 0f 84 e3 02 00 00 3c 05 0f 84 c3 02 00 00 0f 0b 66 0f 1f 84 00 00 00 00 00 <0f> 0b 66 0f 1f 44 00 00 f6 c1 08 0f 84 19 05 00 00 f6 c1 21 0f 
+> [781785.483501] RIP  [<ffffffff81511830>] ata_sff_hsm_move+0x1b0/0x780
+> [781785.483501]  RSP <ffff88007fd03dd0>
+> [781785.484009] ---[ end trace 1b6ef3497a5641b3 ]---
+> [781785.484009] Kernel panic - not syncing: Fatal exception in interrupt
+> [781785.484009] Shutting down cpus with NMI
+
+Please post your QEMU command-line.
+
+For best performance with a raw disk image file on local storage use:
+  -drive if=none,file=path/to/disk.img,format=raw,aio=native,cache=none,id=drive0 -device virtio-blk-pci,drive=drive0
+
+That may also work around this ATA issue.
+
+Stefan
+
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? If so, please provide the command line parameters that you use!
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1470481 b/results/classifier/118/KVM/1470481
new file mode 100644
index 000000000..f4d3420c4
--- /dev/null
+++ b/results/classifier/118/KVM/1470481
@@ -0,0 +1,44 @@
+KVM: 0.869
+device: 0.743
+graphic: 0.734
+performance: 0.486
+semantic: 0.456
+virtual: 0.433
+mistranslation: 0.431
+boot: 0.374
+files: 0.367
+vnc: 0.362
+socket: 0.347
+ppc: 0.346
+user-level: 0.341
+architecture: 0.301
+network: 0.245
+PID: 0.239
+permissions: 0.233
+debug: 0.233
+register: 0.181
+assembly: 0.180
+kernel: 0.157
+hypervisor: 0.152
+x86: 0.134
+risc-v: 0.130
+VMM: 0.117
+i386: 0.106
+peripherals: 0.096
+arm: 0.089
+TCG: 0.056
+
+qemu-img converts large vhd files into only approx. 127GB raw file causing the VM to crash
+
+I have a VHD file for Windows 2014 server OS. I use the following command to convert VHD file (20GB) to a RAW file for KVM.
+
+qemu-img convert -f vpc -O raw WIN-SNRGCQV6O3O.VHD disk.img
+
+The output file is about 127GB. When install the VM and boot it up, the OS crashes with STOP error after the intial screen. I found on the internet that the file limit of 127GB is an existing bug. Kindly fix the problem. The workaround to use a Hyper-V to convert to fixed disk is not a feasible solution.
+
+Which version of QEMU (or rather qemu-img) have you been using here? Can you still reproduce it with the latest version (currently v2.12)?
+
+I have qemu-img 1.4.1 included in Suse Linux Enterprise server version 11 SP3. I will see whether I can update it and then try the conversion and post the results. 
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1500935 b/results/classifier/118/KVM/1500935
new file mode 100644
index 000000000..b8fa8c346
--- /dev/null
+++ b/results/classifier/118/KVM/1500935
@@ -0,0 +1,49 @@
+KVM: 0.918
+architecture: 0.847
+graphic: 0.780
+virtual: 0.753
+x86: 0.704
+device: 0.679
+mistranslation: 0.676
+user-level: 0.646
+semantic: 0.559
+hypervisor: 0.487
+arm: 0.456
+permissions: 0.420
+ppc: 0.363
+performance: 0.352
+files: 0.329
+peripherals: 0.296
+socket: 0.256
+vnc: 0.256
+debug: 0.248
+network: 0.248
+assembly: 0.233
+register: 0.232
+PID: 0.215
+kernel: 0.213
+boot: 0.201
+risc-v: 0.190
+VMM: 0.159
+TCG: 0.152
+i386: 0.049
+
+Qemu / KVM always wants to be on top
+
+Whenever I pass with the mouse over the KVM (qemu) window, it automatically raises on top, obscuring other windows on the same desktop, which is rather intrusive...
+No other application does this.
+
+> dpkg -l qemu-kvm
+Desired=Unknown/Install/Remove/Purge/Hold
+| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
+|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
+||/ Name           Version      Architecture Description
++++-==============-============-============-=================================
+ii  qemu-kvm       2.0.0+dfsg-2 amd64        QEMU Full virtualization
+
+Seems like you are using the QEMU from your Linux distribution. If you want to have support for that version, you should use the bug tracker from your distro instead. Otherwise, can you please try again with the latest version from http://wiki.qemu-project.org/Download to see whether the bug is already fixed there? Thanks!
+
+Seems to be fixed by now. Indeed kvm no longer does this on none of the 2 distributions that I currently use (Debian 8.6.0 and Kubuntu 14.04.5)
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1529187 b/results/classifier/118/KVM/1529187
new file mode 100644
index 000000000..cfdb61c86
--- /dev/null
+++ b/results/classifier/118/KVM/1529187
@@ -0,0 +1,73 @@
+architecture: 0.964
+KVM: 0.945
+semantic: 0.944
+kernel: 0.939
+device: 0.931
+graphic: 0.928
+user-level: 0.913
+performance: 0.907
+mistranslation: 0.892
+VMM: 0.890
+peripherals: 0.890
+hypervisor: 0.889
+debug: 0.879
+PID: 0.874
+files: 0.871
+permissions: 0.869
+network: 0.858
+virtual: 0.857
+risc-v: 0.852
+x86: 0.842
+socket: 0.815
+assembly: 0.815
+register: 0.805
+ppc: 0.794
+vnc: 0.787
+TCG: 0.744
+arm: 0.723
+boot: 0.691
+i386: 0.547
+
+vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform
+
+Environment:
+ ------------
+ Host OS (ia32/ia32e/IA64): ia32e
+ Guest OS (ia32/ia32e/IA64): ia32e
+ Guest OS Type (Linux/Windows): linux
+ kvm.git Commit: da3f7ca3
+ qemu.git Commit: 38a762fe 
+ Host Kernel Version: 4.4.0-rc2
+ Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP)
+
+Bug description:
+ --------------------------
+ when create guest with vt-d assignment using vfio-pci driver, the guest can not be created.
+Warning 'No available IOMMU models'
+
+
+Reproduce steps:
+ ----------------
+ 1. bind device to vfio-pci driver
+ 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 -net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0
+
+Current result:
+ ----------------
+ qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU models
+ qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup container for group 41
+ qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41
+ qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed
+
+Expected result:
+ ----------------
+ guest can be created
+Basic root-causing log:
+ ----------------------
+
+
+
+
+You've somehow managed to not load the vfio_iommu_type1 module.  The vfio module will request it when loading, if the module is not available when loading, such as from an initramfs that does not include the full set of vfio modules, it will need to be loaded later manually.
+
+You're right. After I manually load vfio_iommu_type1, the error is gone.
+
diff --git a/results/classifier/118/KVM/1545 b/results/classifier/118/KVM/1545
new file mode 100644
index 000000000..31c0fa591
--- /dev/null
+++ b/results/classifier/118/KVM/1545
@@ -0,0 +1,39 @@
+KVM: 0.990
+kernel: 0.894
+device: 0.797
+network: 0.733
+socket: 0.665
+graphic: 0.641
+register: 0.581
+vnc: 0.460
+boot: 0.449
+semantic: 0.422
+debug: 0.413
+PID: 0.293
+VMM: 0.271
+arm: 0.256
+TCG: 0.254
+files: 0.245
+hypervisor: 0.231
+permissions: 0.195
+risc-v: 0.191
+ppc: 0.176
+architecture: 0.174
+mistranslation: 0.171
+performance: 0.168
+i386: 0.145
+virtual: 0.124
+x86: 0.121
+user-level: 0.107
+assembly: 0.025
+peripherals: 0.018
+
+SSL is out of date on website
+Description of problem:
+The Linux KVM website is running an out of date SSL certificate.
+Steps to reproduce:
+1. visit the website. https://www.linux-kvm.org/page/Main_Page
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/118/KVM/1553999 b/results/classifier/118/KVM/1553999
new file mode 100644
index 000000000..347d5a42f
--- /dev/null
+++ b/results/classifier/118/KVM/1553999
@@ -0,0 +1,57 @@
+KVM: 0.971
+x86: 0.966
+kernel: 0.924
+architecture: 0.847
+graphic: 0.839
+device: 0.818
+semantic: 0.803
+mistranslation: 0.787
+performance: 0.735
+user-level: 0.732
+PID: 0.714
+i386: 0.702
+hypervisor: 0.653
+boot: 0.597
+ppc: 0.594
+risc-v: 0.584
+network: 0.571
+debug: 0.569
+permissions: 0.564
+register: 0.555
+socket: 0.546
+arm: 0.541
+files: 0.541
+VMM: 0.538
+vnc: 0.516
+virtual: 0.485
+TCG: 0.482
+peripherals: 0.436
+assembly: 0.227
+
+OpenGL support is disabled
+
+$ qemu-system-x86_64 -enable-kvm -display sdl,gl=on -vga qxl
+SDL1 display code has no opengl support.
+Please recompile qemu with SDL2, using
+./configure --enable-sdl --with-sdlabi=2.0
+qemu-system-x86_64: OpenGL support is disabled
+
+
+Can you please recompile qemu with support for opengl. The -display mode allows for opengl support.
+
+This feature allows for the guest OS to have opengl 2 support, that is require for several 3d applications.
+It also opens the way for supporting acceleration on windows and Linux guest systems.
+
+Since you're talking about a pre-compiled binary, I assume you wanted to open this bug against Ubuntu's QEMU package, not against the QEMU project?
+
+Looks like that this bug is duplicate of https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1540692
+
+Isn't it?
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Opengl in general as requested  was enabled and backported up to Bionic (18.04).
+
+There are several usability enhancements to use that with either mdev passthrough and virtgl which I work on upstream and are going into Disco (19.04).
+
+
diff --git a/results/classifier/118/KVM/1559 b/results/classifier/118/KVM/1559
new file mode 100644
index 000000000..062cede18
--- /dev/null
+++ b/results/classifier/118/KVM/1559
@@ -0,0 +1,37 @@
+KVM: 0.995
+boot: 0.981
+ppc: 0.975
+hypervisor: 0.954
+graphic: 0.863
+device: 0.838
+performance: 0.758
+mistranslation: 0.680
+semantic: 0.675
+debug: 0.598
+virtual: 0.582
+architecture: 0.550
+kernel: 0.395
+vnc: 0.288
+PID: 0.227
+arm: 0.226
+register: 0.183
+user-level: 0.160
+socket: 0.128
+risc-v: 0.120
+TCG: 0.118
+VMM: 0.064
+assembly: 0.055
+files: 0.049
+network: 0.048
+peripherals: 0.033
+i386: 0.017
+x86: 0.016
+permissions: 0.006
+
+7.2 (regression?): ppc64 KVM-HV hangs during boot
+Description of problem:
+qemu 7.2.0 hangs at " * Mounting ZFS filesystem(s)  ..." whereas 7.1.0 would fully boot.
+
+Without -smp, sometimes gets further and hangs later on at " * Seeding random number generator ..."
+Additional information:
+7.1.0 used to work before upgrading to 7.2.0, but would hang randomly after booting (usually during my benchmark). Not sure if related. Unfortunately, after downgrading back to 7.1.0, it also now hangs the same way as 7.2.0 does.
diff --git a/results/classifier/118/KVM/1579645 b/results/classifier/118/KVM/1579645
new file mode 100644
index 000000000..19826c30e
--- /dev/null
+++ b/results/classifier/118/KVM/1579645
@@ -0,0 +1,48 @@
+KVM: 0.952
+graphic: 0.948
+ppc: 0.939
+boot: 0.912
+architecture: 0.878
+x86: 0.863
+device: 0.732
+hypervisor: 0.728
+kernel: 0.726
+semantic: 0.716
+performance: 0.711
+user-level: 0.686
+mistranslation: 0.651
+peripherals: 0.650
+network: 0.639
+files: 0.635
+PID: 0.622
+permissions: 0.585
+register: 0.557
+debug: 0.525
+i386: 0.510
+vnc: 0.491
+assembly: 0.468
+virtual: 0.423
+socket: 0.409
+risc-v: 0.407
+arm: 0.355
+VMM: 0.315
+TCG: 0.238
+
+ [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97"
+
+Environment:
+
+when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below:
+"audio: Could no init “oss” audio driver.",
+then login the guest and try run audio, no sound output.
+Reproduce:
+1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img]
+   xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure
+2. it will show "audio: Could no init “oss” audio driver".
+3. login in guest, it can detect audio device, but actually it is not working.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1583 b/results/classifier/118/KVM/1583
new file mode 100644
index 000000000..8d1ef5793
--- /dev/null
+++ b/results/classifier/118/KVM/1583
@@ -0,0 +1,49 @@
+KVM: 0.996
+device: 0.949
+graphic: 0.927
+virtual: 0.861
+files: 0.851
+architecture: 0.785
+kernel: 0.785
+vnc: 0.722
+semantic: 0.683
+socket: 0.655
+PID: 0.644
+boot: 0.639
+hypervisor: 0.632
+network: 0.627
+permissions: 0.625
+ppc: 0.620
+register: 0.577
+debug: 0.570
+performance: 0.540
+TCG: 0.485
+arm: 0.470
+peripherals: 0.461
+VMM: 0.441
+user-level: 0.393
+mistranslation: 0.358
+risc-v: 0.346
+i386: 0.328
+x86: 0.289
+assembly: 0.201
+
+SGX Device mapping is not listed into QEMU KVM
+Description of problem:
+I want to run SGX into QEMU VM, the vm is up and running but SGX device mappings are not listed there. I also looked in dmesg | grep sgx and it returned "There are zero epc section"
+
+I have upgraded the libvirt to 8.6.0 because of below issue
+https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1982896
+
+I tried with libvirt-8.0.0 but it did not help
+
+I have attached the xml, please let me know why sgx mappings are not showing inside VM
+Steps to reproduce:
+1. Create a Ubuntu 20.04 VM with SGX mapping
+Additional information:
+Please let me know if any other logs are required
+
+
+
+
+[ubuntu20.04.xml](/uploads/2609abc31db08e04cc3e3dbf923cd8d7/ubuntu20.04.xml)
diff --git a/results/classifier/118/KVM/1583775 b/results/classifier/118/KVM/1583775
new file mode 100644
index 000000000..10cbe1f91
--- /dev/null
+++ b/results/classifier/118/KVM/1583775
@@ -0,0 +1,69 @@
+KVM: 0.803
+user-level: 0.702
+mistranslation: 0.680
+device: 0.636
+graphic: 0.570
+socket: 0.533
+semantic: 0.524
+network: 0.509
+PID: 0.485
+register: 0.483
+ppc: 0.450
+arm: 0.448
+files: 0.441
+virtual: 0.419
+hypervisor: 0.416
+i386: 0.413
+permissions: 0.401
+architecture: 0.378
+boot: 0.377
+x86: 0.367
+risc-v: 0.353
+performance: 0.349
+assembly: 0.306
+peripherals: 0.291
+kernel: 0.282
+vnc: 0.262
+VMM: 0.239
+TCG: 0.214
+debug: 0.213
+
+Feature Request: qemu 2.6.0
+
+Qemu 2.6.0 just got released, and according to changelogs it has quite some enhancements...
+
+would it be possible to have someone who has a qemu ppa on launchpad to migrate this into his ppa?
+
+thanks in advance
+
+I'm testing a merge of it right now.
+
+On Thu, May 19, 2016 at 9:13 PM, Launchpad Bug Tracker
+<email address hidden> wrote:
+> You have been subscribed to a public bug:
+>
+> Qemu 2.6.0 just got released, and according to changelogs it has quite
+> some enhancements...
+>
+> would it be possible to have someone who has a qemu ppa on launchpad to
+> migrate this into his ppa?
+>
+> thanks in advance
+>
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+>
+>
+> ** Tags: kvm qemu spice vfio virtio
+> --
+> Feature Request: qemu 2.6.0
+> https://bugs.launchpad.net/bugs/1583775
+> You received this bug notification because you are subscribed to QEMU.
+
+
+thank you very much serge=)
+
+Hi; I'm going to close this because it isn't a bug in upstream QEMU (which only does source releases).
+
+
diff --git a/results/classifier/118/KVM/1637511 b/results/classifier/118/KVM/1637511
new file mode 100644
index 000000000..18c1d3ef4
--- /dev/null
+++ b/results/classifier/118/KVM/1637511
@@ -0,0 +1,60 @@
+KVM: 0.903
+kernel: 0.794
+graphic: 0.741
+semantic: 0.630
+user-level: 0.626
+architecture: 0.603
+hypervisor: 0.592
+device: 0.587
+arm: 0.577
+mistranslation: 0.576
+performance: 0.556
+x86: 0.531
+network: 0.520
+peripherals: 0.498
+socket: 0.491
+virtual: 0.488
+permissions: 0.483
+PID: 0.478
+register: 0.465
+ppc: 0.388
+files: 0.382
+boot: 0.348
+debug: 0.347
+i386: 0.325
+assembly: 0.322
+risc-v: 0.282
+TCG: 0.245
+VMM: 0.225
+vnc: 0.192
+
+Armitage crashes KVM guest with Kali2016.2 for QXL video
+
+I recently got a strange bug which seems to be related to qemu-kvm and QXL. I came here via the hints of the KVM web-site for KVM/qemu bug tracking. But, I am not sure whether this is the right bug-tracker at all. Please advise me if I placed the report wrongly. 
+
+I installed Kali2016.2 as a KVM guest on a Opensuse Leap 42.1 host (fully updated). The KVM guest machine was configured to use a spice display and QXL video. Everything OK with the installation with the exception of one major application with a Java interface - Armitage. 
+
+Armitage is correctly configured and starts (with some minor Java errors) and opens its interface (msf console, target window  etc.) Trying to open the 2 specific menu points "Hosts" or "Attack" in the menu bar leads to something very strange: The screen flickers, then the whole login session is stopped and a standard login window opens. This happens independently of the setting for the type of Armitage target window (graphical or table like)  
+
+Why do I report this bug here? 
+Because it happens with the QXL graphical video interface ONLY - not with video=vga or vmvga ! Neither does the bug occur when Armitage is started in a ssh (-X) session from the host. 
+
+So, it is closely related to qemu-kvm AND QXL and the Java interaction with both. 
+
+I really wonder what in the world can make 2 specific menu points of a Java application crash a KVM guest and restart a login shell in Kali only when QXL is used?  
+
+qemu-kvm version : 2.3.1
+Kernel version of OS LEAP 42.1: Linux 4.1.31-30-default           
+
+I have described the bug also to the Kali people - see https://bugs.kali.org/view.php?id=3698
+
+Please inform me what further data are required - if this is relevant in this bug-tracker at all.
+
+If it's related to QXL, you should likely rather report this bug to the Spice people instead of QEMU. See https://www.spice-space.org/support.html for more information.
+
+Is this still an issue with the latest version? Did you ever report it to the Spice project?
+
+Can be closed - did not happen in later versions
+
+Ok, thanks for your answer, so I'm closing this ticket now.
+
diff --git a/results/classifier/118/KVM/1642011 b/results/classifier/118/KVM/1642011
new file mode 100644
index 000000000..ab2b06d1d
--- /dev/null
+++ b/results/classifier/118/KVM/1642011
@@ -0,0 +1,53 @@
+KVM: 0.955
+x86: 0.951
+PID: 0.940
+user-level: 0.931
+device: 0.930
+i386: 0.924
+network: 0.900
+virtual: 0.899
+graphic: 0.883
+socket: 0.856
+peripherals: 0.848
+architecture: 0.803
+vnc: 0.782
+files: 0.782
+semantic: 0.772
+performance: 0.754
+permissions: 0.749
+mistranslation: 0.739
+debug: 0.728
+hypervisor: 0.723
+register: 0.680
+ppc: 0.668
+kernel: 0.626
+boot: 0.588
+risc-v: 0.559
+arm: 0.498
+VMM: 0.472
+TCG: 0.448
+assembly: 0.415
+
+Mouse wheel events not forwarded to guest using GTK display
+
+Using QEMU 2.7.0 with KVM enabled, when I launch the guest without options (using the default of gtk), the mouse wheel events are not propagated to the guest.
+
+When I start qemu using -display sdk, mouse wheel events are properly forwarded.
+
+I can determine that the guest is not receiving mouse wheel events by doing cat /dev/input/by-id/usb-QEMU_QEMU_USB_Mouse_42-event-mouse. When I scroll the wheel, no output is printed to the screen.
+
+The guest is ChromiumOS.
+
+The command line is:
+
+qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -vga cirrus -usbdevice mouse -pidfile /tmp/kvm.pid -chardev pipe,id=control_pipe,path=/tmp/kvm.pipe -serial file:/tmp/kvm.serial -mon chardev=control_pipe -net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:9222-:22 -drive file=chromiumos/src/build/images/amd64-generic/latest/chromiumos_qemu_image.bin,index=0,media=disk,cache=unsafe
+
+(Most of that invocation sets up Linux fifos for various and nefarious purposes and can be profitably ignored).
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting all older bugs to
+"Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1663287 b/results/classifier/118/KVM/1663287
new file mode 100644
index 000000000..2ef750c06
--- /dev/null
+++ b/results/classifier/118/KVM/1663287
@@ -0,0 +1,143 @@
+KVM: 0.809
+VMM: 0.795
+risc-v: 0.793
+vnc: 0.790
+user-level: 0.790
+peripherals: 0.788
+device: 0.782
+permissions: 0.780
+ppc: 0.775
+mistranslation: 0.774
+boot: 0.768
+TCG: 0.758
+hypervisor: 0.754
+virtual: 0.754
+debug: 0.733
+performance: 0.728
+kernel: 0.720
+register: 0.716
+semantic: 0.709
+graphic: 0.686
+architecture: 0.682
+PID: 0.675
+arm: 0.670
+assembly: 0.669
+network: 0.647
+socket: 0.624
+files: 0.601
+x86: 0.561
+i386: 0.478
+
+Illegal delay slot code causes abort on mips64
+
+During some randomised testing of an experimental MIPS implementation I found an instruction sequence that also causes aborts on mainline qemu's MIPS support.  The problem is triggered by an MSA branch instruction appearing in a delay slot when emulating a processor without MSA support.
+
+For example, with the current repository HEAD (f073cd3a2bf1054135271b837c58a7da650dd84b) configured for mips64-softmmu, if I run the attached binary using
+
+    mips64-softmmu/qemu-system-mips64 -bios ../abort2.bin -machine mipssim -nographic
+
+it will report
+
+    unknown branch 0x13000
+    Aborted (core dumped)
+
+The binary contains the following two instructions:
+
+    00200008 jr at
+    47081e61 bz.b       w8,0xffffffffbfc0798c
+
+The jr sets up a jump, and hflags is set accordingly in gen_compute_branch (in target/mips/translate.c).  When processing the bz.b, check_insn generates an exception because the instruction isn't support, but gen_msa_branch skips the usual delay slot check for the same reason, and sets more bits in hflags, leading to an abort in gen_branch because the hflags are now invalid.
+
+I suspect the best fix is to remove the instruction set condition from the delay slot check in gen_msa_branch.
+
+
+
+I've just found the same problem with gen_compute_branch1,
+
+00200008 jr at
+4540563a bc1any4f   $fcc0,0xffffffffbfc158ec
+
+The cause is the same - if the instruction set is wrong then the delay slot check is skipped.
+
+Thanks for reporting this issue. 
+In fact, branches in a delay slot is "undefined" in the pre-Release 6 architecture.
+MIPS architectre release 6 defines to signal Reserved Instruction exceptions for such cases.
+However as it was undefined, it is better to signal RI and carry on rather than stopping simulation.
+Hence I've made a patch for the msa case. 
+I will have a look into the other case. (sorry I've missed in the first place.)
+
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=075a1fe788d36b271ec2
+
+Thanks for that fix.  I've just noticed that the second part, in gen_compute_branch1, wasn't included, though.  Could you take a look at it?
+
+I found the exact same bug. Tested on several hosts and qemu releases. The newest one I tested was on FreeBSD 12.1 host and qemu-4.1.1_1 built from ports. 
+
+Instructions:
+  4000d0:	0320f809 	jalr	t9
+  4000d4:	45454545 	0x45454545         # bc1any4t $fcc1,0x800101f8
+
+I was running qemu-mips as:
+
+qemu-system-mipsel -s -m 1024 -M malta \
+        -kernel vmlinux-3.16.0-6-4kc-malta -initrd initrd.img-3.16.0-6-4kc-malta \
+	-device virtio-blk-pci,drive=hd0 -drive if=none,id=hd0,format=qcow2,file=debian_wheezy_mipsel_standard.qcow2    \
+	-append "root=/dev/vda1" \
+	-device virtio-net-pci,netdev=net0 \
+	-netdev user,id=net0,hostfwd=tcp::1666-:22,ipv6=off  \
+	-curses 
+
+abort() was in target/mips/translate.c:12945, in gen_branch().
+
+Doesn't really matter if the instruction is supported on given CPU, user can crash the qemu within guest.
+
+Hi Brian,
+
+You try to execute a CP1 instruction in a delay slot,
+which triggers a Reserved Instruction exception.
+Per the ISA the processor operation is UNPREDICTABLE in such case.
+
+What is the behavior on real hardware?
+An assertion() seems appropriate.
+
+Your compiler might be buggy, or you are not compiling for the correct CPU
+(or you are not using the correct QEMU cpu).
+
+I don't know how Brian go to his state. 
+
+I should've mentioned though I was using custom binary (shellcode) that triggered this behavior. This code was not generated by compiler.
+
+However, I wanted to point out that user can crash the qemu host by running custom code from userspace. 
+
+Unfortunately I can't test this behavior on real HW right now. 
+
+Yeah, QEMU crashing is definitely a bug that we should fix. (NB that it's not a 'security' bug, though -- we make no guarantee that malicious code run under QEMU with TCG emulation is unable to escape from it: there's too much unaudited and old code for us to be able to safely make that guarantee.)
+
+
+When I reread the thread I see Brian was doing some testing/fuzzing, that's why he found that out. 
+
+I managed to get my old router running. It's BCM5354 (BCM3302 v2.9) running on Linux 2.4.35.
+I used the following code (gnu as compiled but replaced the nop after branch with the branch instruction above):
+
+  4000d0:	10000003 	b	4000e0 <__start+0x10>
+  4000d4:	45454545 	0x45454545
+	...
+  4000e0:	2404002a 	li	a0,42
+  4000e4:	24020fa1 	li	v0,4001
+  4000e8:	0000000c 	syscall
+  4000ec:	00000000 	nop
+
+Program was terminated with the trap Illegal instruction.
+
+
+If my memory is correct, this problem doesn't need qemu to execute the code, it only needs it to translate the code.  In the original test case the invalid instructions were actually dead code but still managed to crash qemu.
+
+I suggest following Yongbok Kim's approach and signalling Reserved Instruction in the same way R6 does.  I think that's architecturally allowed, although I admit that it's ages since I looked at this.
+
+
+This is an automated cleanup. This bug report has been moved
+to QEMU's new bug tracker on gitlab.com and thus gets marked
+as 'expired' now. Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/63
+
+
diff --git a/results/classifier/118/KVM/1677247 b/results/classifier/118/KVM/1677247
new file mode 100644
index 000000000..467f19774
--- /dev/null
+++ b/results/classifier/118/KVM/1677247
@@ -0,0 +1,51 @@
+KVM: 0.917
+kernel: 0.889
+ppc: 0.861
+virtual: 0.823
+graphic: 0.812
+user-level: 0.775
+device: 0.765
+architecture: 0.675
+mistranslation: 0.667
+performance: 0.665
+debug: 0.655
+PID: 0.646
+register: 0.612
+files: 0.597
+hypervisor: 0.590
+permissions: 0.526
+vnc: 0.518
+semantic: 0.508
+peripherals: 0.478
+risc-v: 0.448
+x86: 0.429
+arm: 0.425
+network: 0.418
+TCG: 0.397
+VMM: 0.394
+boot: 0.378
+socket: 0.302
+assembly: 0.277
+i386: 0.259
+
+QEMU e500 kvm no video and kernel crashing in virtios modules
+
+Hi,
+i been attached the log of my issue on Qoriq e5500
+when i start qemu-system-ppc64  -cpu e5500 -M ppce500 --enable-kvm -device virtio-gpu-pci  --nodefaults -display gtk and so and so . i have crashes in virtio modules in the VM and continue traces on the host machine.
+If is needed more for investigating ask freely .
+
+Note: i use my selfmade kernel this machine dont have a distro kenels and official kernels.
+
+
+Ciao 
+Luigi
+
+
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1682128 b/results/classifier/118/KVM/1682128
new file mode 100644
index 000000000..8358d5d3c
--- /dev/null
+++ b/results/classifier/118/KVM/1682128
@@ -0,0 +1,36 @@
+KVM: 0.984
+mistranslation: 0.945
+virtual: 0.922
+graphic: 0.893
+device: 0.853
+semantic: 0.745
+performance: 0.734
+architecture: 0.679
+arm: 0.638
+hypervisor: 0.632
+socket: 0.527
+boot: 0.512
+permissions: 0.441
+debug: 0.364
+register: 0.361
+network: 0.334
+risc-v: 0.321
+peripherals: 0.272
+PID: 0.260
+user-level: 0.240
+i386: 0.203
+files: 0.184
+vnc: 0.174
+ppc: 0.172
+TCG: 0.147
+assembly: 0.128
+x86: 0.074
+VMM: 0.041
+kernel: 0.033
+
+solaris can't power off
+
+I have created solaris 10 VM on KVM. Everything in VM is running OK, but finally I use shell command ‘poweroff’ or ‘init 5’, the solaris VM system could’t be poweroff but with promoting me the message: perss any key to reboot ….. 
+
+but on Xen, solaris can be powerofff
+
diff --git a/results/classifier/118/KVM/1686350 b/results/classifier/118/KVM/1686350
new file mode 100644
index 000000000..43b4dee69
--- /dev/null
+++ b/results/classifier/118/KVM/1686350
@@ -0,0 +1,81 @@
+KVM: 0.927
+kernel: 0.746
+x86: 0.744
+architecture: 0.742
+virtual: 0.618
+performance: 0.572
+device: 0.531
+semantic: 0.500
+hypervisor: 0.405
+user-level: 0.400
+VMM: 0.367
+graphic: 0.354
+PID: 0.303
+permissions: 0.295
+socket: 0.295
+debug: 0.271
+network: 0.270
+mistranslation: 0.233
+arm: 0.223
+boot: 0.187
+assembly: 0.177
+ppc: 0.162
+risc-v: 0.160
+peripherals: 0.158
+files: 0.144
+register: 0.137
+i386: 0.129
+vnc: 0.124
+TCG: 0.068
+
+[KVM] The qemu ‘-cpu’ option not have skylake server cpu model
+
+Environment:
+-------------------
+KVM commit/branch: bd17117b/next
+Qemu commit/branch: cd1ea508/master
+Host OS: RHEL7.3 ia32e
+Host Kernel:4.11.0-rc3
+Bug detailed description:
+----------------------------------
+In latest qemu commit the qemu still not have skylake server cpu model
+Reproduce steps:
+-------------------------
+[root@skl-2s2 ~]# qemu-system-x86_64 -cpu help
+Available CPUs:
+x86 486
+x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX)
+x86 Broadwell Intel Core Processor (Broadwell)
+x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2)
+x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX)
+x86 Haswell Intel Core Processor (Haswell)
+x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge)
+x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7)
+x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron)
+x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron)
+x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron)
+x86 Opteron_G4 AMD Opteron 62xx class CPU
+x86 Opteron_G5 AMD Opteron 63xx class CPU
+x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2)
+x86 SandyBridge Intel Xeon E312xx (Sandy Bridge)
+x86 Skylake-Client Intel Core Processor (Skylake)
+x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C)
+x86 athlon QEMU Virtual CPU version 2.5+
+x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz
+x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz
+x86 kvm32 Common 32-bit KVM processor
+x86 kvm64 Common KVM processor
+x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz
+x86 pentium
+x86 pentium2
+x86 pentium3
+x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor
+x86 qemu32 QEMU Virtual CPU version 2.5+
+x86 qemu64 QEMU Virtual CPU version 2.5+
+x86 base base CPU model type with no features enabled
+x86 host KVM processor with all supported host features (only available in KVM mode)
+x86 max Enables all features supported by the accelerator in the current host
+
+The Skylake-Server cpu type was added for either QEMU 3.0 or 3.1, so this bug is fix-released.
+
+
diff --git a/results/classifier/118/KVM/1688 b/results/classifier/118/KVM/1688
new file mode 100644
index 000000000..a16443462
--- /dev/null
+++ b/results/classifier/118/KVM/1688
@@ -0,0 +1,63 @@
+KVM: 0.978
+kernel: 0.965
+graphic: 0.899
+risc-v: 0.885
+virtual: 0.838
+semantic: 0.835
+device: 0.835
+register: 0.828
+performance: 0.789
+network: 0.740
+files: 0.706
+architecture: 0.699
+socket: 0.684
+PID: 0.678
+VMM: 0.655
+vnc: 0.628
+mistranslation: 0.627
+hypervisor: 0.578
+debug: 0.568
+arm: 0.547
+peripherals: 0.492
+ppc: 0.485
+boot: 0.459
+permissions: 0.452
+i386: 0.408
+x86: 0.385
+TCG: 0.343
+assembly: 0.330
+user-level: 0.307
+
+target/riscv KVM_RISCV_SET_TIMER macro is not configured correctly
+Description of problem:
+When riscv kvm vm state changed, guest virtual time would stop/continue. But KVM_RISCV_SET_TIMER is wrong, qemu-kvm can only set 'time'.
+Steps to reproduce:
+1.start host kernel
+2.start qemu-kvm
+Additional information:
+Below code has some probelm:
+```
+===================================================================
+#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
+    do { \
+        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), &reg); \
+
+===================================================================
+```
+I think it should be like this:
+
+```
+diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
+index 30f21453d6..0c567f668c 100644
+--- a/target/riscv/kvm.c
++++ b/target/riscv/kvm.c
+@@ -99,7 +99,7 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type,
+
+ #define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
+     do { \
+-        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), &reg); \
++        int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), &reg); \
+         if (ret) { \
+             abort(); \
+         } \
+```
diff --git a/results/classifier/118/KVM/1715203 b/results/classifier/118/KVM/1715203
new file mode 100644
index 000000000..527a24de0
--- /dev/null
+++ b/results/classifier/118/KVM/1715203
@@ -0,0 +1,346 @@
+KVM: 0.873
+hypervisor: 0.856
+virtual: 0.853
+peripherals: 0.850
+VMM: 0.846
+x86: 0.839
+permissions: 0.836
+register: 0.829
+graphic: 0.812
+PID: 0.809
+semantic: 0.806
+ppc: 0.801
+vnc: 0.800
+assembly: 0.794
+device: 0.785
+architecture: 0.780
+TCG: 0.773
+arm: 0.769
+network: 0.766
+performance: 0.765
+debug: 0.760
+risc-v: 0.758
+files: 0.744
+kernel: 0.743
+boot: 0.731
+socket: 0.721
+user-level: 0.701
+mistranslation: 0.613
+i386: 0.455
+
+Maintain Haiku support
+
+It was pointed out that the 2.10 release notes are pushing to drop Haiku support.  The qemu port is currently working as-is under Haiku.
+
+Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped?
+
+We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete?
+
+On 5 September 2017 at 18:55, kallisti5 <email address hidden> wrote:
+> It was pointed out that the 2.10 release notes are pushing to drop Haiku
+> support.  The qemu port is currently working as-is under Haiku.
+>
+> Was there a reason this was recommended? Is there anything Haiku can do
+> to keep it from being dropped?
+
+Basically we don't want to try to support host systems where we
+have no access to hardware that will let us compile and run
+the test suite, and where there's nobody interacting with us
+upstream to help fix issues that are Haiku related.
+
+If there's genuinely a community of Haiku QEMU users out there
+who want to help us maintain the support in the QEMU codebase that's
+great. What we don't want is to be carrying around code we can't
+test and where we don't seem to have anybody using it. (For instance
+we're about to drop support for AIX...)
+
+> We're working on a docker container to cross-compile rust-lang for
+> Haiku, could this be of some use to qemu when complete?
+
+Cross-compilation won't let us run the test suite.
+
+thanks
+-- PMM
+
+
+Haiku recently got a virtio driver, so running a Haiku system in cloud infrastructure seems possible now. (I've personally run it on vultr.com) Does QEMU have some infrastructure available so we can stand up a x86_64 system?
+
+On 5 September 2017 at 19:14, kallisti5 <email address hidden> wrote:
+> Haiku recently got a virtio driver, so running a Haiku system in cloud
+> infrastructure seems possible now. (I've personally run it on vultr.com)
+> Does QEMU have some infrastructure available so we can stand up a x86_64
+> system?
+
+Nope. We would be looking either for ssh login on a system somebody
+else admins, or detailed instructions on how to set up a VM for it,
+like the ones we have for BSD at https://wiki.qemu.org/index.php/Hosts/BSD
+
+thanks
+-- PMM
+
+
+Contacting our board of directors to see if I can get a VM deployed at Vultr. I'll keep this ticket updated.
+
+We're purchasing some new hardware, once we get it set up we'll setup a x86_64 Haiku machine to build qemu.
+
+Is there any update on this? Could you provide a machine with ssh login to the QEMU project where QEMU could be built and tested on Haiku? Or can Haiku be installed automatically without graphical UI interactions? In that case, would it be feasible that you provide a VM setup for our tests/vm/ files in QEMU?
+
+Hi!
+
+Sorry, I forgot about this one.
+
+Haiku has a lot of options.. we can setup a vm image if needed to move this along.
+Haiku is graphical, but has ssh and all the standard tools.
+
+Vagrant also supports Haiku and provides some automation around it.
+https://app.vagrantup.com/boxes/search?utf8=%E2%9C%93&sort=downloads&provider=&q=haiku-os
+
+Let me check out tests/vm/ to see if I can PR something.
+
+ok..  a Haiku vm for QEMU is WIP here:
+
+https://github.com/kallisti5/qemu/tree/haiku-test-vm
+
+
+
+```
+$ ./haiku.x86_64 --build-image --image /tmp/haiku.img
+### Downloading disk image ...
+### Preparing disk image ...
+./box.img
+100% repochecksum-1 [65 bytes]
+Validating checksum for Haiku...done.
+100% repocache-2 [4.25 KiB]
+Validating checksum for Haiku...done.
+100% repochecksum-1 [64 bytes]
+Validating checksum for HaikuPorts...done.
+100% repocache-2 [1.26 MiB]
+Validating checksum for HaikuPorts...done.
+The following changes will be made:
+  in system:
+    install package bzip2_devel-1.0.8-1 from repository HaikuPorts
+    install package libgpg_error_devel-1.36-1 from repository HaikuPorts
+    install package gettext-0.19.8.1-7 from repository HaikuPorts
+    install package ncurses6_devel-6.2-1 from repository HaikuPorts
+    install package libtasn1_devel-4.15.0-1 from repository HaikuPorts
+    install package capstone-4.0.2-1 from repository HaikuPorts
+    install package dtc-1.4.7-2 from repository HaikuPorts
+    install package libffi_devel-3.2.1-6 from repository HaikuPorts
+    install package libpcre_devel-8.44-1 from repository HaikuPorts
+    install package libiconv_devel-1.16-1 from repository HaikuPorts
+    install package lzo-2.10-2 from repository HaikuPorts
+    install package nettle-3.5.1-1 from repository HaikuPorts
+    install package pixman-0.38.4-1 from repository HaikuPorts
+    install package snappy-1.1.7-2 from repository HaikuPorts
+    install package libssh2-1.9.0-2 from repository HaikuPorts
+    install package libusb-1.0.23-1 from repository HaikuPorts
+    install package p11_kit-0.23.18.1-1 from repository HaikuPorts
+    install package libunistring-0.9.10-1 from repository HaikuPorts
+    install package libidn2-2.0.5-1 from repository HaikuPorts
+    install package libtool_libltdl-2.4.6-2 from repository HaikuPorts
+    install package file_data-5.38-1 from repository HaikuPorts
+    install package libgcrypt_devel-1.8.5-1 from repository HaikuPorts
+    install package glib2-2.62.0-3 from repository HaikuPorts
+    install package capstone_devel-4.0.2-1 from repository HaikuPorts
+    install package dtc_devel-1.4.7-2 from repository HaikuPorts
+    install package lzo_devel-2.10-2 from repository HaikuPorts
+    install package nettle_devel-3.5.1-1 from repository HaikuPorts
+    install package pixman_devel-0.38.4-1 from repository HaikuPorts
+    install package snappy_devel-1.1.7-2 from repository HaikuPorts
+    install package libssh2_devel-1.9.0-2 from repository HaikuPorts
+    install package libusb_devel-1.0.23-1 from repository HaikuPorts
+    install package p11_kit_devel-0.23.18.1-1 from repository HaikuPorts
+    install package gnutls-3.6.10-2 from repository HaikuPorts
+    install package libsdl2-2.0.10-1 from repository HaikuPorts
+    install package file-5.38-1 from repository HaikuPorts
+    install package gnutls_devel-3.6.10-2 from repository HaikuPorts
+    install package libsdl2_devel-2.0.10-1 from repository HaikuPorts
+    install package python3-3.7.7-2 from repository HaikuPorts
+    install package glib2_devel-2.62.0-3 from repository HaikuPorts
+Continue? [yes/no] (yes) : yes
+100% bzip2_devel-1.0.8-1-x86_64.hpkg [119.14 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/bzip2_devel-1.0.8-1-x86_64.hpkg...done.
+100% libgpg_error_devel-1.36-1-x86_64.hpkg [57.73 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgpg_error_devel-1.36-1-x86_64.hpkg...done.
+100% gettext-0.19.8.1-7-x86_64.hpkg [12.16 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gettext-0.19.8.1-7-x86_64.hpkg...done.
+100% ncurses6_devel-6.2-1-x86_64.hpkg [844.82 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/ncurses6_devel-6.2-1-x86_64.hpkg...done.
+100% libtasn1_devel-4.15.0-1-x86_64.hpkg [166.87 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtasn1_devel-4.15.0-1-x86_64.hpkg...done.
+100% capstone-4.0.2-1-x86_64.hpkg [1.80 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone-4.0.2-1-x86_64.hpkg...done.
+100% dtc-1.4.7-2-x86_64.hpkg [142.38 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc-1.4.7-2-x86_64.hpkg...done.
+100% libffi_devel-3.2.1-6-x86_64.hpkg [31.88 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libffi_devel-3.2.1-6-x86_64.hpkg...done.
+100% libpcre_devel-8.44-1-x86_64.hpkg [1.26 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libpcre_devel-8.44-1-x86_64.hpkg...done.
+100% libiconv_devel-1.16-1-x86_64.hpkg [901.83 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libiconv_devel-1.16-1-x86_64.hpkg...done.
+100% lzo-2.10-2-x86_64.hpkg [166.74 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo-2.10-2-x86_64.hpkg...done.
+100% nettle-3.5.1-1-x86_64.hpkg [890.41 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle-3.5.1-1-x86_64.hpkg...done.
+100% pixman-0.38.4-1-x86_64.hpkg [1.43 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman-0.38.4-1-x86_64.hpkg...done.
+100% snappy-1.1.7-2-x86_64.hpkg [34.08 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy-1.1.7-2-x86_64.hpkg...done.
+100% libssh2-1.9.0-2-x86_64.hpkg [423.77 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2-1.9.0-2-x86_64.hpkg...done.
+100% libusb-1.0.23-1-x86_64.hpkg [50.38 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb-1.0.23-1-x86_64.hpkg...done.
+100% p11_kit-0.23.18.1-1-x86_64.hpkg [987.54 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit-0.23.18.1-1-x86_64.hpkg...done.
+100% libunistring-0.9.10-1-x86_64.hpkg [610.86 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libunistring-0.9.10-1-x86_64.hpkg...done.
+100% libidn2-2.0.5-1-x86_64.hpkg [196.76 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libidn2-2.0.5-1-x86_64.hpkg...done.
+100% libtool_libltdl-2.4.6-2-x86_64.hpkg [64.24 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libtool_libltdl-2.4.6-2-x86_64.hpkg...done.
+100% file_data-5.38-1-any.hpkg [300.96 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file_data-5.38-1-any.hpkg...done.
+100% libgcrypt_devel-1.8.5-1-x86_64.hpkg [158.77 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libgcrypt_devel-1.8.5-1-x86_64.hpkg...done.
+100% glib2-2.62.0-3-x86_64.hpkg [4.10 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2-2.62.0-3-x86_64.hpkg...done.
+100% capstone_devel-4.0.2-1-x86_64.hpkg [1.03 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/capstone_devel-4.0.2-1-x86_64.hpkg...done.
+100% dtc_devel-1.4.7-2-x86_64.hpkg [88.46 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/dtc_devel-1.4.7-2-x86_64.hpkg...done.
+100% lzo_devel-2.10-2-x86_64.hpkg [314.15 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/lzo_devel-2.10-2-x86_64.hpkg...done.
+100% nettle_devel-3.5.1-1-x86_64.hpkg [39.87 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/nettle_devel-3.5.1-1-x86_64.hpkg...done.
+100% pixman_devel-0.38.4-1-x86_64.hpkg [1.81 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/pixman_devel-0.38.4-1-x86_64.hpkg...done.
+100% snappy_devel-1.1.7-2-x86_64.hpkg [8.90 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/snappy_devel-1.1.7-2-x86_64.hpkg...done.
+100% libssh2_devel-1.9.0-2-x86_64.hpkg [51.70 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libssh2_devel-1.9.0-2-x86_64.hpkg...done.
+100% libusb_devel-1.0.23-1-x86_64.hpkg [378.12 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libusb_devel-1.0.23-1-x86_64.hpkg...done.
+100% p11_kit_devel-0.23.18.1-1-x86_64.hpkg [19.07 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/p11_kit_devel-0.23.18.1-1-x86_64.hpkg...done.
+100% gnutls-3.6.10-2-x86_64.hpkg [1.52 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls-3.6.10-2-x86_64.hpkg...done.
+100% libsdl2-2.0.10-1-x86_64.hpkg [2.29 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2-2.0.10-1-x86_64.hpkg...done.
+100% file-5.38-1-x86_64.hpkg [103.26 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/file-5.38-1-x86_64.hpkg...done.
+100% gnutls_devel-3.6.10-2-x86_64.hpkg [285.23 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/gnutls_devel-3.6.10-2-x86_64.hpkg...done.
+100% libsdl2_devel-2.0.10-1-x86_64.hpkg [294.06 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/libsdl2_devel-2.0.10-1-x86_64.hpkg...done.
+100% python3-3.7.7-2-x86_64.hpkg [9.85 MiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/python3-3.7.7-2-x86_64.hpkg...done.
+100% glib2_devel-2.62.0-3-x86_64.hpkg [395.96 KiB]
+Validating checksum for https://eu.hpkg.haiku-os.org/haikuports/r1beta2/x86_64/current/packages/glib2_devel-2.62.0-3-x86_64.hpkg...done.
+[system] Applying changes ...
+[system] Changes applied. Old activation state backed up in "state_2020-09-05_14:46:23"
+[system] Cleaning up ...
+[system] Done.
+### All done ...
+```
+
+$ ./haiku.x86_64 --verbose --image /tmp/haiku.img uname
+Haiku
+
+./haiku.x86_64 --verbose --image /tmp/haiku.img "gcc -v"
+Using built-in specs.
+COLLECT_GCC=gcc
+COLLECT_LTO_WRAPPER=/boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-haiku/8.3.0/lto-wrapper
+Target: x86_64-unknown-haiku
+Configured with: /sources/gcc-8.3.0/configure --build=x86_64-unknown-haiku --prefix=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools --libexecdir=/packages/gcc-8.3.0_2019_05_24-7/.self/develop/tools/lib --mandir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/man --docdir=/packages/gcc-8.3.0_2019_05_24-7/.self/documentation/packages/gcc --enable-threads=posix --disable-nls --enable-shared --with-gnu-ld --with-gnu-as --enable-version-specific-runtime-libs --enable-languages=c,c++,fortran,objc --enable-lto --enable-frame-pointer --with-pkgversion=2019_05_24 --enable-__cxa-atexit --with-system-zlib --enable-checking=release --with-bug-url=http://dev.haiku-os.org/ --with-default-libstdcxx-abi=gcc4-compatible --enable-libssp --disable-multilib
+Thread model: posix
+gcc version 8.3.0 (2019_05_24) 
+
+
+and away we go..
+
+./haiku.x86_64 --image /tmp/haiku.img --build-qemu /home/kallisti5/Code/qemu
+Submodule 'dtc' (https://git.qemu.org/git/dtc.git) registered for path 'dtc'
+Submodule 'slirp' (https://git.qemu.org/git/libslirp.git) registered for path 'slirp'
+Submodule 'meson' (https://github.com/mesonbuild/meson/) registered for path 'meson'
+Submodule 'ui/keycodemapdb' (https://git.qemu.org/git/keycodemapdb.git) registered for path 'ui/keycodemapdb'
+Submodule 'tests/fp/berkeley-softfloat-3' (https://git.qemu.org/git/berkeley-softfloat-3.git) registered for path 'tests/fp/berkeley-softfloat-3'
+Submodule 'tests/fp/berkeley-testfloat-3' (https://git.qemu.org/git/berkeley-testfloat-3.git) registered for path 'tests/fp/berkeley-testfloat-3'
+cross containers  no
+
+NOTE: guest cross-compilers enabled: cc
+The Meson build system
+Version: 0.55.1
+Source dir: /boot/system/cache/tmp/qemu-test.oCwd7u/src
+Build dir: /boot/system/cache/tmp/qemu-test.oCwd7u/build
+Build type: native build
+Project name: qemu
+Project version: 5.1.50
+C compiler for the host machine: cc (gcc 8.3.0 "cc (2019_05_24) 8.3.0")
+C linker for the host machine: cc ld.bfd 2.31.1
+Host machine cpu family: x86_64
+Host machine cpu: x86_64
+../src/meson.build:10: WARNING: Module unstable-keyval has no backwards or forwards compatibility and might not exist in future releases.
+Program sh found: YES
+Program python3 found: YES (/boot/system/bin/python3)
+C++ compiler for the host machine: c++ (gcc 8.3.0 "c++ (2019_05_24) 8.3.0")
+C++ linker for the host machine: c++ ld.bfd 2.31.1
+Configuring ninjatool using configuration
+Library m found: YES
+Library util found: NO
+Library posix_error_mapper found: YES
+Library network found: YES
+Library bsd found: YES
+Found pkg-config: /boot/system/bin/pkg-config (0.29.2)
+Run-time dependency pixman-1 found: YES 0.38.4
+Library aio found: NO
+Run-time dependency zlib found: YES 1.2.11
+Run-time dependency xkbcommon found: NO (tried pkgconfig)
+Library rt found: NO
+Run-time dependency sdl2 found: YES 2.0.10
+Run-time dependency sdl2_image found: NO (tried pkgconfig)
+Run-time dependency libpng found: YES 1.6.37
+Has header "jpeglib.h" : YES 
+.
+.
+/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: error: 'O_BINARY' undeclared (first use in this function); did you mean 'L_INCR'?
+         spt->fd = open(spt->filename, O_RDONLY | O_BINARY);
+                                                  ^~~~~~~~
+                                                  L_INCR
+/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp/src/tftp.c:113:50: note: each undeclared identifier is reported only once for each function it appears in
+Makefile:45: recipe for target '/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o' failed
+make[1]: *** [/boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/tftp.o] Error 1
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: *** Waiting for unfinished jobs....
+make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+  CC      /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/util.o
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+  CC      /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/ip6_output.o
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+  CC      /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/state.o
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+  CC      /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/misc.o
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: Entering directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+  CC      /boot/system/cache/tmp/qemu-test.oCwd7u/build/slirp/src/bootp.o
+make[1]: Leaving directory '/boot/system/cache/tmp/qemu-test.oCwd7u/src/slirp'
+make[1]: *** wait: No child process.  Stop.
+Makefile:178: recipe for target 'slirp/all' failed
+make: *** [slirp/all] Error 2
+make: *** Waiting for unfinished jobs....
+python3 -B /tmp/qemu-test.oCwd7u/src/meson/meson.py introspect --tests | python3 -B scripts/mtest2make.py > Makefile.mtest
+./ninjatool -t ninja2make --omit clean dist uninstall cscope TAGS ctags < build.ninja > Makefile.ninja
+
+
+
+It looks like we have a few out-of-tree patches to fix that:
+
+https://github.com/haikuports/haikuports/blob/master/app-emulation/qemu/patches/qemu-2.11.1.patchset
+
+A patch for this work has been posted to the qemu-dev ML.
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=9fc33bf4e1d694225
+... the test suite is still failing, but at least we can compile test Haiku now. Thanks!
+
diff --git a/results/classifier/118/KVM/1754038 b/results/classifier/118/KVM/1754038
new file mode 100644
index 000000000..b259c2ffe
--- /dev/null
+++ b/results/classifier/118/KVM/1754038
@@ -0,0 +1,371 @@
+user-level: 0.943
+KVM: 0.922
+peripherals: 0.922
+hypervisor: 0.921
+permissions: 0.905
+TCG: 0.903
+VMM: 0.902
+performance: 0.877
+debug: 0.874
+device: 0.855
+graphic: 0.853
+arm: 0.848
+assembly: 0.847
+vnc: 0.839
+register: 0.829
+ppc: 0.822
+risc-v: 0.822
+boot: 0.812
+files: 0.811
+socket: 0.809
+PID: 0.808
+virtual: 0.808
+mistranslation: 0.797
+architecture: 0.793
+kernel: 0.793
+network: 0.792
+semantic: 0.790
+x86: 0.746
+i386: 0.742
+
+ARM M: Systick first wrap delayed (qemu-timers/icount prb?)
+
+When running this kind of code with qemu:
+
+static void SysTickISR(void)
+{
+	printf("SysTick\n");
+}
+
+void main()
+{
+	volatile int i, j;
+	printf("setup timer\n");
+	*(uint32_t*) 0xE000E014 = 0x8FFFFF; //reload value
+	*(uint32_t*) 0xE000E018 = 0;        //force reload
+	*(uint32_t*) 0xE000E010 = 7;        //cpu clk + ISR + enable 
+
+	for (j = 0; j < 0x100; j++) {
+		for (i = 0; i < 0x100000; i++)
+			;
+		printf("cnt %08x  -- %8x\n", *(uint32_t*) 0xE000E018, *(uint32_t*)0xE000E010);
+	}
+}
+
+I get the following output (comments added after '#'):
+
+setup timer
+cnt 007cccca  --        7
+cnt 006998a2  --        7
+cnt 00566479  --        7
+cnt 0043304f  --        7
+cnt 002ffc26  --        7
+cnt 001cc7fd  --        7
+cnt 000993d5  --        7
+cnt 00000000  --        7  <--- problem here, systick should wrap and raise isr
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+SysTick                     <--- delayed isr occuring here
+cnt 000986e0  --    10007
+SysTick
+cnt 00865290  --    10007   <---- then running fine as long as regs not modified
+cnt 00731e51  --        7
+cnt 005fea27  --        7
+cnt 004cb5ff  --        7
+cnt 003981d6  --        7
+cnt 00264dad  --        7
+cnt 00131984  --        7
+SysTick
+cnt 008fe545  --    10007
+cnt 007cb106  --        7
+cnt 00697cdd  --        7
+cnt 005648b4  --        7
+cnt 0043148b  --        7
+cnt 002fe061  --        7
+cnt 001cac38  --        7
+cnt 00097810  --        7
+SysTick
+cnt 008643d6  --    10007
+cnt 00730f97  --        7
+cnt 005fdb6d  --        7
+cnt 004ca745  --        7
+cnt 0039731c  --        7
+cnt 00263ef3  --        7
+cnt 00130aca  --        7
+SysTick
+cnt 008fd68b  --    10007
+cnt 007ca24c  --        7
+cnt 00696e23  --        7
+cnt 005639fa  --        7
+cnt 004305d1  --        7
+cnt 002fd1a8  --        7
+cnt 001c9d7f  --        7
+cnt 00096956  --        7
+SysTick
+cnt 0086351d  --    10007
+cnt 007300dd  --        7
+cnt 005fccb4  --        7
+cnt 004c988c  --        7
+cnt 00396463  --        7
+cnt 00263039  --        7
+cnt 0012fc10  --        7
+[...]
+
+Command line and version:
+qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -monitor stdio -serial file:/dev/pts/6 -icount 4 -cpu cortex-m4
+QEMU 2.11.50
+
+I am compiling from git repo, head is:
+commit f32408f3b472a088467474ab152be3b6285b2d7b
+Author: Daniel P. Berrangé <email address hidden>
+Date:   Tue Mar 6 13:43:17 2018 +0000
+
+Config options:
+./configure --target-list=arm-softmmu --enable-debug --disable-slirp --enable-tcg-interpreter --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native
+
+
+Not working with git tag 2.10.0 (almost same config)
+
+Working with stock qemu-arm 2.5.0 from Ubuntu 16.04.
+
+I started investigating, though I am not familiar with qemu code and I could see that the execution is not geting out of qemu_tcg_rr_cpu_thread_fn() 'while' loop and timers are not triggered because the values in cpu->icount_extra or cpu->icount_budget are not to modified accordingly after the timer is set (host side) when the systick register is written (target side).
+
+Delay between the counter hitting zero and the ISR firing is architecturally permitted (the interrupt must be recognized in finite time or at a context synchronizing event, but not necessarily at the same 'clock tick' that the counter hits zero). If you want to ensure that an interrupt has been taken before you read the counter value, you need to use an ISB instruction in your loop.
+
+(There are also some buggy behaviours in our systick device implementation, but in this case I don't think you're running into them.)
+
+
+I tried to insert an ISB in the loop but I get more or less the same result.
+
+However, I guess from your response that I did not explain the problem well enough. I understand that qemu will not be cycle accurate, however, here, we are not even "one million cycles accurate"! The counter would have the time to wrap twice before qemu is taking into account the first ISR... and if we check the following ISR time, we have a good accuracy, so I still think this is a bug.
+
+Morever, as said above, if I test with qemu 2.5.0 from Ubuntu package I get an accurate behavior:
+
+setup timer
+cnt 00799997  --        7
+cnt 0063323b  --        7
+cnt 004ccade  --        7
+cnt 00366383  --        7
+cnt 001ffc26  --        7
+cnt 000994ca  --        7
+SysTick
+cnt 00832d5e  --    10007
+cnt 006cc5eb  --        7
+cnt 00565e8f  --        7
+cnt 003ff733  --        7
+cnt 00298fd7  --        7
+cnt 0013287b  --        7
+SysTick
+cnt 008cc108  --    10007
+cnt 00765996  --        7
+cnt 005ff239  --        7
+cnt 00498add  --        7
+cnt 00332381  --        7
+cnt 001cbc24  --        7
+cnt 000654c8  --        7
+SysTick
+cnt 007fed5c  --    10007
+cnt 006985ea  --        7
+cnt 00531e8d  --        7
+cnt 003cb731  --        7
+cnt 00264fd5  --        7
+cnt 000fe879  --        7
+SysTick
+cnt 0089810c  --    10007
+cnt 0073199a  --        7
+cnt 005cb23d  --        7
+[...]
+
+So here I would suspect either a regression in the code or a wrong combination of options when I compile it myself. I am trying to recompile version 2.5 myself to sort this out but I am running in other errors.
+
+
+
+OK, I will see if I can find some time to investigate this. Can you attach your guest binary, please?
+
+
+Please find the binary attached.
+
+I have been trying several versions and it looks like the regression occured between v2.8.0 and v2.9.0.
+
+
+Ok I spent more time trying to identify the commits giving problem.
+
+So before 8d04fb5, qemu is executing the binary as expected:
+
+setup timer
+cnt 007cccca  --        7
+cnt 006998a2  --        7
+cnt 00566479  --        7
+cnt 0043304f  --        7
+cnt 002ffc26  --        7
+cnt 001cc7fd  --        7
+cnt 000993d5  --        7
+SysTick
+cnt 00865f9c  --    10007
+cnt 00732b5c  --        7
+cnt 005ff733  --        7
+cnt 004cc30a  --        7
+[...]
+
+
+Then, after this commit "tcg: drop global lock during TCG code execution":
+
+https://git.qemu.org/?p=qemu.git;a=commit;h=8d04fb55dec381bc5105cb47f29d918e579e8cbd
+
+things start to look bad (but not the same way I first ran into):
+
+setup timer
+SysTick
+cnt 00000000  --    10007
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 008ff3e3  --        7
+cnt 007cbfba  --        7
+cnt 00698b92  --        7
+cnt 00565768  --        7
+cnt 0043233f  --        7
+cnt 002fef16  --        7
+cnt 001cbaed  --        7
+cnt 000986c5  --        7
+SysTick
+cnt 0086528b  --    10007
+cnt 00731e4c  --        7
+cnt 005fea23  --        7
+cnt 004cb5fa  --        7
+cnt 003981d1  --        7
+[...]
+
+Then, not long after, this commit changes a little bit the prb "icount: process QEMU_CLOCK_VIRTUAL timers in vCPU thread"
+
+https://git.qemu.org/?p=qemu.git;a=commit;h=6b8f0187a4d7c263e356302f8d308655372a4b5b    
+
+Output then looks like:
+
+setup timer
+cnt 007cccca  --        7
+cnt 006998a2  --        7
+cnt 00566479  --        7
+cnt 0043304f  --        7
+cnt 002ffc26  --        7
+cnt 001cc7fd  --        7
+cnt 000993d5  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+cnt 00000000  --        7
+SysTick
+cnt 000986e0  --    10007
+SysTick
+cnt 00865290  --    10007
+cnt 00731e51  --        7
+cnt 005fea27  --        7
+[...]
+
+... and it seems this very problem has been occurring up to now.
+
+I am here using the binary attached, with this command line:
+
+qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4
+
+And with these build options:
+
+./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-tcmalloc --disable-jemalloc --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-pie --extra-cflags=-mtune=native
+
+Note that, to prevent MTTCG/icount error, we must modify configure for the arm target with:
+
+     mttcg="no"
+
+
+
+
+I finally implemented a workaround to correct the problem:
+
+in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }" part, I added:
+
+        CPUState *cpu;
+        CPU_FOREACH(cpu) {
+            atomic_mb_set(&cpu->exit_request, 1);
+        }
+
+I do not understand more than 5% of the code I am messing up, so this hack is probably broken...
+
+Then I tested a bit more the code with different testcases... and I found a new bug when writing a reload value smaller than the current counter (the counter will then read as 0). It is due to this piece of code in armv7m_systick.c : systick_read() :
+
+        /* The interrupt in triggered when the timer reaches zero.
+           However the counter is not reloaded until the next clock
+           tick.  This is a hack to return zero during the first tick.  */
+        if (val > s->reload) {
+            val = 0;
+        }
+
+Well this is not really a prb for me with normal code, and it looks like under control, but I can open another bug if needed.
+
+
+
+The workaround I described above is actually not the good one, because of this check occurring just before:
+
+    if (!all_cpu_threads_idle()) {
+        return;
+    }
+
+The exit request setting must be done before, so my code looks like this:
+
+
+    CPUState *cpu;
+    CPU_FOREACH(cpu) {
+        atomic_mb_set(&cpu->exit_request, 1);
+    }
+
+    if (!all_cpu_threads_idle()) {
+        return;
+    }
+
+(version is v2.11.0-2122-g9fa673c-dirty)
+
+
+
+
+Thanks for the test case; that was very useful. I've sent a patch which should fix this bug:
+https://patchwork.ozlabs.org/patch/895693/
+
+The "writing a reload value smaller than the current counter" bug is one of the ones I know about in our systick implementation. I may have time to overhaul that code in the 2.13 timeframe.
+
+
+Hi Peter,
+
+I just tested your patch, I confirm it is also working on my side. Many thanks.
+
+Now fixed in master, commit c52e7132d7c885, and will be in 2.12.0.
+
diff --git a/results/classifier/118/KVM/1774605 b/results/classifier/118/KVM/1774605
new file mode 100644
index 000000000..5446e1acd
--- /dev/null
+++ b/results/classifier/118/KVM/1774605
@@ -0,0 +1,127 @@
+KVM: 0.834
+mistranslation: 0.821
+ppc: 0.809
+hypervisor: 0.804
+graphic: 0.803
+user-level: 0.797
+permissions: 0.777
+peripherals: 0.768
+register: 0.767
+TCG: 0.750
+performance: 0.746
+device: 0.742
+boot: 0.729
+x86: 0.714
+virtual: 0.713
+assembly: 0.712
+kernel: 0.707
+risc-v: 0.706
+socket: 0.702
+semantic: 0.701
+vnc: 0.700
+arm: 0.697
+architecture: 0.682
+debug: 0.681
+files: 0.680
+network: 0.652
+PID: 0.652
+VMM: 0.624
+i386: 0.594
+
+PowerPC guest does not emulate L2 and L3 cache for KVM vCPUs
+
+PowerPC KVM guest does not emulate L2 and L2 caches for vCPU, it would be good to have them enabled if not any known issues/limitation already with PowerPC.
+
+Host Env:
+kernel: 4.17.0-rc7-00045-g0512e0134582
+qemu: v2.12.0-923-gc181ddaa17-dirty
+#libvirtd -V
+libvirtd (libvirt) 4.4.0
+
+
+Guest Kernel:
+# uname -a
+Linux atest-guest 4.17.0-rc7-00045-g0512e0134582 #9 SMP Fri Jun 1 02:55:50 EDT 2018 ppc64le ppc64le ppc64le GNU/Linux
+
+Guest:
+# lscpu
+Architecture:        ppc64le
+Byte Order:          Little Endian
+CPU(s):              16
+On-line CPU(s) list: 0-15
+Thread(s) per core:  8
+Core(s) per socket:  2
+Socket(s):           1
+NUMA node(s):        1
+Model:               2.1 (pvr 004b 0201)
+Model name:          POWER8 (architected), altivec supported
+Hypervisor vendor:   KVM
+Virtualization type: para
+L1d cache:           64K
+L1i cache:           32K
+NUMA node0 CPU(s):   0-15
+
+
+
+background: x86 enabling cpu L2 cache bydefault and L3 cache on demand for kvm guest
+and claims performance improvement as vcpus can be 
+benefited with lesser `vmexits due to guest send IPIs.` with L3 cache enabled, below was patch for same.
+
+https://git.qemu.org/?p=qemu.git;a=commit;h=14c985cffa6cb177fc01a163d8bcf227c104718c
+
+Guest xml(cpu portion):
+
+...
+   <vcpu placement='static' current='16'>32</vcpu>
+  <resource>
+    <partition>/machine</partition>
+  </resource>
+  <os>
+    <type arch='ppc64le' machine='pseries-2.13'>hvm</type>
+    <kernel>/home/kvmci/linux/vmlinux</kernel>
+    <cmdline>root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug</cmdline>
+    <boot dev='hd'/>
+  </os>
+  <cpu mode='host-passthrough' check='none'>
+    <topology sockets='2' cores='2' threads='8'/>
+  </cpu>
+...
+
+
+Host lscpu:
+# lscpu
+Architecture:         ppc64le
+Byte Order:           Little Endian
+CPU(s):               80
+On-line CPU(s) list:  0,8,16,24,32,40,48,56,64,72
+Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63,65-71,73-79
+Thread(s) per core:   1
+Core(s) per socket:   5
+Socket(s):            2
+NUMA node(s):         2
+Model:                2.1 (pvr 004b 0201)
+Model name:           POWER8E (raw), altivec supported
+CPU max MHz:          3690.0000
+CPU min MHz:          2061.0000
+L1d cache:            64K
+L1i cache:            32K
+L2 cache:             512K
+L3 cache:             8192K
+NUMA node0 CPU(s):    0,8,16,24,32
+NUMA node1 CPU(s):    40,48,56,64,72
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1775702 b/results/classifier/118/KVM/1775702
new file mode 100644
index 000000000..989340618
--- /dev/null
+++ b/results/classifier/118/KVM/1775702
@@ -0,0 +1,113 @@
+KVM: 0.814
+ppc: 0.768
+x86: 0.749
+performance: 0.720
+TCG: 0.706
+register: 0.691
+user-level: 0.687
+risc-v: 0.682
+vnc: 0.672
+mistranslation: 0.664
+hypervisor: 0.662
+VMM: 0.661
+debug: 0.636
+peripherals: 0.618
+kernel: 0.616
+PID: 0.569
+device: 0.564
+permissions: 0.557
+arm: 0.546
+network: 0.544
+assembly: 0.542
+semantic: 0.541
+architecture: 0.535
+virtual: 0.519
+graphic: 0.516
+boot: 0.513
+socket: 0.484
+files: 0.448
+i386: 0.446
+
+High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803
+
+After upgrading Windows 10 guest to version 1803, guests VM runs slower and there is high host CPU load even when guest is almost idle. Did not happened with windows 10 up to version 1709.
+
+See my 1st report here:
+https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803
+
+Another user report is here:
+https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/
+
+Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu 2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three platform showing the same slowdown and higher host cpu load with windows 10 1803 VM compared to windows 10 1709 VM.
+
+This bug affect me
+
+I ran into similar issues with Windows 10 (1803), with regard to 2D graphics performance.
+
+See my bug report here: https://bugzilla.kernel.org/show_bug.cgi?id=200877
+
+Could you test with Spectre protection (temporarily) turned off inside the Windows VM?
+
+See my post here: https://heiko-sieger.info/low-2d-graphics-benchmark-with-windows-10-1803-kvm-vm/
+
+
+
+Hi,
+proxmox users have reported this bug
+https://forum.proxmox.com/threads/high-cpu-load-for-windows-10-guests-when-idle.44531/#post-213876
+
+hv_synic && hv_stimer  hyperv enlightments fix it
+
+
+(seem to be related to some hpet change in windows)
+
+
+
+----- Mail original -----
+De: "Lemos Lemosov" <email address hidden>
+À: "qemu-devel" <email address hidden>
+Envoyé: Mercredi 1 Août 2018 08:43:46
+Objet: [Qemu-devel] [Bug 1775702] Re: High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803
+
+This bug affect me 
+
+-- 
+You received this bug notification because you are a member of qemu- 
+devel-ml, which is subscribed to QEMU. 
+https://bugs.launchpad.net/bugs/1775702 
+
+Title: 
+High host CPU load and slower guest after upgrade guest OS Windows 10 
+to ver 1803 
+
+Status in QEMU: 
+New 
+
+Bug description: 
+After upgrading Windows 10 guest to version 1803, guests VM runs 
+slower and there is high host CPU load even when guest is almost idle. 
+Did not happened with windows 10 up to version 1709. 
+
+See my 1st report here: 
+https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803 
+
+Another user report is here: 
+https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/ 
+
+Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu 
+2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three 
+platform showing the same slowdown and higher host cpu load with 
+windows 10 1803 VM compared to windows 10 1709 VM. 
+
+To manage notifications about this bug go to: 
+https://bugs.launchpad.net/qemu/+bug/1775702/+subscriptions 
+
+
+
+hv_synic && hv_stimer only reduces the cpu from 40-50% to 4-5%.
+still expecting under 1% like linux guests.
+
+I found that C:\Program Files (x86)\SPICE Guest Tools\drivers\Balloon\w10\amd64/blnsvr.exe intensively requesting something in WMI-provider-host. And there are a lot of errors in event logs about it also.
+
+Gannet, SPICE Guest Tools is certainly a different problem, you should report that to the spice project instead. And since the original problem was apparently fixed via hv_synic / hv_stimer (if I got the comments right), I'm closing this ticket now.
+
diff --git a/results/classifier/118/KVM/1834051 b/results/classifier/118/KVM/1834051
new file mode 100644
index 000000000..96df2309b
--- /dev/null
+++ b/results/classifier/118/KVM/1834051
@@ -0,0 +1,57 @@
+KVM: 0.947
+i386: 0.831
+device: 0.656
+performance: 0.650
+hypervisor: 0.648
+architecture: 0.646
+semantic: 0.627
+graphic: 0.621
+kernel: 0.614
+user-level: 0.601
+peripherals: 0.594
+network: 0.578
+ppc: 0.577
+socket: 0.552
+mistranslation: 0.544
+virtual: 0.539
+permissions: 0.517
+files: 0.496
+debug: 0.495
+x86: 0.491
+register: 0.461
+vnc: 0.454
+risc-v: 0.426
+PID: 0.390
+boot: 0.371
+assembly: 0.344
+VMM: 0.321
+TCG: 0.321
+arm: 0.296
+
+IRQ2 ignored under KVM when using IOAPIC
+
+When using KVM, and an OS that supports the IOAPIC, interrupts mapped on IRQ2 (for instance, routing an HPET timer on interrupt 2) will cause the interrupts to never be delivered. This is because QEmu, when setting up the KVM interrupt routes, will not set one up for IRQ2[0]. When running without KVM, IRQ2 is identity-mapped to GSI2.
+
+My understanding is that IRQs should be identity mapped to their equivalent GSI unless a redirection entry is present in the MADT. This is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override Structure, which claims: "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources.".
+
+I stumbled across this while working on my own custom OS, got very confused why the HPET wasn't triggering any interruption - and even more confused why the behavior only happened in KVM and not in non-KVM.
+
+[0]: https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40
+
+[1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1848244 b/results/classifier/118/KVM/1848244
new file mode 100644
index 000000000..5fccd8422
--- /dev/null
+++ b/results/classifier/118/KVM/1848244
@@ -0,0 +1,46 @@
+KVM: 0.896
+ppc: 0.668
+x86: 0.663
+architecture: 0.661
+graphic: 0.637
+device: 0.615
+kernel: 0.480
+PID: 0.444
+semantic: 0.435
+performance: 0.432
+mistranslation: 0.383
+boot: 0.296
+peripherals: 0.293
+debug: 0.273
+VMM: 0.265
+TCG: 0.214
+virtual: 0.212
+hypervisor: 0.181
+socket: 0.181
+network: 0.176
+register: 0.160
+vnc: 0.155
+arm: 0.139
+user-level: 0.120
+permissions: 0.114
+risc-v: 0.082
+assembly: 0.073
+files: 0.025
+i386: 0.018
+
+QEMU KVM IGD SandyBridge Passthrough crash
+
+I try to passthrough my Intel GPU with this command:
+
+qemu-system-x86_64 -nodefaults -parallel none -k de -rtc base=localtime -serial unix:/run/qemu/win7-serial.sock,server,nowait -monitor unix:/run/qemu/win7-monitor.sock,server,nowait -netdev user,id=net0 -device virtio-net-pci,netdev=net0,mac=52:54:00:00:00:07 -device vfio-pci,host=0000:00:02.0,addr=0x2 -device vfio-pci,host=0000:00:1b.0 -device virtio-keyboard-pci -device virtio-mouse-pci -object input-linux,id=kbd1,evdev=/dev/input/by-path/pci-0000:00:1a.0-usb-0:1.2.2:1.2-event-kbd,grab_all=on,repeat=on -object input-linux,id=mouse1,evdev=/dev/input/by-path/pci-0000:00:1a.0-usb-0:1.2.2:1.2-event-mouse -enable-kvm -cpu host -smp 4,sockets=1,cores=4,threads=1 -vga none -display none -m 2g -device virtio-blk-pci,drive=boot,bootindex=1 -drive file=/opt/vm/qcow2/win7.qcow2,format=qcow2,if=none,id=boot
+
+This ONLY works if i remove "-enable-kvm" else the windows (7 and 10) boot crashes in bluescreen "stop 0x0000003b" (probably while loading the intel gpu driver (intel graphics 3000).
+
+The system is an older ThinkPad T420 with Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz.
+
+CMDLINE: BOOT_IMAGE=/vmlinuz-linux root=LABEL=root rw ipv6.disable=0 net.ifnames=0 intel_iommu=on iommu=pt video=LVDS-1:d
+
+Solved: I added kvm.ignore_msrs=1 to kernel parameter!
+
+I'm closing this now since there seems to be a workaround available and nobody updated this bug in the past 1.5 years anymore
+
diff --git a/results/classifier/118/KVM/1859310 b/results/classifier/118/KVM/1859310
new file mode 100644
index 000000000..d2618ce07
--- /dev/null
+++ b/results/classifier/118/KVM/1859310
@@ -0,0 +1,53 @@
+KVM: 0.975
+i386: 0.960
+architecture: 0.925
+device: 0.916
+register: 0.905
+x86: 0.869
+semantic: 0.804
+mistranslation: 0.791
+PID: 0.776
+performance: 0.765
+socket: 0.751
+graphic: 0.745
+hypervisor: 0.707
+ppc: 0.672
+permissions: 0.644
+virtual: 0.621
+kernel: 0.620
+network: 0.593
+peripherals: 0.588
+user-level: 0.547
+vnc: 0.542
+risc-v: 0.542
+TCG: 0.540
+files: 0.530
+debug: 0.507
+VMM: 0.480
+arm: 0.473
+boot: 0.425
+assembly: 0.157
+
+libvirt probing fails due to assertion failure with KVM and 'none' machine type
+
+Using libvirt on Ubuntu 19.10, I get the following error when I try to set <emulator> to the latest qemu from git (commit dc65a5bdc9):
+
+    error: internal error: Failed to start QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: /home/joey/git/qemu/target/i386/kvm.c:2176:kvm_arch_init: Object 0x564bfd5c3200 is not an instance of type x86-machine
+
+Qemu command line to reproduce:
+
+    sudo x86_64-softmmu/qemu-system-x86_64 -machine 'none,accel=kvm'
+
+Commit ed9e923c3c (Dec 12, 2019) introduced the issue by removing an object_dynamic_cast call.  In this scenario, kvm_arch_init is passed an instance of "none-machine" instead of "x86-machine".
+
+The following one-line change to target/i386/kvm.c reintroduces the cast:
+
+     if (kvm_check_extension(s, KVM_CAP_X86_SMM) &&
++        object_dynamic_cast(OBJECT(ms), TYPE_X86_MACHINE) &&
+         x86_machine_is_smm_enabled(X86_MACHINE(ms))) {
+         smram_machine_done.notify = register_smram_listener;
+         qemu_add_machine_init_done_notifier(&smram_machine_done);
+     }
+
+This was fixed in commit 8f54bbd0b4 "x86: Check for machine state object class before typecasting it".
+
diff --git a/results/classifier/118/KVM/1863819 b/results/classifier/118/KVM/1863819
new file mode 100644
index 000000000..807f50bca
--- /dev/null
+++ b/results/classifier/118/KVM/1863819
@@ -0,0 +1,76 @@
+architecture: 0.948
+KVM: 0.931
+graphic: 0.916
+ppc: 0.902
+user-level: 0.887
+debug: 0.880
+performance: 0.869
+virtual: 0.852
+semantic: 0.848
+files: 0.810
+assembly: 0.769
+socket: 0.761
+kernel: 0.740
+vnc: 0.739
+peripherals: 0.726
+device: 0.711
+permissions: 0.708
+risc-v: 0.708
+register: 0.690
+network: 0.688
+mistranslation: 0.657
+PID: 0.602
+boot: 0.520
+hypervisor: 0.518
+x86: 0.505
+VMM: 0.492
+arm: 0.485
+i386: 0.358
+TCG: 0.324
+
+repeated KVM single step crashes leaks into SMP guest and crashes guest application
+
+Guest: Windows 7 x64
+Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic)
+QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3
+
+If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x80000004 exception (single step). This is easily reproducible on a Windows guest, I've not tried another guest type but I've been told it's the same there also.
+
+On a Ubuntu 16 host with an older kernel, this will hang the entire machine. However, it seems it may have been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cc244a20b86090c087073c124284381cdf47234 ?
+
+It's not clear to me whether this is a KVM or a QEMU bug. A TCG guest does not crash the userspace process in the same way, but it does hang the VM.
+
+I've tried a variety of QEMU versions (3.0, 4.2, master) and they all exhibit the same behavior. I'm happy to dig into this more if someone can point me in the right direction.
+
+Here's the outline for reproducing the bug:
+
+* Compile iloop.cpp (attached) as a 32-bit application using MSVC
+* Start Windows 7 x64 guest under GDB
+  * Pass '-enable-kvm -smp 4,cores=2 -gdb tcp::4567' to QEMU along with other typical options
+
+(need to get CR3 to ensure we're in the right application context -- if there's an easier way to do this I'd love to hear it!)
+* Install WinDBG on guest
+* Copy SysInternals LiveKD to guest
+* Start iloop.exe in guest, note loop address
+* Run LiveKD from administrative prompt
+  * livekd64.exe -w
+* In WinDBG:
+  * !process 0 0
+  * Search for iloop.exe, note DirBase (this is CR3)
+
+In GDB:
+* Execute 'target remote tcp::4567'
+* Execute 'c'
+* Hit CTRL-C to pause the VM
+* Execute 'p/x $cr3'
+  .. continue if not equal to DirBase in WinDBG, keep stopping until it is equal
+* Once $cr3 is correct value, if you 'stepi' a few times you'll note the process going in a loop, it should keep hitting the address echoed to the console by iloop.exe
+
+Crash the process from GDB:
+* Execute 'stepi 100000000'
+* Watch the process, eventually it'll die with an 0x80000004 error
+
+
+
+Some experimentation with newer kernels indicate that this is most likely a KVM bug.
+
diff --git a/results/classifier/118/KVM/1873340 b/results/classifier/118/KVM/1873340
new file mode 100644
index 000000000..9f633bdfa
--- /dev/null
+++ b/results/classifier/118/KVM/1873340
@@ -0,0 +1,56 @@
+KVM: 0.944
+hypervisor: 0.917
+virtual: 0.904
+kernel: 0.841
+device: 0.832
+socket: 0.749
+peripherals: 0.699
+architecture: 0.682
+boot: 0.631
+VMM: 0.609
+vnc: 0.604
+graphic: 0.595
+performance: 0.571
+files: 0.569
+arm: 0.558
+ppc: 0.554
+risc-v: 0.550
+permissions: 0.461
+x86: 0.448
+semantic: 0.406
+network: 0.397
+mistranslation: 0.378
+register: 0.371
+PID: 0.344
+debug: 0.318
+assembly: 0.260
+i386: 0.230
+user-level: 0.170
+TCG: 0.170
+
+KVM Old ATI(pre) AMD card passthrough is not working
+
+Hello,
+tried to passthroug old ATI pre AMD PCI / PCI-E cards, on machine where anything else is working - Nvidia /Matrox / 3dfx cards..
+
+Here are results:
+ATI Mach 64 PCI - videocard - machine start segfault
+ATI Rage XL PCI - videocard - machine start segfault
+ATI Radeon 7000 PCI - Segmentation fault
+ATI X600 Giabyte GV-RX60P128D - Segmentation fault
+ATI X700 PCI-E Legend - videocard - completely broken picture from boot
+ATI X800 XL PCI-E Gigabyte - videocard - completely broken picture from boot
+  All cards has last bioses.
+
+ATI X600 - HP one professional with DMS-59 connector, im unable to make passthrough, but im not able to set in Windows 98/WinXP machine.. anything less than 16 bit colors.. Im getting VM crashes or boot freezes, when i try to boot with more colors.
+
+ Qemu 2.11 and 4.2, is the same, Mint Linux 19.3.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/252
+
+
diff --git a/results/classifier/118/KVM/1873344 b/results/classifier/118/KVM/1873344
new file mode 100644
index 000000000..57fccd728
--- /dev/null
+++ b/results/classifier/118/KVM/1873344
@@ -0,0 +1,51 @@
+KVM: 0.898
+device: 0.715
+ppc: 0.680
+peripherals: 0.672
+hypervisor: 0.552
+vnc: 0.537
+architecture: 0.513
+performance: 0.464
+socket: 0.422
+boot: 0.417
+arm: 0.394
+semantic: 0.392
+kernel: 0.386
+graphic: 0.373
+mistranslation: 0.347
+files: 0.323
+permissions: 0.296
+register: 0.295
+risc-v: 0.279
+VMM: 0.249
+network: 0.235
+PID: 0.231
+TCG: 0.202
+debug: 0.197
+virtual: 0.179
+i386: 0.132
+x86: 0.126
+assembly: 0.119
+user-level: 0.115
+
+KVM Windows 98 sound card passthrough is not working for DOS programs..
+
+Hello,
+im trying to passthrough PCI soundcards into Qemu Windows 98 machine - i tried Yamaha 724/744 and Aunreal Vortex 1, for Windows 98 its working fine, but for Windows 98 dosbox mode its at the best half - working - FM (music) only or nothing with detected by games sound setups.
+  All there cards are using SB emulation devices. 
+
+  When i try to boot to pure DOS, without Windows 98, even music is not working with pass through, only sound which i was able to heard its form Yamaha Setup utility test - Native 16bit sound, aby other test, games setup etc.. are able to dettect sound cards at all. 
+  Im pretty sure that drivers are setup correctly, because im using same setup on other physical machine, when its working. My suspect is missing or broken Qemu MB DMA channels emulation.. Because its is need to make DOS sound working.
+
+  Im using pass through because, SB16 emulation in Qemu is incomplete and for Windows 98 dos box, problem is same as with physical cards. Same with AC97 emulation and its Win95 drivers, which have SB emulation device fallback..
+
+Qemu 2.11 + 4.2 Linux Mint 19.3. MB Gigabyte Z170.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/73
+
+
diff --git a/results/classifier/118/KVM/1877052 b/results/classifier/118/KVM/1877052
new file mode 100644
index 000000000..acaf85a5b
--- /dev/null
+++ b/results/classifier/118/KVM/1877052
@@ -0,0 +1,78 @@
+KVM: 0.954
+virtual: 0.894
+graphic: 0.873
+kernel: 0.872
+hypervisor: 0.872
+boot: 0.871
+user-level: 0.844
+performance: 0.804
+semantic: 0.784
+mistranslation: 0.674
+device: 0.614
+ppc: 0.584
+architecture: 0.582
+VMM: 0.556
+permissions: 0.535
+PID: 0.532
+register: 0.524
+risc-v: 0.510
+files: 0.509
+vnc: 0.504
+x86: 0.493
+debug: 0.476
+socket: 0.459
+network: 0.454
+i386: 0.444
+peripherals: 0.438
+arm: 0.435
+TCG: 0.362
+assembly: 0.345
+
+KVM Win 10 guest pauses after kernel upgrade
+
+
+
+Hello!
+Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time.
+
+Until yesterday it used to work and I was able to boot the VM. During the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active and then went into pause mode. Even after a reboot of my host system the problem still persists: the VM boots for a few seconds and then switches to pause mode.
+
+
+Kind regards,
+   Andreas
+
+
+
+
+
+
+
+
+
+Note: might be related (or not) to bug 1866870
+Let's analyze as independent and dup if it turns out to be a dup.
+
+The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are unrelated (in regard to guest hang).
+Those happen on
+a) too old kernels that don't support the feature
+b) mismatch of expectations of a chips vs its actual capabilities
+E.g. if libvirt thinks a feature should be supported by a chip, but isn't.
+There are toomany SKUs out there to be perfect - so these are red-herrings at best.
+
+I have not seen similar reports recently nor anyone else chiming in on this one.
+After loosing what e thought could be a track to the bgu I'm puzzled what to do now on this?
+
+@Andreas - did you in the meantime find any new insight on this?
+
+@Andreas - If we find nothing else to try I'll ping you when I have a newer qemu&libvirt build for Ubuntu 20.10 for you to try.
+
+I haven't seen any similar reports nor any updates here.
+Might I ask if you  have got any further since then?
+
+Qemu 5.0 is available in Ubuntu 20.10 now, if you are willing to upgrade or install a test system that might be worth a try (new libvirt is still WIP, but unlikely to play a role here).
+20.10 proposed would even have a 5.8.0.12.14 kernel since a kernel change might have been what started this that might be worth a check as well.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1878323 b/results/classifier/118/KVM/1878323
new file mode 100644
index 000000000..b904d1d08
--- /dev/null
+++ b/results/classifier/118/KVM/1878323
@@ -0,0 +1,99 @@
+KVM: 0.834
+mistranslation: 0.833
+peripherals: 0.824
+x86: 0.811
+user-level: 0.805
+hypervisor: 0.799
+graphic: 0.794
+VMM: 0.781
+register: 0.779
+risc-v: 0.773
+files: 0.771
+performance: 0.754
+ppc: 0.750
+vnc: 0.741
+TCG: 0.741
+semantic: 0.735
+virtual: 0.734
+device: 0.729
+arm: 0.717
+architecture: 0.714
+i386: 0.698
+permissions: 0.697
+assembly: 0.694
+debug: 0.662
+socket: 0.657
+PID: 0.637
+kernel: 0.622
+network: 0.593
+boot: 0.573
+
+Assertion-failure in usb_detach
+
+Hello,
+While fuzzing, I found an input that triggers an assertion-failure in usb_detach
+
+/home/alxndr/Development/qemu/hw/usb/core.c:69: void usb_detach(USBPort *): Assertion `dev->state != USB_STATE_NOTATTACHED' failed.
+#3  0x00007ffff6866092 in __GI___assert_fail (assertion=0x555557fd2040 <str> "dev->state != USB_STATE_NOTATTACHED", file=0x555557fd1ec0 <str> "/home/alxndr/Development/qemu/hw/usb/core.c", line=0x45, function=0x555557fd2000 <__PRETTY_FUNCTION__.usb_detach> "void usb_detach(USBPort *)") at assert.c:101
+#4  0x000055555723f0ce in usb_detach (port=0x62100002df30) at /home/alxndr/Development/qemu/hw/usb/core.c:69
+#5  0x00005555572a05a4 in ehci_reset (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:863
+#6  0x00005555572bf941 in ehci_opreg_write (ptr=0x62100002d9f0, addr=0x0, val=0xbebebebe, size=0x4) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1032
+#7  0x00005555564938b5 in memory_region_write_accessor (mr=0x62100002dcb0, addr=0x0, value=0x7fffffffaad0, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483
+#8  0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffffaad0, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62100002dcb0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544
+#9  0x0000555556491df6 in memory_region_dispatch_write (mr=0x62100002dcb0, addr=0x0, data=0xbebebebe, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476
+#10 0x00005555562cbbf4 in flatview_write_continue (fv=0x60600003e600, addr=0xe0000020, attrs=..., ptr=0x625000260000, len=0xfe0, addr1=0x0, l=0x4, mr=0x62100002dcb0) at /home/alxndr/Development/qemu/exec.c:3137
+#11 0x00005555562bbad9 in flatview_write (fv=0x60600003e600, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3177
+#12 0x00005555562bb609 in address_space_write (as=0x62100002d328, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3268
+#13 0x00005555562c06a6 in address_space_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, is_write=0x1, access_len=0x1000) at /home/alxndr/Development/qemu/exec.c:3592
+#14 0x0000555557257d73 in dma_memory_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, dir=DMA_DIRECTION_FROM_DEVICE, access_len=0x1000) at /home/alxndr/Development/qemu/include/sysemu/dma.h:145
+#15 0x0000555557257c57 in usb_packet_unmap (p=0x6110000484c0, sgl=0x611000048548) at /home/alxndr/Development/qemu/hw/usb/libhw.c:65
+#16 0x00005555572a5953 in ehci_free_packet (p=0x611000048480) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:536
+#17 0x00005555572a4ed4 in ehci_cancel_queue (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:584
+#18 0x00005555572a49ab in ehci_free_queue (q=0x60d000004f10, warn=0x0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:611
+#19 0x00005555572b102d in ehci_queues_rip_device (ehci=0x62100002d9f0, dev=0x623000001d00, async=0x1) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:674
+#20 0x00005555572af7a3 in ehci_detach (port=0x62100002df78) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:733
+#21 0x000055555723f15c in usb_detach (port=0x62100002df78) at /home/alxndr/Development/qemu/hw/usb/core.c:70
+#22 0x00005555572a05a4 in ehci_reset (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:863
+#23 0x00005555572bf941 in ehci_opreg_write (ptr=0x62100002d9f0, addr=0x0, val=0xbebebebe, size=0x4) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1032
+#24 0x00005555564938b5 in memory_region_write_accessor (mr=0x62100002dcb0, addr=0x0, value=0x7fffffffc410, size=0x4, shift=0x0, mask=0xffffffff, attrs=...) at /home/alxndr/Development/qemu/memory.c:483
+#25 0x000055555649328a in access_with_adjusted_size (addr=0x0, value=0x7fffffffc410, size=0x4, access_size_min=0x1, access_size_max=0x4, access_fn=0x555556493360 <memory_region_write_accessor>, mr=0x62100002dcb0, attrs=...) at /home/alxndr/Development/qemu/memory.c:544
+#26 0x0000555556491df6 in memory_region_dispatch_write (mr=0x62100002dcb0, addr=0x0, data=0xbebebebe, op=MO_32, attrs=...) at /home/alxndr/Development/qemu/memory.c:1476
+#27 0x00005555562cbbf4 in flatview_write_continue (fv=0x60600003e600, addr=0xe0000020, attrs=..., ptr=0x625000260000, len=0xfe0, addr1=0x0, l=0x4, mr=0x62100002dcb0) at /home/alxndr/Development/qemu/exec.c:3137
+#28 0x00005555562bbad9 in flatview_write (fv=0x60600003e600, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3177
+#29 0x00005555562bb609 in address_space_write (as=0x62100002d328, addr=0xe0000000, attrs=..., buf=0x625000260000, len=0x1000) at /home/alxndr/Development/qemu/exec.c:3268
+#30 0x00005555562c06a6 in address_space_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, is_write=0x1, access_len=0x1000) at /home/alxndr/Development/qemu/exec.c:3592
+#31 0x0000555557257d73 in dma_memory_unmap (as=0x62100002d328, buffer=0x625000260000, len=0x1000, dir=DMA_DIRECTION_FROM_DEVICE, access_len=0x1000) at /home/alxndr/Development/qemu/include/sysemu/dma.h:145
+#32 0x0000555557257c57 in usb_packet_unmap (p=0x6110000484c0, sgl=0x611000048548) at /home/alxndr/Development/qemu/hw/usb/libhw.c:65
+#33 0x00005555572aa87e in ehci_execute_complete (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1324
+#34 0x00005555572a7b8c in ehci_state_executing (q=0x60d000004f10) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:1973
+#35 0x00005555572b3685 in ehci_advance_state (ehci=0x62100002d9f0, async=0x1) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2094
+#36 0x00005555572b2db9 in ehci_advance_async_state (ehci=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2152
+#37 0x00005555572a29c3 in ehci_work_bh (opaque=0x62100002d9f0) at /home/alxndr/Development/qemu/hw/usb/hcd-ehci.c:2320
+#38 0x0000555557bfba60 in aio_bh_call (bh=0x60400001cd90) at /home/alxndr/Development/qemu/util/async.c:136
+
+
+I can reproduce it in qemu 5.0 using the commands in the attachment:
+
+qemu-system-i386 \
+-qtest stdio -nographic -monitor none -serial none \
+-M pc-q35-5.0 -machine q35 \
+-device ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \
+-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=ich9-ehci-1.0,firstport=0 \
+-device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,multifunction=on,masterbus=ich9-ehci-1.0,firstport=2 \
+-device ich9-usb-uhci3,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport=4 \
+-drive if=none,id=usbcdrom,media=cdrom \
+-device usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 \
+-device usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom \
+-display none -nodefaults -nographic < attachment
+
+Please let me know if I can provide any further info.
+-Alex
+
+
+
+I can reproduce this crash with QEMU v5.0, but with the current version from the master branch, this does not trigger anymore. I assume this has been fixed. Could you please have a try and confirm that it does not happen anymore?
+
+OSS-Fuzz never found it, though we are fuzzing a slightly different ehci configuration there. I made a note of the arguments we should start fuzzing on OSS-Fuzz, but I think this is safe to close.
+
+Ok, thanks, then let's close this ticket now.
+
diff --git a/results/classifier/118/KVM/1878645 b/results/classifier/118/KVM/1878645
new file mode 100644
index 000000000..035e8ca57
--- /dev/null
+++ b/results/classifier/118/KVM/1878645
@@ -0,0 +1,1091 @@
+KVM: 0.832
+x86: 0.821
+TCG: 0.800
+peripherals: 0.798
+VMM: 0.787
+ppc: 0.772
+vnc: 0.766
+hypervisor: 0.759
+i386: 0.753
+virtual: 0.696
+graphic: 0.692
+register: 0.684
+user-level: 0.683
+device: 0.668
+performance: 0.656
+permissions: 0.652
+semantic: 0.650
+mistranslation: 0.650
+architecture: 0.649
+risc-v: 0.646
+arm: 0.645
+debug: 0.640
+PID: 0.617
+assembly: 0.616
+socket: 0.591
+boot: 0.579
+kernel: 0.574
+network: 0.564
+files: 0.553
+
+null-ptr dereference in ich9_apm_ctrl_changed
+
+Hello,
+While fuzzing, I found an input which triggers a NULL pointer dereference in
+tcg_handle_interrupt. It seems the culprint is a "cpu" pointer - maybe this bug
+is specific to QTest?
+
+==23862==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000000b4 (pc 0x55b9dc7c9dce bp 0x7ffc346a0900 sp 0x7ffc346a0880 T0)
+==23862==The signal is caused by a READ memory access.
+==23862==Hint: address points to the zero page.
+    #0 0x55b9dc7c9dce in tcg_handle_interrupt /home/alxndr/Development/qemu/accel/tcg/tcg-all.c:57:21
+    #1 0x55b9dc904799 in cpu_interrupt /home/alxndr/Development/qemu/include/hw/core/cpu.h:872:5
+    #2 0x55b9dc9085e8 in ich9_apm_ctrl_changed /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:442:13
+    #3 0x55b9dd19cdc8 in apm_ioport_writeb /home/alxndr/Development/qemu/hw/isa/apm.c:50:13
+    #4 0x55b9dc73f8b4 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5
+    #5 0x55b9dc73f289 in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18
+    #6 0x55b9dc73ddf5 in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16
+    #7 0x55b9dc577bf3 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23
+    #8 0x55b9dc567ad8 in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14
+    #9 0x55b9dc567608 in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18
+    #10 0x55b9dc723fe7 in cpu_outb /home/alxndr/Development/qemu/ioport.c:60:5
+    #11 0x55b9dc72d3c0 in qtest_process_command /home/alxndr/Development/qemu/qtest.c:392:13
+    #12 0x55b9dc72b186 in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9
+    #13 0x55b9dc72a8b3 in qtest_read /home/alxndr/Development/qemu/qtest.c:722:5
+    #14 0x55b9ddc6e60b in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:183:9
+    #15 0x55b9ddc6e75a in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:195:9
+    #16 0x55b9ddc77979 in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9
+    #17 0x55b9ddcff0e9 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12
+    #18 0x7f7161eac897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
+    #19 0x55b9ddebcb84 in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9
+    #20 0x55b9ddebb57d in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5
+    #21 0x55b9ddebb176 in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11
+    #22 0x55b9dcb4bd1d in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9
+    #23 0x55b9ddd1629c in main /home/alxndr/Development/qemu/softmmu/main.c:49:5
+    #24 0x7f7160a5ce0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
+    #25 0x55b9dc49c819 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xc9c819)
+
+
+I can reproduce this in qemu 5.0 built with AddressSanitizer using these qtest commands:
+
+cat << EOF | ./qemu-system-i386 \
+-qtest stdio -nographic -monitor none -serial none \
+-M pc-q35-5.0
+outl 0xcf8 0x8400f841
+outl 0xcfc 0xaa215d6d
+outl 0x6d30 0x2ef8ffbe
+outb 0xb2 0x20
+EOF
+
+Please let me know if I can provide any further info.
+-Alex
+
+I don't think this is a qtest-specific error: 
+cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
+o/4 0xcf8 0x8400f841
+o/4 0xcfc 0xaa215d6d
+o/4 0x6d30 0x2ef8ffbe
+o/1 0xb2 0x20
+EOF
+
+...
+Segmentation fault
+
+
+
+Alexander Bulekov <email address hidden> writes:
+
+> I don't think this is a qtest-specific error: 
+> cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
+> o/4 0xcf8 0x8400f841
+> o/4 0xcfc 0xaa215d6d
+> o/4 0x6d30 0x2ef8ffbe
+> o/1 0xb2 0x20
+> EOF
+>
+> ...
+> Segmentation fault
+
+Both this and the qtest have the same problem of depending on
+current_cpu which is a TLS variable which will never be correct from the
+qtest or monitor context. There are only a few other cases.
+
+sun4m:cpu_halt_signal does:
+
+    if (level && current_cpu) {
+        cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
+    }
+
+pxa2xx:pxa2xx_pwrmode_write does a bare:
+
+    /* Suspend */
+    cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
+
+but given the context has a CPUARMState *env it could arguably use that
+to derive current_cpu but as it's only triggered by a system register
+write you can't actually trigger from a monitor/qtest command.
+
+I would suggest either:
+
+        } else if (current_cpu) {
+            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+        }
+
+or possibly:
+
+        } else {
+            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+        }
+
+if you really care about triggering a real IRQ from outside the CPU context.
+
+-- 
+Alex Bennée
+
+
+On 200629 2000, Alex Bennée wrote:
+> 
+> Alexander Bulekov <email address hidden> writes:
+> 
+> > I don't think this is a qtest-specific error: 
+> > cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
+> > o/4 0xcf8 0x8400f841
+> > o/4 0xcfc 0xaa215d6d
+> > o/4 0x6d30 0x2ef8ffbe
+> > o/1 0xb2 0x20
+> > EOF
+> >
+> > ...
+> > Segmentation fault
+> 
+> Both this and the qtest have the same problem of depending on
+> current_cpu which is a TLS variable which will never be correct from the
+> qtest or monitor context. There are only a few other cases.
+
+Ah that makes sense. It probably isn't a real issue, but I'll send
+patches with the changes you suggested below.
+Thank you
+
+> sun4m:cpu_halt_signal does:
+> 
+>     if (level && current_cpu) {
+>         cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
+>     }
+> 
+> pxa2xx:pxa2xx_pwrmode_write does a bare:
+> 
+>     /* Suspend */
+>     cpu_interrupt(current_cpu, CPU_INTERRUPT_HALT);
+> 
+> but given the context has a CPUARMState *env it could arguably use that
+> to derive current_cpu but as it's only triggered by a system register
+> write you can't actually trigger from a monitor/qtest command.
+> 
+> I would suggest either:
+> 
+>         } else if (current_cpu) {
+>             cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>         }
+> 
+> or possibly:
+> 
+>         } else {
+>             cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>         }
+> 
+> if you really care about triggering a real IRQ from outside the CPU context.
+> 
+> -- 
+> Alex Bennée
+> 
+
+
+It's possible to trigger this function from qtest/monitor at which
+point current_cpu won't point at the right place. Check it and
+fall back to first_cpu if it's NULL.
+
+Signed-off-by: Alex Bennée <email address hidden>
+Cc: Bug 1878645 <email address hidden>
+---
+ hw/isa/lpc_ich9.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+index cd6e169d47a..791c878eb0b 100644
+--- a/hw/isa/lpc_ich9.c
++++ b/hw/isa/lpc_ich9.c
+@@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+                 cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+             }
+         } else {
+-            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
++            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+         }
+     }
+ }
+-- 
+2.20.1
+
+
+
+On 7/1/20 3:56 PM, Alex Bennée wrote:
+> It's possible to trigger this function from qtest/monitor at which
+> point current_cpu won't point at the right place. Check it and
+> fall back to first_cpu if it's NULL.
+> 
+> Signed-off-by: Alex Bennée <email address hidden>
+> Cc: Bug 1878645 <email address hidden>
+> ---
+>  hw/isa/lpc_ich9.c | 2 +-
+>  1 file changed, 1 insertion(+), 1 deletion(-)
+> 
+> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+> index cd6e169d47a..791c878eb0b 100644
+> --- a/hw/isa/lpc_ich9.c
+> +++ b/hw/isa/lpc_ich9.c
+> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>              }
+>          } else {
+> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+
+I'm not sure this change anything, as first_cpu is NULL when using
+qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+GDB connection segfault caused by empty machines").
+
+>          }
+>      }
+>  }
+> 
+
+
+
+
+Philippe Mathieu-Daudé <email address hidden> writes:
+
+> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>> It's possible to trigger this function from qtest/monitor at which
+>> point current_cpu won't point at the right place. Check it and
+>> fall back to first_cpu if it's NULL.
+>> 
+>> Signed-off-by: Alex Bennée <email address hidden>
+>> Cc: Bug 1878645 <email address hidden>
+>> ---
+>>  hw/isa/lpc_ich9.c | 2 +-
+>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>> 
+>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>> index cd6e169d47a..791c878eb0b 100644
+>> --- a/hw/isa/lpc_ich9.c
+>> +++ b/hw/isa/lpc_ich9.c
+>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>              }
+>>          } else {
+>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>
+> I'm not sure this change anything, as first_cpu is NULL when using
+> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+> GDB connection segfault caused by empty machines").
+
+Good point - anyway feel free to ignore - it shouldn't have been in this
+series. It was just some random experimentation I was doing when looking
+at that bug.
+
+-- 
+Alex Bennée
+
+
+On 7/1/20 6:40 PM, Alex Bennée wrote:
+> 
+> Philippe Mathieu-Daudé <email address hidden> writes:
+> 
+>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>> It's possible to trigger this function from qtest/monitor at which
+>>> point current_cpu won't point at the right place. Check it and
+>>> fall back to first_cpu if it's NULL.
+>>>
+>>> Signed-off-by: Alex Bennée <email address hidden>
+>>> Cc: Bug 1878645 <email address hidden>
+>>> ---
+>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>
+>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>> index cd6e169d47a..791c878eb0b 100644
+>>> --- a/hw/isa/lpc_ich9.c
+>>> +++ b/hw/isa/lpc_ich9.c
+>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>              }
+>>>          } else {
+>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>
+>> I'm not sure this change anything, as first_cpu is NULL when using
+>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>> GDB connection segfault caused by empty machines").
+> 
+> Good point - anyway feel free to ignore - it shouldn't have been in this
+> series. It was just some random experimentation I was doing when looking
+> at that bug.
+
+See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+crashing") for a similar approach, but here I was thinking about
+a more generic fix, not very intrusive:
+
+-- >8 --
+diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+index bce266b957..809afeb3e4 100644
+--- a/hw/isa/apm.c
++++ b/hw/isa/apm.c
+@@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+addr, uint64_t val,
+     if (addr == 0) {
+         apm->apmc = val;
+
+-        if (apm->callback) {
++        if (apm->callback && !qtest_enabled()) {
+             (apm->callback)(val, apm->arg);
+         }
+     } else {
+---
+
+
+
+
+Philippe Mathieu-Daudé <email address hidden> writes:
+
+> On 7/1/20 6:40 PM, Alex Bennée wrote:
+>> 
+>> Philippe Mathieu-Daudé <email address hidden> writes:
+>> 
+>>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>>> It's possible to trigger this function from qtest/monitor at which
+>>>> point current_cpu won't point at the right place. Check it and
+>>>> fall back to first_cpu if it's NULL.
+>>>>
+>>>> Signed-off-by: Alex Bennée <email address hidden>
+>>>> Cc: Bug 1878645 <email address hidden>
+>>>> ---
+>>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>>
+>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>>> index cd6e169d47a..791c878eb0b 100644
+>>>> --- a/hw/isa/lpc_ich9.c
+>>>> +++ b/hw/isa/lpc_ich9.c
+>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>>              }
+>>>>          } else {
+>>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>>
+>>> I'm not sure this change anything, as first_cpu is NULL when using
+>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>>> GDB connection segfault caused by empty machines").
+>> 
+>> Good point - anyway feel free to ignore - it shouldn't have been in this
+>> series. It was just some random experimentation I was doing when looking
+>> at that bug.
+>
+> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+> crashing") for a similar approach, but here I was thinking about
+> a more generic fix, not very intrusive:
+>
+> -- >8 --
+> diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+> index bce266b957..809afeb3e4 100644
+> --- a/hw/isa/apm.c
+> +++ b/hw/isa/apm.c
+> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+> addr, uint64_t val,
+>      if (addr == 0) {
+>          apm->apmc = val;
+>
+> -        if (apm->callback) {
+> +        if (apm->callback && !qtest_enabled()) {
+>              (apm->callback)(val, apm->arg);
+>          }
+
+But the other failure mode reported on the bug thread was via the
+monitor - so I'm not sure just checking for qtest catches that.
+
+>      } else {
+> ---
+
+
+-- 
+Alex Bennée
+
+
++Paolo
+
+On 7/1/20 7:09 PM, Alex Bennée wrote:
+> Philippe Mathieu-Daudé <email address hidden> writes:
+>> On 7/1/20 6:40 PM, Alex Bennée wrote:
+>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>
+>>>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>>>> It's possible to trigger this function from qtest/monitor at which
+>>>>> point current_cpu won't point at the right place. Check it and
+>>>>> fall back to first_cpu if it's NULL.
+>>>>>
+>>>>> Signed-off-by: Alex Bennée <email address hidden>
+>>>>> Cc: Bug 1878645 <email address hidden>
+>>>>> ---
+>>>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>>>
+>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>>>> index cd6e169d47a..791c878eb0b 100644
+>>>>> --- a/hw/isa/lpc_ich9.c
+>>>>> +++ b/hw/isa/lpc_ich9.c
+>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>>>              }
+>>>>>          } else {
+>>>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>>>
+>>>> I'm not sure this change anything, as first_cpu is NULL when using
+>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>>>> GDB connection segfault caused by empty machines").
+>>>
+>>> Good point - anyway feel free to ignore - it shouldn't have been in this
+>>> series. It was just some random experimentation I was doing when looking
+>>> at that bug.
+>>
+>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+>> crashing") for a similar approach, but here I was thinking about
+>> a more generic fix, not very intrusive:
+>>
+>> -- >8 --
+>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+>> index bce266b957..809afeb3e4 100644
+>> --- a/hw/isa/apm.c
+>> +++ b/hw/isa/apm.c
+>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+>> addr, uint64_t val,
+>>      if (addr == 0) {
+>>          apm->apmc = val;
+>>
+>> -        if (apm->callback) {
+>> +        if (apm->callback && !qtest_enabled()) {
+>>              (apm->callback)(val, apm->arg);
+>>          }
+> 
+> But the other failure mode reported on the bug thread was via the
+> monitor - so I'm not sure just checking for qtest catches that.
+
+Ah indeed.
+
+in exec.c:
+
+/* current CPU in the current thread. It is only valid inside
+   cpu_exec() */
+__thread CPUState *current_cpu;
+
+Maybe we shouldn't use current_cpu out of exec.c...
+
+
+
+On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote:
+> +Paolo
+> 
+> On 7/1/20 7:09 PM, Alex Bennée wrote:
+>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>> On 7/1/20 6:40 PM, Alex Bennée wrote:
+>>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>>
+>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>>>>> It's possible to trigger this function from qtest/monitor at which
+>>>>>> point current_cpu won't point at the right place. Check it and
+>>>>>> fall back to first_cpu if it's NULL.
+>>>>>>
+>>>>>> Signed-off-by: Alex Bennée <email address hidden>
+>>>>>> Cc: Bug 1878645 <email address hidden>
+>>>>>> ---
+>>>>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>>>>
+>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>>>>> index cd6e169d47a..791c878eb0b 100644
+>>>>>> --- a/hw/isa/lpc_ich9.c
+>>>>>> +++ b/hw/isa/lpc_ich9.c
+>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>>>>              }
+>>>>>>          } else {
+>>>>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>>>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>>>>
+>>>>> I'm not sure this change anything, as first_cpu is NULL when using
+>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>>>>> GDB connection segfault caused by empty machines").
+>>>>
+>>>> Good point - anyway feel free to ignore - it shouldn't have been in this
+>>>> series. It was just some random experimentation I was doing when looking
+>>>> at that bug.
+>>>
+>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+>>> crashing") for a similar approach, but here I was thinking about
+>>> a more generic fix, not very intrusive:
+>>>
+>>> -- >8 --
+>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+>>> index bce266b957..809afeb3e4 100644
+>>> --- a/hw/isa/apm.c
+>>> +++ b/hw/isa/apm.c
+>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+>>> addr, uint64_t val,
+>>>      if (addr == 0) {
+>>>          apm->apmc = val;
+>>>
+>>> -        if (apm->callback) {
+>>> +        if (apm->callback && !qtest_enabled()) {
+>>>              (apm->callback)(val, apm->arg);
+>>>          }
+>>
+>> But the other failure mode reported on the bug thread was via the
+>> monitor - so I'm not sure just checking for qtest catches that.
+> 
+> Ah indeed.
+> 
+> in exec.c:
+> 
+> /* current CPU in the current thread. It is only valid inside
+>    cpu_exec() */
+> __thread CPUState *current_cpu;
+> 
+> Maybe we shouldn't use current_cpu out of exec.c...
+
+I meant, out of cpu_exec(), a cpu thread. Here we access it
+from an I/O thread.
+
+
+
++MST/Igor for ICH9
+
+On 7/1/20 7:37 PM, Philippe Mathieu-Daudé wrote:
+> On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote:
+>> +Paolo
+>>
+>> On 7/1/20 7:09 PM, Alex Bennée wrote:
+>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>> On 7/1/20 6:40 PM, Alex Bennée wrote:
+>>>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>>>
+>>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>>>>>> It's possible to trigger this function from qtest/monitor at which
+>>>>>>> point current_cpu won't point at the right place. Check it and
+>>>>>>> fall back to first_cpu if it's NULL.
+>>>>>>>
+>>>>>>> Signed-off-by: Alex Bennée <email address hidden>
+>>>>>>> Cc: Bug 1878645 <email address hidden>
+>>>>>>> ---
+>>>>>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>>>>>
+>>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>>>>>> index cd6e169d47a..791c878eb0b 100644
+>>>>>>> --- a/hw/isa/lpc_ich9.c
+>>>>>>> +++ b/hw/isa/lpc_ich9.c
+>>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>>>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>>>>>              }
+>>>>>>>          } else {
+>>>>>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>>>>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>>>>>
+>>>>>> I'm not sure this change anything, as first_cpu is NULL when using
+>>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>>>>>> GDB connection segfault caused by empty machines").
+>>>>>
+>>>>> Good point - anyway feel free to ignore - it shouldn't have been in this
+>>>>> series. It was just some random experimentation I was doing when looking
+>>>>> at that bug.
+>>>>
+>>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+>>>> crashing") for a similar approach, but here I was thinking about
+>>>> a more generic fix, not very intrusive:
+>>>>
+>>>> -- >8 --
+>>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+>>>> index bce266b957..809afeb3e4 100644
+>>>> --- a/hw/isa/apm.c
+>>>> +++ b/hw/isa/apm.c
+>>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+>>>> addr, uint64_t val,
+>>>>      if (addr == 0) {
+>>>>          apm->apmc = val;
+>>>>
+>>>> -        if (apm->callback) {
+>>>> +        if (apm->callback && !qtest_enabled()) {
+>>>>              (apm->callback)(val, apm->arg);
+>>>>          }
+>>>
+>>> But the other failure mode reported on the bug thread was via the
+>>> monitor - so I'm not sure just checking for qtest catches that.
+>>
+>> Ah indeed.
+>>
+>> in exec.c:
+>>
+>> /* current CPU in the current thread. It is only valid inside
+>>    cpu_exec() */
+>> __thread CPUState *current_cpu;
+>>
+>> Maybe we shouldn't use current_cpu out of exec.c...
+> 
+> I meant, out of cpu_exec(), a cpu thread. Here we access it
+> from an I/O thread.
+
+ARM and S390X use:
+
+hw/arm/boot.c:460:    ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));
+hw/arm/virt.c:331:    armcpu = ARM_CPU(qemu_get_cpu(0));
+hw/arm/virt.c:549:    armcpu = ARM_CPU(qemu_get_cpu(0));
+hw/cpu/a15mpcore.c:69:        cpuobj = OBJECT(qemu_get_cpu(0));
+hw/cpu/a9mpcore.c:76:    cpuobj = OBJECT(qemu_get_cpu(0));
+target/s390x/cpu_models.c:155:        cpu = S390_CPU(qemu_get_cpu(0));
+target/s390x/cpu_models.c:169:        cpu = S390_CPU(qemu_get_cpu(0));
+target/s390x/cpu_models.c:184:        cpu = S390_CPU(qemu_get_cpu(0));
+target/s390x/cpu_models.c:204:        cpu = S390_CPU(qemu_get_cpu(0));
+target/s390x/cpu_models.c:218:        cpu = S390_CPU(qemu_get_cpu(0));
+
+It seems odd that the ICH9 delivers the SMI on a random core.
+Usually the IRQ lines are wired to a particular unit.
+
+
+
+On 7/1/20 7:48 PM, Philippe Mathieu-Daudé wrote:
+> +MST/Igor for ICH9
+> 
+> On 7/1/20 7:37 PM, Philippe Mathieu-Daudé wrote:
+>> On 7/1/20 7:34 PM, Philippe Mathieu-Daudé wrote:
+>>> +Paolo
+>>>
+>>> On 7/1/20 7:09 PM, Alex Bennée wrote:
+>>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>>> On 7/1/20 6:40 PM, Alex Bennée wrote:
+>>>>>> Philippe Mathieu-Daudé <email address hidden> writes:
+>>>>>>
+>>>>>>> On 7/1/20 3:56 PM, Alex Bennée wrote:
+>>>>>>>> It's possible to trigger this function from qtest/monitor at which
+>>>>>>>> point current_cpu won't point at the right place. Check it and
+>>>>>>>> fall back to first_cpu if it's NULL.
+>>>>>>>>
+>>>>>>>> Signed-off-by: Alex Bennée <email address hidden>
+>>>>>>>> Cc: Bug 1878645 <email address hidden>
+>>>>>>>> ---
+>>>>>>>>  hw/isa/lpc_ich9.c | 2 +-
+>>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
+>>>>>>>>
+>>>>>>>> diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
+>>>>>>>> index cd6e169d47a..791c878eb0b 100644
+>>>>>>>> --- a/hw/isa/lpc_ich9.c
+>>>>>>>> +++ b/hw/isa/lpc_ich9.c
+>>>>>>>> @@ -439,7 +439,7 @@ static void ich9_apm_ctrl_changed(uint32_t val, void *arg)
+>>>>>>>>                  cpu_interrupt(cs, CPU_INTERRUPT_SMI);
+>>>>>>>>              }
+>>>>>>>>          } else {
+>>>>>>>> -            cpu_interrupt(current_cpu, CPU_INTERRUPT_SMI);
+>>>>>>>> +            cpu_interrupt(current_cpu ? current_cpu : first_cpu, CPU_INTERRUPT_SMI);
+>>>>>>>
+>>>>>>> I'm not sure this change anything, as first_cpu is NULL when using
+>>>>>>> qtest accelerator or none-machine, see 508b4ecc39 ("gdbstub.c: fix
+>>>>>>> GDB connection segfault caused by empty machines").
+>>>>>>
+>>>>>> Good point - anyway feel free to ignore - it shouldn't have been in this
+>>>>>> series. It was just some random experimentation I was doing when looking
+>>>>>> at that bug.
+>>>>>
+>>>>> See commit c781a2cc42 ("hw/i386/vmport: Allow QTest use without
+>>>>> crashing") for a similar approach, but here I was thinking about
+>>>>> a more generic fix, not very intrusive:
+>>>>>
+>>>>> -- >8 --
+>>>>> diff --git a/hw/isa/apm.c b/hw/isa/apm.c
+>>>>> index bce266b957..809afeb3e4 100644
+>>>>> --- a/hw/isa/apm.c
+>>>>> +++ b/hw/isa/apm.c
+>>>>> @@ -40,7 +40,7 @@ static void apm_ioport_writeb(void *opaque, hwaddr
+>>>>> addr, uint64_t val,
+>>>>>      if (addr == 0) {
+>>>>>          apm->apmc = val;
+>>>>>
+>>>>> -        if (apm->callback) {
+>>>>> +        if (apm->callback && !qtest_enabled()) {
+>>>>>              (apm->callback)(val, apm->arg);
+>>>>>          }
+>>>>
+>>>> But the other failure mode reported on the bug thread was via the
+>>>> monitor - so I'm not sure just checking for qtest catches that.
+>>>
+>>> Ah indeed.
+>>>
+>>> in exec.c:
+>>>
+>>> /* current CPU in the current thread. It is only valid inside
+>>>    cpu_exec() */
+>>> __thread CPUState *current_cpu;
+>>>
+>>> Maybe we shouldn't use current_cpu out of exec.c...
+>>
+>> I meant, out of cpu_exec(), a cpu thread. Here we access it
+>> from an I/O thread.
+
+Ah! we are in the monitor thread... It makes sense there is not
+current_cpu assigned :)
+
+> 
+> ARM and S390X use:
+> 
+> hw/arm/boot.c:460:    ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));
+> hw/arm/virt.c:331:    armcpu = ARM_CPU(qemu_get_cpu(0));
+> hw/arm/virt.c:549:    armcpu = ARM_CPU(qemu_get_cpu(0));
+> hw/cpu/a15mpcore.c:69:        cpuobj = OBJECT(qemu_get_cpu(0));
+> hw/cpu/a9mpcore.c:76:    cpuobj = OBJECT(qemu_get_cpu(0));
+> target/s390x/cpu_models.c:155:        cpu = S390_CPU(qemu_get_cpu(0));
+> target/s390x/cpu_models.c:169:        cpu = S390_CPU(qemu_get_cpu(0));
+> target/s390x/cpu_models.c:184:        cpu = S390_CPU(qemu_get_cpu(0));
+> target/s390x/cpu_models.c:204:        cpu = S390_CPU(qemu_get_cpu(0));
+> target/s390x/cpu_models.c:218:        cpu = S390_CPU(qemu_get_cpu(0));
+> 
+> It seems odd that the ICH9 delivers the SMI on a random core.
+> Usually the IRQ lines are wired to a particular unit.
+> 
+
+
+
+We can run I/O access with the 'i' or 'o' HMP commands in the
+monitor. These commands are expected to run on a vCPU. The
+monitor is not a vCPU thread. To avoid crashing, initialize
+the 'current_cpu' variable with the first vCPU created. The
+command executed on the monitor will end using it.
+
+This fixes:
+
+  $ cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
+  o/4 0xcf8 0x8400f841
+  o/4 0xcfc 0xaa215d6d
+  o/4 0x6d30 0x2ef8ffbe
+  o/1 0xb2 0x20
+  EOF
+  Segmentation fault (core dumped)
+
+  Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault.
+  0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57
+  57          old_mask = cpu->interrupt_request;
+  (gdb) bt
+  #0  0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57
+  #1  0x00005555558ed7d2 in cpu_interrupt (cpu=0x0, mask=64) at include/hw/core/cpu.h:877
+  #2  0x00005555558ee776 in ich9_apm_ctrl_changed (val=32, arg=0x555556e2ff50) at hw/isa/lpc_ich9.c:442
+  #3  0x0000555555b47f96 in apm_ioport_writeb (opaque=0x555556e308c0, addr=0, val=32, size=1) at hw/isa/apm.c:44
+  #4  0x0000555555879931 in memory_region_write_accessor (mr=0x555556e308e0, addr=0, value=0x7fffffffb9f8, size=1, shift=0, mask=255, attrs=...) at memory.c:483
+  #5  0x0000555555879b5a in access_with_adjusted_size (addr=0, value=0x7fffffffb9f8, size=4, access_size_min=1, access_size_max=1, access_fn=
+      0x55555587984e <memory_region_write_accessor>, mr=0x555556e308e0, attrs=...) at memory.c:544
+  #6  0x000055555587ca32 in memory_region_dispatch_write (mr=0x555556e308e0, addr=0, data=32, op=MO_32, attrs=...) at memory.c:1465
+  #7  0x000055555581b7e9 in flatview_write_continue (fv=0x55555698a790, addr=178, attrs=..., ptr=0x7fffffffbb84, len=4, addr1=0, l=4, mr=0x555556e308e0) at exec.c:3198
+  #8  0x000055555581b92e in flatview_write (fv=0x55555698a790, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3238
+  #9  0x000055555581bc81 in address_space_write (as=0x555556441220 <address_space_io>, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3329
+  #10 0x0000555555873f08 in cpu_outl (addr=178, val=32) at ioport.c:80
+  #11 0x000055555598a26a in hmp_ioport_write (mon=0x5555567621b0, qdict=0x555557702600) at monitor/misc.c:937
+  #12 0x0000555555c9c5a5 in handle_hmp_command (mon=0x5555567621b0, cmdline=0x55555676aae1 "/1 0xb2 0x20") at monitor/hmp.c:1082
+  #13 0x0000555555c99e02 in monitor_command_cb (opaque=0x5555567621b0, cmdline=0x55555676aae0 "o/1 0xb2 0x20", readline_opaque=0x0) at monitor/hmp.c:47
+                            ^
+    HMP command from monitor
+
+Reported-by: Alexander Bulekov <email address hidden>
+Buglink: https://bugs.launchpad.net/qemu/+bug/1878645
+Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+---
+Cc: Bug 1878645 <email address hidden>
+
+RFC because I believe the correct fix is to NOT use current_cpu
+out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU.
+---
+ cpus.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/cpus.c b/cpus.c
+index 41d1c5099f..1f6f43d221 100644
+--- a/cpus.c
++++ b/cpus.c
+@@ -2106,6 +2106,9 @@ void qemu_init_vcpu(CPUState *cpu)
+ {
+     MachineState *ms = MACHINE(qdev_get_machine());
+ 
++    if (!current_cpu) {
++        current_cpu = cpu;
++    }
+     cpu->nr_cores = ms->smp.cores;
+     cpu->nr_threads =  ms->smp.threads;
+     cpu->stopped = true;
+-- 
+2.21.3
+
+
+
+On 200701 2021, Philippe Mathieu-Daudé wrote:
+> We can run I/O access with the 'i' or 'o' HMP commands in the
+> monitor. These commands are expected to run on a vCPU. The
+> monitor is not a vCPU thread. To avoid crashing, initialize
+> the 'current_cpu' variable with the first vCPU created. The
+> command executed on the monitor will end using it.
+> 
+> This fixes:
+> 
+>   $ cat << EOF| qemu-system-i386 -M q35 -nographic -serial none -monitor stdio
+>   o/4 0xcf8 0x8400f841
+>   o/4 0xcfc 0xaa215d6d
+>   o/4 0x6d30 0x2ef8ffbe
+>   o/1 0xb2 0x20
+>   EOF
+>   Segmentation fault (core dumped)
+> 
+>   Thread 1 "qemu-system-i38" received signal SIGSEGV, Segmentation fault.
+>   0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57
+>   57          old_mask = cpu->interrupt_request;
+>   (gdb) bt
+>   #0  0x00005555558946c7 in tcg_handle_interrupt (cpu=0x0, mask=64) at accel/tcg/tcg-all.c:57
+>   #1  0x00005555558ed7d2 in cpu_interrupt (cpu=0x0, mask=64) at include/hw/core/cpu.h:877
+>   #2  0x00005555558ee776 in ich9_apm_ctrl_changed (val=32, arg=0x555556e2ff50) at hw/isa/lpc_ich9.c:442
+>   #3  0x0000555555b47f96 in apm_ioport_writeb (opaque=0x555556e308c0, addr=0, val=32, size=1) at hw/isa/apm.c:44
+>   #4  0x0000555555879931 in memory_region_write_accessor (mr=0x555556e308e0, addr=0, value=0x7fffffffb9f8, size=1, shift=0, mask=255, attrs=...) at memory.c:483
+>   #5  0x0000555555879b5a in access_with_adjusted_size (addr=0, value=0x7fffffffb9f8, size=4, access_size_min=1, access_size_max=1, access_fn=
+>       0x55555587984e <memory_region_write_accessor>, mr=0x555556e308e0, attrs=...) at memory.c:544
+>   #6  0x000055555587ca32 in memory_region_dispatch_write (mr=0x555556e308e0, addr=0, data=32, op=MO_32, attrs=...) at memory.c:1465
+>   #7  0x000055555581b7e9 in flatview_write_continue (fv=0x55555698a790, addr=178, attrs=..., ptr=0x7fffffffbb84, len=4, addr1=0, l=4, mr=0x555556e308e0) at exec.c:3198
+>   #8  0x000055555581b92e in flatview_write (fv=0x55555698a790, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3238
+>   #9  0x000055555581bc81 in address_space_write (as=0x555556441220 <address_space_io>, addr=178, attrs=..., buf=0x7fffffffbb84, len=4) at exec.c:3329
+>   #10 0x0000555555873f08 in cpu_outl (addr=178, val=32) at ioport.c:80
+>   #11 0x000055555598a26a in hmp_ioport_write (mon=0x5555567621b0, qdict=0x555557702600) at monitor/misc.c:937
+>   #12 0x0000555555c9c5a5 in handle_hmp_command (mon=0x5555567621b0, cmdline=0x55555676aae1 "/1 0xb2 0x20") at monitor/hmp.c:1082
+>   #13 0x0000555555c99e02 in monitor_command_cb (opaque=0x5555567621b0, cmdline=0x55555676aae0 "o/1 0xb2 0x20", readline_opaque=0x0) at monitor/hmp.c:47
+>                             ^
+>     HMP command from monitor
+> 
+> Reported-by: Alexander Bulekov <email address hidden>
+> Buglink: https://bugs.launchpad.net/qemu/+bug/1878645
+> Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+> ---
+> Cc: Bug 1878645 <email address hidden>
+> 
+> RFC because I believe the correct fix is to NOT use current_cpu
+> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU.
+> ---
+>  cpus.c | 3 +++
+>  1 file changed, 3 insertions(+)
+> 
+> diff --git a/cpus.c b/cpus.c
+> index 41d1c5099f..1f6f43d221 100644
+> --- a/cpus.c
+> +++ b/cpus.c
+> @@ -2106,6 +2106,9 @@ void qemu_init_vcpu(CPUState *cpu)
+>  {
+>      MachineState *ms = MACHINE(qdev_get_machine());
+>  
+> +    if (!current_cpu) {
+> +        current_cpu = cpu;
+> +    }
+
+Seems like a neat solution.
+is it fair to assume that qemu_init_vcpu is called before any threads
+that can do I/O are created? I confirmed that the qtest and hmp crashes
+are avoided.
+-Alex
+
+>      cpu->nr_cores = ms->smp.cores;
+>      cpu->nr_threads =  ms->smp.threads;
+>      cpu->stopped = true;
+> -- 
+> 2.21.3
+> 
+
+
+On Wed, 1 Jul 2020 at 19:21, Philippe Mathieu-Daudé <email address hidden> wrote:
+>
+> We can run I/O access with the 'i' or 'o' HMP commands in the
+> monitor. These commands are expected to run on a vCPU. The
+> monitor is not a vCPU thread. To avoid crashing, initialize
+> the 'current_cpu' variable with the first vCPU created. The
+> command executed on the monitor will end using it.
+
+>
+> RFC because I believe the correct fix is to NOT use current_cpu
+> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU.
+
+Yes, I agree -- I don't think this is the correct fix.
+current_cpu is documented as "only valid inside cpu_exec()",
+ie if you're actually on a vcpu thread you can use it, but if
+you're not on a CPU thread, like the monitor, you need to
+say which vCPU you want to affect. For the monitor, that
+would be the current "default cpu" as set by the "cpu"
+command (cf monitor_set_cpu()). The bug here will be that
+somewhere along the line we are probably missing plumbing
+sufficient to pass down "which CPU do we want".
+
+https://bugs.launchpad.net/qemu/+bug/1602247 is a bug of
+a similar nature -- if the gdbstub does a memory access
+we know which CPU we're trying to do that memory access as,
+but it doesn't get plumbed through and so in the Arm GIC
+register read/write function that looks at current_cpu
+we get a segfault.
+
+One way to fix this would be to do something akin to how
+real hardware works -- encode into the MemTxAttrs an
+indication of what the transaction master was (eg the
+CPU number for CPUs); then the handful of devices that
+care about which CPU was doing the transaction can use
+that, rather than directly looking at current_cpu, and
+when gdbstub or monitor perform an access that should
+act like it's from a particular CPU they can indicate
+that by supplying appropriate transaction attributes.
+That would potentially be quite a bit of work though
+(but I think it would be a neat design if we want to
+try to fix this kind of "segfault if the user prods
+a device via the monitor" bug).
+
++    if (!current_cpu) {
++        current_cpu = cpu;
++    }
+
+Some more specific issues with this -- current_cpu is
+a thread-local variable, so this will set that for
+whatever thread happens to make this call, which
+might or might not be the one that ends up handling
+the monitor command. Also some code assumes that
+current_cpu is non-NULL only if this is a vCPU thread,
+eg sigbus_handler().
+
+thanks
+-- PMM
+
+
+On 7/1/20 10:35 PM, Peter Maydell wrote:
+> On Wed, 1 Jul 2020 at 19:21, Philippe Mathieu-Daudé <email address hidden> wrote:
+>>
+>> We can run I/O access with the 'i' or 'o' HMP commands in the
+>> monitor. These commands are expected to run on a vCPU. The
+>> monitor is not a vCPU thread. To avoid crashing, initialize
+>> the 'current_cpu' variable with the first vCPU created. The
+>> command executed on the monitor will end using it.
+> 
+>>
+>> RFC because I believe the correct fix is to NOT use current_cpu
+>> out of cpus.c, at least use qemu_get_cpu(0) to get the first vCPU.
+> 
+> Yes, I agree -- I don't think this is the correct fix.
+> current_cpu is documented as "only valid inside cpu_exec()",
+> ie if you're actually on a vcpu thread you can use it, but if
+> you're not on a CPU thread, like the monitor, you need to
+> say which vCPU you want to affect. For the monitor, that
+> would be the current "default cpu" as set by the "cpu"
+> command (cf monitor_set_cpu()). The bug here will be that
+> somewhere along the line we are probably missing plumbing
+> sufficient to pass down "which CPU do we want".
+
+TIL mon_get_cpu() :)
+
+This is a bit different here, the monitor is not doing an
+access on a CPU address space, but directly on the I/O
+address space. The APM port is registered by the ICH9
+south bridge, and this triggers a SMI exception on a
+CPU core, but I have no idea which one, a random one?
+Then this particular core will switch to SMM mode.
+
+Another way of seeing this problem, is imagining we
+start a PIT timer from the monitor. When the timer
+expires, the PIT will interrupt the CPU. Which CPU
+to interrupt? We are not in the context of the monitor.
+
+> https://bugs.launchpad.net/qemu/+bug/1602247 is a bug of
+> a similar nature -- if the gdbstub does a memory access
+> we know which CPU we're trying to do that memory access as,
+> but it doesn't get plumbed through and so in the Arm GIC
+> register read/write function that looks at current_cpu
+> we get a segfault.
+> 
+> One way to fix this would be to do something akin to how
+> real hardware works -- encode into the MemTxAttrs an
+> indication of what the transaction master was (eg the
+> CPU number for CPUs); then the handful of devices that
+> care about which CPU was doing the transaction can use
+> that, rather than directly looking at current_cpu, and
+> when gdbstub or monitor perform an access that should
+> act like it's from a particular CPU they can indicate
+> that by supplying appropriate transaction attributes.
+> That would potentially be quite a bit of work though
+> (but I think it would be a neat design if we want to
+> try to fix this kind of "segfault if the user prods
+> a device via the monitor" bug).
+
+This is complex stuff. Too early for me to digest, I am
+keeping this for later (I am not ignoring your comment).
+
+> 
+> +    if (!current_cpu) {
+> +        current_cpu = cpu;
+> +    }
+> 
+> Some more specific issues with this -- current_cpu is
+> a thread-local variable, so this will set that for
+> whatever thread happens to make this call, which
+> might or might not be the one that ends up handling
+> the monitor command. Also some code assumes that
+> current_cpu is non-NULL only if this is a vCPU thread,
+> eg sigbus_handler().
+
+Yes, I agree.
+
+> 
+> thanks
+> -- PMM
+> 
+
+
+
+
+Paolo Bonzini <email address hidden> writes:
+
+> On 01/07/20 22:35, Peter Maydell wrote:
+>> For the monitor, that
+>> would be the current "default cpu" as set by the "cpu"
+>> command (cf monitor_set_cpu()). The bug here will be that
+>> somewhere along the line we are probably missing plumbing
+>> sufficient to pass down "which CPU do we want".
+>
+> Yeah, the fix is probably to add a functions that returns either
+> current_cpu or the monitor CPU, and use it in device emulation if
+> applicable.
+>
+> The problem with current_cpu is that it affects stuff like run_on_cpu,
+> and that is guaranteed to cause havoc to code that expects to run on a
+> given CPU and therefore doesn't use locks.
+
+IIRC the original reported bug was in a APM callback which was triggered
+by an MMIO operation. Currently we don't expose the current cpu via the
+memory dispatch routines. Should we to ensure there is always something
+valid there?
+
+>
+> Paolo
+
+
+-- 
+Alex Bennée
+
+
+I moved this report over to QEMU's new bug tracker on gitlab.com.
+Please continue with the discussion here:
+
+https://gitlab.com/qemu-project/qemu/-/issues/536
+
+Thanks for moving it over! ... let's close this one here on Launchpad now.
+
+
diff --git a/results/classifier/118/KVM/1880507 b/results/classifier/118/KVM/1880507
new file mode 100644
index 000000000..aab22ca45
--- /dev/null
+++ b/results/classifier/118/KVM/1880507
@@ -0,0 +1,42 @@
+KVM: 0.983
+VMM: 0.980
+mistranslation: 0.971
+virtual: 0.875
+semantic: 0.860
+device: 0.799
+graphic: 0.655
+hypervisor: 0.581
+architecture: 0.531
+performance: 0.423
+i386: 0.407
+boot: 0.402
+network: 0.395
+user-level: 0.320
+risc-v: 0.316
+debug: 0.304
+register: 0.290
+x86: 0.286
+PID: 0.278
+ppc: 0.256
+socket: 0.230
+TCG: 0.214
+files: 0.166
+arm: 0.165
+kernel: 0.148
+permissions: 0.121
+vnc: 0.109
+assembly: 0.082
+peripherals: 0.041
+
+VMM from Ubuntu 20.04 does not show the memory consumption
+
+KVM host system: Ubuntu 18.04 and 20.04, guest machines: Windows and Ubuntu. Management through Ubuntu 20.04, vmm does not show RAM consumption for Windows guest systems (Win7, Win2008R2), for Ubuntu values are shown. The error is not observed in Ubuntu 18.04/vmm.
+
+Does "vmm" mean Virtual Machine Manager (aka virt-manager)? If yes,
+please file this bug against the virt-manager package instead of qemu.
+
+Thanks!
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/1883732 b/results/classifier/118/KVM/1883732
new file mode 100644
index 000000000..90a16a762
--- /dev/null
+++ b/results/classifier/118/KVM/1883732
@@ -0,0 +1,151 @@
+KVM: 0.941
+hypervisor: 0.939
+TCG: 0.926
+ppc: 0.902
+register: 0.899
+peripherals: 0.883
+risc-v: 0.876
+x86: 0.871
+performance: 0.857
+vnc: 0.845
+i386: 0.843
+permissions: 0.841
+user-level: 0.828
+VMM: 0.816
+device: 0.812
+virtual: 0.800
+debug: 0.772
+PID: 0.763
+files: 0.762
+graphic: 0.751
+boot: 0.739
+mistranslation: 0.730
+network: 0.726
+arm: 0.719
+architecture: 0.714
+socket: 0.712
+semantic: 0.667
+kernel: 0.662
+assembly: 0.609
+
+xhci_kick_epctx: Assertion `ring->dequeue != 0' failed.
+
+To reproduce run the QEMU with the following command line:
+```
+qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio
+```
+
+QEMU Version:
+```
+# qemu-5.0.0
+$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make
+$ x86_64-softmmu/qemu-system-x86_64 --version
+QEMU emulator version 5.0.0
+Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
+```
+
+
+
+Here's a QTest reproducer:
+
+cat << EOF | ./i386-softmmu/qemu-system-i386 \
+-device nec-usb-xhci -trace usb\* \
+-device usb-audio -device usb-storage,drive=mydrive \
+-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \
+-nodefaults -nographic -qtest stdio
+outl 0xcf8 0x80001014
+outl 0xcfc 0xff000a8e
+outl 0xcf8 0x80001004
+outl 0xcfc 0x1c77695e
+writel 0xff000a8e00000040 0x1d00d815
+write 0x1d 0x1 0x5c
+write 0x2d 0x1 0x27
+write 0x3d 0x1 0x2e
+write 0xd 0x1 0x60
+write 0x17232 0x1 0x03
+write 0x17254 0x1 0x05
+write 0x4d 0x1 0x5c
+write 0x5d 0x1 0x27
+write 0x60 0x1 0x2e
+write 0x61 0x1 0x72
+write 0x62 0x1 0x01
+write 0x6d 0x1 0x2e
+write 0x6f 0x1 0x01
+writel 0xff000a8e00002000 0x0
+writeq 0xff000a8e00002000 0x514ef0100000009
+EOF
+
+The trace:
+[R +0.031152] writel 0xff000a8e00000040 0x1d00d815
+26994@1597124755.565242:usb_xhci_oper_write off 0x0000, val 0x1d00d815
+26994@1597124755.565247:usb_xhci_run
+26994@1597124755.565252:usb_xhci_irq_intx level 0
+OK
+[S +0.031173] OK
+[R +0.031179] write 0x1d 0x1 0x5c
+OK
+[S +0.031190] OK
+[R +0.031195] write 0x2d 0x1 0x27
+OK
+[S +0.031198] OK
+[R +0.031203] write 0x3d 0x1 0x2e
+OK
+[S +0.031207] OK
+[R +0.031211] write 0xd 0x1 0x60
+OK
+[S +0.031214] OK
+[R +0.031219] write 0x17232 0x1 0x03
+OK
+[S +0.031224] OK
+[R +0.031228] write 0x17254 0x1 0x05
+OK
+[S +0.031231] OK
+[R +0.031236] write 0x4d 0x1 0x5c
+OK
+[S +0.031239] OK
+[R +0.031244] write 0x5d 0x1 0x27
+OK
+[S +0.031247] OK
+[R +0.031251] write 0x60 0x1 0x2e
+OK
+[S +0.031254] OK
+[R +0.031259] write 0x61 0x1 0x72
+OK
+[S +0.031262] OK
+[R +0.031267] write 0x62 0x1 0x01
+OK
+[S +0.031270] OK
+[R +0.031275] write 0x6d 0x1 0x2e
+OK
+[S +0.031278] OK
+[R +0.031282] write 0x6f 0x1 0x01
+OK
+[S +0.031286] OK
+[R +0.031290] writel 0xff000a8e00002000 0x0
+26994@1597124755.565377:usb_xhci_doorbell_write off 0x0000, val 0x00000000
+26994@1597124755.565384:usb_xhci_fetch_trb addr 0x0000000000000000, ???, p 0x0000000000000000, s 0x00000000, c 0x00006000
+26994@1597124755.565390:usb_xhci_unimplemented command (0x18)
+26994@1597124755.565395:usb_xhci_fetch_trb addr 0x0000000000000010, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00
+26994@1597124755.565399:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700
+26994@1597124755.565403:usb_xhci_slot_enable slotid 1
+26994@1597124755.565406:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00
+26994@1597124755.565411:usb_xhci_fetch_trb addr 0x0000000000000040, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00
+26994@1597124755.565416:usb_xhci_fetch_trb addr 0x0000000000000050, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700
+26994@1597124755.565421:usb_xhci_slot_enable slotid 2
+26994@1597124755.565423:usb_xhci_fetch_trb addr 0x0000000000000060, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00
+26994@1597124755.565431:usb_xhci_slot_address slotid 1, port 1
+26994@1597124755.565436:usb_xhci_ep_enable slotid 1, epid 1
+26994@1597124755.565444:usb_xhci_fetch_trb addr 0x0000000000000070, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000
+OK
+[S +0.031365] OK
+[R +0.031370] writeq 0xff000a8e00002000 0x514ef0100000009
+26994@1597124755.565456:usb_xhci_doorbell_write off 0x0000, val 0x00000009
+26994@1597124755.565459:usb_xhci_doorbell_write off 0x0004, val 0x0514ef01
+26994@1597124755.565462:usb_xhci_ep_kick slotid 1, epid 1, streamid 1300
+qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/usb/hcd-xhci.c:1955: void xhci_kick_epctx(XHCIEPContext *, unsigned int): Assertion `ring->dequeue != 0' failed.
+Aborted
+
+-Alex
+
+ClusterFuzz testcase 5662083651469312 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_qemu&range=202011160601:202011170627
+
diff --git a/results/classifier/118/KVM/1914353 b/results/classifier/118/KVM/1914353
new file mode 100644
index 000000000..f6a4dae7a
--- /dev/null
+++ b/results/classifier/118/KVM/1914353
@@ -0,0 +1,91 @@
+KVM: 0.974
+architecture: 0.907
+kernel: 0.807
+graphic: 0.775
+arm: 0.761
+device: 0.739
+PID: 0.720
+ppc: 0.677
+socket: 0.622
+mistranslation: 0.616
+register: 0.548
+risc-v: 0.542
+user-level: 0.530
+vnc: 0.528
+semantic: 0.523
+performance: 0.517
+network: 0.506
+files: 0.506
+permissions: 0.493
+TCG: 0.475
+peripherals: 0.474
+debug: 0.471
+VMM: 0.466
+x86: 0.459
+boot: 0.416
+i386: 0.378
+assembly: 0.347
+hypervisor: 0.292
+virtual: 0.250
+
+QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID
+
+Via [qemu-security] list
+
++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
+| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
+| > Per the ARM Generic Interrupt Controller Architecture specification
+| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
+| > not 10:
+| >
+| >    - Table 4-21 GICD_SGIR bit assignments
+| >
+| >    The Interrupt ID of the SGI to forward to the specified CPU
+| >    interfaces. The value of this field is the Interrupt ID, in
+| >    the range 0-15, for example a value of 0b0011 specifies
+| >    Interrupt ID 3.
+| >
+...
+| > Correct the irq mask to fix an undefined behavior (which eventually
+| > lead to a heap-buffer-overflow, see [Buglink]):
+| >
+| >    $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio
+| >    [I 1612088147.116987] OPENED
+| >  [R +0.278293] writel 0x8000f00 0xff4affb0
+| >  ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]'
+| >  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13
+| >
+| > Cc: <email address hidden>
+| > Fixes: 9ee6e8bb853 ("ARMv7 support.")
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
+| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
+...
+
+On 210202 1221, Peter Maydell wrote:
+> In both cases the overrun is on the first writel to 0x8000f00,
+> but the fuzzer has for some reason not reported that but instead
+> blundered on until it happens to trigger some other issue that
+> resulted from the memory corruption it induced with the first write.
+>
+...
+> On the CVE:
+>
+> Since this can affect systems using KVM, this is a security bug for
+> us. However, it only affects an uncommon configuration:
+> you are only vulnerable if you are using "kernel-irqchip=off"
+> (the default is 'on', and turning it off is an odd thing to do).
+>
+> thanks
+> -- PMM
+>
+
+Upstream patch:
+  -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00709.html
+
+CVE requested.
+
+'CVE-2021-20221' assigned by Red Hat Inc.
+
+Fix has been included here:
+https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bd
+
diff --git a/results/classifier/118/KVM/1914748 b/results/classifier/118/KVM/1914748
new file mode 100644
index 000000000..3de693633
--- /dev/null
+++ b/results/classifier/118/KVM/1914748
@@ -0,0 +1,54 @@
+KVM: 0.970
+architecture: 0.935
+graphic: 0.801
+device: 0.781
+vnc: 0.699
+performance: 0.672
+mistranslation: 0.646
+semantic: 0.623
+kernel: 0.595
+virtual: 0.538
+ppc: 0.531
+network: 0.530
+x86: 0.485
+permissions: 0.458
+hypervisor: 0.436
+arm: 0.413
+register: 0.413
+boot: 0.400
+socket: 0.345
+VMM: 0.344
+files: 0.338
+i386: 0.314
+debug: 0.309
+PID: 0.287
+peripherals: 0.280
+risc-v: 0.241
+TCG: 0.223
+user-level: 0.146
+assembly: 0.137
+
+Confuse error message when KVM can not start requested CPU
+
+As of commit 1ba089f2255, on Cavium CN8890 (ThunderX cores):
+
+$ qemu-system-aarch64 -display none -accel kvm -M virt,gic-version=3 -accel kvm -cpu cortex-a57 --trace \*kvm_vcpu\*      
+kvm_vcpu_ioctl cpu_index 0, type 0x4020aeae, arg 0xffff9b7f9b18 
+qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument
+
+(same using "-cpu cortex-a53" or cortex-a72).
+
+Explanation from Peter Maydell on IRC:
+> using a specific cpu type will only work with KVM if the host CPU really is that
+> exact CPU type, otherwise, use "-cpu host" or "-cpu max"
+
+Having a better error description would help to understand the reason.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/239
+
+
diff --git a/results/classifier/118/KVM/1919169 b/results/classifier/118/KVM/1919169
new file mode 100644
index 000000000..e2c31c177
--- /dev/null
+++ b/results/classifier/118/KVM/1919169
@@ -0,0 +1,51 @@
+x86: 0.929
+KVM: 0.928
+graphic: 0.912
+performance: 0.905
+architecture: 0.876
+device: 0.870
+boot: 0.867
+semantic: 0.827
+PID: 0.825
+virtual: 0.821
+files: 0.815
+mistranslation: 0.770
+vnc: 0.750
+hypervisor: 0.746
+socket: 0.721
+TCG: 0.697
+network: 0.691
+user-level: 0.683
+ppc: 0.667
+kernel: 0.661
+VMM: 0.635
+permissions: 0.622
+risc-v: 0.615
+arm: 0.613
+register: 0.612
+peripherals: 0.596
+debug: 0.536
+i386: 0.284
+assembly: 0.245
+
+[git]Startup crash when trying to use an EFI enabled VM in accel/kvm/kvm-all.c
+
+Hello.
+
+I build a git version based on commit 6157b0e19721aadb4c7fdcfe57b2924af6144b14.
+
+When I try to launch an EFI enabled VM, it crashes on start. Here is the command line used:
+
+qemu-system-x86_64 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -enable-kvm -smp 4 -soundhw all -k fr -m 4096 -vga qxl -hda disk.img -cdrom archlinux-2021.03.01-x86_64.iso -boot cd &
+
+Here is the log I get:
+
+```
+qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: Assertion `QEMU_IS_ALIGNED(start | size, psize)' failed.
+```
+
+
+ed2k-ovmf version: 202102
+
+I tried an older version, edk2-ovmf 202011, same crash on start.
+
diff --git a/results/classifier/118/KVM/1936 b/results/classifier/118/KVM/1936
new file mode 100644
index 000000000..cc082b512
--- /dev/null
+++ b/results/classifier/118/KVM/1936
@@ -0,0 +1,31 @@
+KVM: 0.956
+architecture: 0.886
+device: 0.858
+hypervisor: 0.846
+files: 0.843
+virtual: 0.771
+performance: 0.697
+permissions: 0.627
+mistranslation: 0.606
+peripherals: 0.588
+semantic: 0.549
+kernel: 0.475
+debug: 0.398
+graphic: 0.363
+boot: 0.309
+network: 0.285
+i386: 0.243
+x86: 0.241
+VMM: 0.206
+PID: 0.198
+TCG: 0.179
+arm: 0.150
+assembly: 0.100
+risc-v: 0.089
+socket: 0.087
+user-level: 0.081
+register: 0.074
+vnc: 0.056
+ppc: 0.042
+
+Pass file descriptor to /dev/kvm device node?
diff --git a/results/classifier/118/KVM/2046 b/results/classifier/118/KVM/2046
new file mode 100644
index 000000000..6754d0080
--- /dev/null
+++ b/results/classifier/118/KVM/2046
@@ -0,0 +1,31 @@
+KVM: 0.953
+device: 0.857
+network: 0.850
+kernel: 0.793
+files: 0.681
+VMM: 0.645
+vnc: 0.625
+PID: 0.622
+socket: 0.606
+debug: 0.599
+arm: 0.579
+ppc: 0.567
+graphic: 0.547
+register: 0.545
+TCG: 0.528
+permissions: 0.517
+boot: 0.509
+mistranslation: 0.501
+architecture: 0.457
+hypervisor: 0.436
+peripherals: 0.415
+semantic: 0.362
+performance: 0.342
+i386: 0.278
+x86: 0.220
+risc-v: 0.202
+virtual: 0.117
+assembly: 0.061
+user-level: 0.057
+
+live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm
diff --git a/results/classifier/118/KVM/2060 b/results/classifier/118/KVM/2060
new file mode 100644
index 000000000..b2c01c349
--- /dev/null
+++ b/results/classifier/118/KVM/2060
@@ -0,0 +1,33 @@
+KVM: 0.898
+kernel: 0.811
+mistranslation: 0.752
+architecture: 0.740
+device: 0.728
+semantic: 0.722
+network: 0.605
+graphic: 0.530
+hypervisor: 0.511
+performance: 0.358
+peripherals: 0.314
+VMM: 0.304
+permissions: 0.282
+register: 0.282
+virtual: 0.280
+boot: 0.278
+socket: 0.270
+files: 0.248
+PID: 0.235
+debug: 0.235
+vnc: 0.204
+ppc: 0.196
+x86: 0.139
+i386: 0.082
+TCG: 0.064
+user-level: 0.054
+arm: 0.033
+assembly: 0.026
+risc-v: 0.020
+
+memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
+Additional information:
+i'm using pve-qemu-kvm 8.1.2-6 on 6.5.11-7-pve kernel
diff --git a/results/classifier/118/KVM/2110 b/results/classifier/118/KVM/2110
new file mode 100644
index 000000000..ac1279f4e
--- /dev/null
+++ b/results/classifier/118/KVM/2110
@@ -0,0 +1,41 @@
+KVM: 0.913
+device: 0.897
+graphic: 0.895
+vnc: 0.860
+PID: 0.859
+socket: 0.853
+network: 0.836
+performance: 0.804
+kernel: 0.791
+ppc: 0.781
+VMM: 0.762
+architecture: 0.729
+files: 0.714
+risc-v: 0.699
+semantic: 0.696
+TCG: 0.690
+register: 0.665
+hypervisor: 0.626
+i386: 0.605
+x86: 0.564
+boot: 0.559
+mistranslation: 0.443
+debug: 0.440
+permissions: 0.437
+arm: 0.417
+virtual: 0.387
+assembly: 0.222
+peripherals: 0.214
+user-level: 0.208
+
+live migrations fail qemu-kvm
+Description of problem:
+live migrations fail between two identical hosts
+```
+2024-01-18T00:16:31.582070Z qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm
+2024-01-18T00:16:31.582169Z qemu-kvm: load of migration failed: Invalid argument
+2024-01-18 00:16:31.611+0000: shutting down, reason=failed
+```
+Additional information:
+source log for vm [source.log](/uploads/5816f929a5e543f423bb909a0df23fb7/source.log)
+dest log for vm   [dest.log](/uploads/a1b6ae02e4c8235536e740b86d16ddd6/dest.log)
diff --git a/results/classifier/118/KVM/2313 b/results/classifier/118/KVM/2313
new file mode 100644
index 000000000..d73476154
--- /dev/null
+++ b/results/classifier/118/KVM/2313
@@ -0,0 +1,47 @@
+KVM: 0.982
+risc-v: 0.902
+architecture: 0.775
+device: 0.705
+graphic: 0.685
+ppc: 0.616
+semantic: 0.583
+PID: 0.578
+files: 0.484
+vnc: 0.469
+permissions: 0.445
+peripherals: 0.440
+hypervisor: 0.429
+network: 0.389
+TCG: 0.374
+socket: 0.369
+boot: 0.362
+register: 0.355
+performance: 0.330
+debug: 0.318
+VMM: 0.312
+mistranslation: 0.290
+kernel: 0.230
+user-level: 0.203
+virtual: 0.195
+arm: 0.121
+assembly: 0.082
+x86: 0.059
+i386: 0.034
+
+RISC-V KVM strerrorname_np regression breaks build on Alpine Linux
+Description of problem:
+Build from source fails on Alpine Linux due to the use of the non-portable `strerrorname_np`:
+```
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_realize':
+kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np'
+/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_instance_init':
+kvm-cpu.c:(.text+0x1244): undefined reference to `strerrorname_np'
+```
+Steps to reproduce:
+1. install alpine linux on a riscv64 machine
+2. build qemu-9.0.0 from source.
+3.
+Additional information:
+Same problem as https://gitlab.com/qemu-project/qemu/-/issues/2041
+
+Re-introduced with d4ff3da8f45c52670941c6e1b94e771d69d887e9 and 0d71f0a34938a6ac11953ae3dbec40113d2838a1
diff --git a/results/classifier/118/KVM/239 b/results/classifier/118/KVM/239
new file mode 100644
index 000000000..2d2e60666
--- /dev/null
+++ b/results/classifier/118/KVM/239
@@ -0,0 +1,31 @@
+KVM: 0.991
+mistranslation: 0.988
+architecture: 0.974
+arm: 0.915
+hypervisor: 0.870
+device: 0.831
+debug: 0.763
+graphic: 0.750
+performance: 0.739
+semantic: 0.698
+virtual: 0.616
+boot: 0.476
+risc-v: 0.429
+TCG: 0.230
+register: 0.171
+user-level: 0.160
+vnc: 0.138
+ppc: 0.137
+PID: 0.128
+peripherals: 0.066
+permissions: 0.060
+assembly: 0.050
+i386: 0.027
+socket: 0.022
+files: 0.014
+network: 0.011
+kernel: 0.008
+VMM: 0.008
+x86: 0.003
+
+Confusing error message when KVM can not start requested ARM CPU
diff --git a/results/classifier/118/KVM/2392 b/results/classifier/118/KVM/2392
new file mode 100644
index 000000000..b6643c683
--- /dev/null
+++ b/results/classifier/118/KVM/2392
@@ -0,0 +1,31 @@
+KVM: 0.961
+hypervisor: 0.915
+virtual: 0.834
+device: 0.804
+performance: 0.606
+semantic: 0.491
+arm: 0.476
+boot: 0.378
+mistranslation: 0.333
+architecture: 0.317
+network: 0.225
+graphic: 0.200
+permissions: 0.195
+user-level: 0.192
+risc-v: 0.175
+files: 0.140
+register: 0.135
+debug: 0.093
+ppc: 0.092
+vnc: 0.064
+assembly: 0.046
+PID: 0.040
+socket: 0.032
+peripherals: 0.022
+i386: 0.016
+kernel: 0.014
+TCG: 0.008
+VMM: 0.004
+x86: 0.003
+
+Ability to use KVM on Windows
diff --git a/results/classifier/118/KVM/2394 b/results/classifier/118/KVM/2394
new file mode 100644
index 000000000..9a69727d4
--- /dev/null
+++ b/results/classifier/118/KVM/2394
@@ -0,0 +1,59 @@
+KVM: 0.995
+graphic: 0.991
+VMM: 0.979
+performance: 0.968
+device: 0.952
+semantic: 0.907
+user-level: 0.868
+network: 0.861
+kernel: 0.850
+hypervisor: 0.839
+PID: 0.833
+files: 0.831
+virtual: 0.802
+socket: 0.769
+architecture: 0.751
+ppc: 0.729
+permissions: 0.711
+arm: 0.707
+peripherals: 0.698
+mistranslation: 0.694
+boot: 0.693
+risc-v: 0.691
+debug: 0.676
+register: 0.644
+vnc: 0.624
+i386: 0.544
+x86: 0.485
+TCG: 0.436
+assembly: 0.423
+
+kvm-unit-tests vmx failed
+Description of problem:
+On the Sierra Forest platform, the vmx test in kvm-unit-tests failed. But this issue cannot be replicated on Emerald Rapids platform.
+
+The first bad commit is ba6780905943696d790cc880c8e5684b51f027fe.
+Steps to reproduce:
+1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git
+
+2.cd kvm-unit-tests; ./configure
+
+3.make standalone
+
+4.rmmod kvm_intel
+
+5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y
+
+6.cd tests; ./vmx
+Additional information:
+...
+FAIL: HOST_CR3 2000000001007000: vmlaunch fails
+
+FAIL: HOST_CR3 4000000001007000: vmlaunch fails
+...
+
+SUMMARY: 430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped
+
+FAIL vmx (430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped)
+
+[error.log](/uploads/02456b40f2736c0bf34d3f4b3a0c872a/error.log)
diff --git a/results/classifier/118/KVM/252 b/results/classifier/118/KVM/252
new file mode 100644
index 000000000..09f378d9d
--- /dev/null
+++ b/results/classifier/118/KVM/252
@@ -0,0 +1,31 @@
+KVM: 0.975
+architecture: 0.904
+device: 0.883
+peripherals: 0.760
+arm: 0.636
+virtual: 0.618
+performance: 0.560
+graphic: 0.526
+debug: 0.512
+hypervisor: 0.500
+semantic: 0.449
+permissions: 0.409
+risc-v: 0.372
+network: 0.346
+register: 0.299
+mistranslation: 0.289
+user-level: 0.205
+vnc: 0.191
+files: 0.185
+ppc: 0.173
+TCG: 0.090
+PID: 0.084
+boot: 0.068
+i386: 0.055
+kernel: 0.053
+assembly: 0.029
+socket: 0.023
+VMM: 0.017
+x86: 0.001
+
+KVM Old ATI(pre) AMD card passthrough is not working
diff --git a/results/classifier/118/KVM/2573 b/results/classifier/118/KVM/2573
new file mode 100644
index 000000000..b706cc639
--- /dev/null
+++ b/results/classifier/118/KVM/2573
@@ -0,0 +1,39 @@
+risc-v: 0.996
+architecture: 0.988
+KVM: 0.980
+device: 0.873
+virtual: 0.813
+TCG: 0.797
+vnc: 0.789
+x86: 0.764
+graphic: 0.704
+performance: 0.700
+files: 0.670
+arm: 0.583
+boot: 0.559
+semantic: 0.555
+permissions: 0.540
+VMM: 0.528
+PID: 0.485
+register: 0.467
+socket: 0.455
+debug: 0.429
+hypervisor: 0.393
+ppc: 0.378
+network: 0.376
+i386: 0.345
+kernel: 0.321
+mistranslation: 0.273
+user-level: 0.151
+peripherals: 0.096
+assembly: 0.033
+
+RISC-V: Executing floating point instruction in VS mode under KVM acceleration leads to crash
+Description of problem:
+Executing `fcvt.d.w fa5,a5` in VS mode leads to crash.
+Steps to reproduce:
+1. Download the Ubuntu 24.10 image https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oracular-preinstalled-server-riscv64.img.xz
+2. On your amd64 system launch a VM using -accel tcg
+3. Inside the VM launch a new VM using -accel kvm with the payload mentioned above
+Additional information:
+For more details see https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2077731
diff --git a/results/classifier/118/KVM/2658 b/results/classifier/118/KVM/2658
new file mode 100644
index 000000000..8ea699d33
--- /dev/null
+++ b/results/classifier/118/KVM/2658
@@ -0,0 +1,31 @@
+KVM: 0.953
+register: 0.937
+virtual: 0.784
+device: 0.743
+performance: 0.566
+hypervisor: 0.560
+network: 0.452
+architecture: 0.314
+graphic: 0.307
+arm: 0.295
+boot: 0.287
+debug: 0.282
+semantic: 0.183
+peripherals: 0.177
+ppc: 0.130
+risc-v: 0.102
+mistranslation: 0.075
+i386: 0.055
+vnc: 0.048
+assembly: 0.048
+TCG: 0.030
+user-level: 0.022
+permissions: 0.017
+kernel: 0.014
+PID: 0.013
+socket: 0.007
+files: 0.006
+x86: 0.004
+VMM: 0.003
+
+How to simulate the L2MERRSR_EL1 register in KVM mode？
diff --git a/results/classifier/118/KVM/2692 b/results/classifier/118/KVM/2692
new file mode 100644
index 000000000..e9e0a18c7
--- /dev/null
+++ b/results/classifier/118/KVM/2692
@@ -0,0 +1,31 @@
+KVM: 0.980
+device: 0.799
+architecture: 0.740
+virtual: 0.661
+network: 0.635
+socket: 0.570
+performance: 0.556
+arm: 0.532
+peripherals: 0.473
+debug: 0.337
+assembly: 0.333
+graphic: 0.319
+semantic: 0.290
+files: 0.261
+PID: 0.246
+i386: 0.236
+risc-v: 0.223
+boot: 0.219
+hypervisor: 0.209
+ppc: 0.201
+register: 0.201
+TCG: 0.134
+vnc: 0.128
+mistranslation: 0.097
+x86: 0.087
+permissions: 0.074
+user-level: 0.074
+kernel: 0.008
+VMM: 0.008
+
+Using the ldp instruction to access the I/O address space in KVM mode causes an exception
diff --git a/results/classifier/118/KVM/391880 b/results/classifier/118/KVM/391880
new file mode 100644
index 000000000..cde106e68
--- /dev/null
+++ b/results/classifier/118/KVM/391880
@@ -0,0 +1,44 @@
+KVM: 0.922
+graphic: 0.908
+device: 0.825
+performance: 0.791
+virtual: 0.729
+network: 0.622
+architecture: 0.597
+vnc: 0.573
+arm: 0.568
+semantic: 0.547
+socket: 0.474
+VMM: 0.471
+user-level: 0.451
+files: 0.428
+hypervisor: 0.417
+risc-v: 0.416
+boot: 0.381
+debug: 0.366
+peripherals: 0.360
+PID: 0.353
+mistranslation: 0.347
+ppc: 0.345
+i386: 0.345
+kernel: 0.342
+x86: 0.311
+permissions: 0.273
+register: 0.240
+TCG: 0.160
+assembly: 0.036
+
+migrate exec hangs for several minutes if the pipe is closed before all its data is written
+
+Binary package hint: kvm
+
+Using
+
+  migrate "exec:true"
+
+in the monitor hangs the VM for several minutes. What I expect is that the VM stops attempting to migrate after the pipe has been closed.
+
+Indicating a background migrate with -d doesn't help. Presumably the migration is not backgrounded until a certain amount of data is written to the pipe, or the migration times out What I expect is that the migration is backgrounded immediately.
+
+I can reproduce this in Lucid.  Like the other related bug report, I don't have a strong opinion on the feature request, though it seems reasonable.  We will defer to Upstream's decision on this one.  Thanks!
+
diff --git a/results/classifier/118/KVM/412 b/results/classifier/118/KVM/412
new file mode 100644
index 000000000..4db9f8aad
--- /dev/null
+++ b/results/classifier/118/KVM/412
@@ -0,0 +1,31 @@
+KVM: 0.871
+device: 0.858
+kernel: 0.835
+network: 0.824
+arm: 0.773
+vnc: 0.738
+architecture: 0.703
+performance: 0.699
+VMM: 0.630
+ppc: 0.604
+TCG: 0.545
+boot: 0.531
+risc-v: 0.478
+debug: 0.473
+hypervisor: 0.468
+graphic: 0.416
+x86: 0.348
+i386: 0.346
+socket: 0.337
+assembly: 0.283
+files: 0.265
+PID: 0.257
+register: 0.247
+virtual: 0.229
+semantic: 0.221
+user-level: 0.211
+peripherals: 0.208
+permissions: 0.144
+mistranslation: 0.098
+
+stable-5.0 crashes with SIGSEV while checking for kvm extension
diff --git a/results/classifier/118/KVM/528 b/results/classifier/118/KVM/528
new file mode 100644
index 000000000..e0a4ff087
--- /dev/null
+++ b/results/classifier/118/KVM/528
@@ -0,0 +1,31 @@
+arm: 0.996
+KVM: 0.969
+architecture: 0.931
+hypervisor: 0.887
+device: 0.816
+performance: 0.677
+debug: 0.583
+risc-v: 0.530
+files: 0.493
+graphic: 0.490
+ppc: 0.451
+vnc: 0.424
+PID: 0.392
+boot: 0.366
+semantic: 0.360
+i386: 0.303
+TCG: 0.301
+x86: 0.258
+register: 0.226
+assembly: 0.181
+mistranslation: 0.160
+virtual: 0.146
+network: 0.131
+user-level: 0.128
+permissions: 0.076
+VMM: 0.075
+socket: 0.068
+peripherals: 0.044
+kernel: 0.021
+
+arm: trying to use KVM with an EL3-enabled CPU hits an assertion failure
diff --git a/results/classifier/118/KVM/530077 b/results/classifier/118/KVM/530077
new file mode 100644
index 000000000..289d25430
--- /dev/null
+++ b/results/classifier/118/KVM/530077
@@ -0,0 +1,46 @@
+KVM: 0.898
+graphic: 0.810
+device: 0.589
+semantic: 0.536
+boot: 0.533
+performance: 0.484
+architecture: 0.483
+hypervisor: 0.467
+kernel: 0.405
+socket: 0.359
+network: 0.350
+user-level: 0.330
+register: 0.317
+permissions: 0.296
+vnc: 0.281
+mistranslation: 0.255
+debug: 0.250
+i386: 0.250
+PID: 0.230
+virtual: 0.227
+risc-v: 0.223
+ppc: 0.218
+files: 0.202
+x86: 0.195
+peripherals: 0.137
+arm: 0.131
+TCG: 0.111
+VMM: 0.109
+assembly: 0.055
+
+kvm: 16-bit code execution failure should be more friendly
+
+Today, when kvm fails at 16-bit code execution, we report:
+
+     spirit:~/qemu> qemu-kvm ./hda-fedora.img 
+     kvm: unhandled exit 80000021
+     kvm_run returned -22
+
+There are three reasons exit reason 21 happens.  The first is that a user is executing an image containing a workload that uses GFXBOOT or some other bootloader that exercises big real mode.  On pre-Westmere Intel processors, VT could not handle big real mode.  The second reason is that the guest's image is corrupted and we're executing random code.  We accidentally fall into one of the unsupported modes for VT.  Again, this is addressed on WSM.  The third case is where there's an actual bug in KVM.  This should be exceedingly rare at this stage.
+
+We should present a friendly error message explaining the possible causes and recommending corrective action.
+
+Triaging old bug tickets... has this ever been fixed, thus could we close this ticket nowadays? Or is there something left to do here?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/584514 b/results/classifier/118/KVM/584514
new file mode 100644
index 000000000..f8f74ab7e
--- /dev/null
+++ b/results/classifier/118/KVM/584514
@@ -0,0 +1,66 @@
+KVM: 0.913
+device: 0.664
+performance: 0.605
+graphic: 0.585
+ppc: 0.492
+semantic: 0.455
+hypervisor: 0.406
+kernel: 0.357
+socket: 0.312
+architecture: 0.290
+permissions: 0.287
+register: 0.285
+mistranslation: 0.282
+peripherals: 0.271
+PID: 0.269
+network: 0.264
+virtual: 0.263
+user-level: 0.245
+x86: 0.219
+vnc: 0.210
+assembly: 0.207
+arm: 0.204
+i386: 0.181
+debug: 0.169
+boot: 0.144
+risc-v: 0.113
+files: 0.106
+TCG: 0.088
+VMM: 0.084
+
+Qemu-KVM 0.12.4 Guest entered Paused State
+
+I recently had a 0.12.4 qemu-kvm with a debian lenny guest which occasionally paused.
+
+There was no memory exhaustion as suggested earlier.
+
+qemu-kvm send the following output::
+
+VM internal error. Suberror: 1
+rax 0000000000000100 rbx ffff880017585bc0 rcx 00007f84c6d5b000 rdx 0000000000000001
+rsi 0000000000000000 rdi ffff88001d322dec rsp ffff88001e133e88 rbp ffff88001e133e88
+r8  0000000001f25bc2 r9  0000000000000007 r10 00007f84c6b4d97b r11 0000000000000206
+r12 ffff88001d322dec r13 ffff88001d322de8 r14 0000000000000001 r15 0000000000000000
+rip ffffffff81039719 rflags 00010092
+cs 0010 (00000000/ffffffff p 1 dpl 0 db 0 s 1 type b l 1 g 1 avl 0)
+ds 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+es 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+ss 0018 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0)
+fs 0000 (7f84c6d53700/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+gs 0000 (ffff880001d00000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+tr 0040 (ffff880001d13780/00002087 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0)
+ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0)
+gdt ffff880001d04000/7f
+idt ffffffff8195e000/fff
+cr0 80050033 cr2 7f84c6b38ec8 cr3 1db7d000 cr4 6e0 cr8 0 efer 501
+emulation failure, check dmesg for details
+
+Unfortunately, I found nothing in syslog or dmesg
+
+How about the qemu process，in which state？ will it be blocking？ 
+
+
+QEMU 0.12 is pretty old nowadays - is this issue still reproducible with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/612452 b/results/classifier/118/KVM/612452
new file mode 100644
index 000000000..9aa7df29e
--- /dev/null
+++ b/results/classifier/118/KVM/612452
@@ -0,0 +1,157 @@
+KVM: 0.861
+hypervisor: 0.843
+mistranslation: 0.799
+virtual: 0.769
+user-level: 0.768
+risc-v: 0.765
+VMM: 0.758
+TCG: 0.758
+peripherals: 0.756
+permissions: 0.744
+ppc: 0.728
+vnc: 0.724
+arm: 0.720
+device: 0.690
+debug: 0.667
+register: 0.658
+semantic: 0.650
+PID: 0.648
+assembly: 0.647
+boot: 0.645
+architecture: 0.637
+performance: 0.624
+files: 0.622
+socket: 0.600
+graphic: 0.586
+kernel: 0.552
+x86: 0.521
+i386: 0.502
+network: 0.445
+
+Problems with the number of serial ports for more than two
+
+qemu --version
+QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard
+
+Command line:
+
+qemu -serial null -serial null -serial file:test1 hd.img
+
+Error:
+
+isa irq 4 already assigned
+
+echo $?
+1
+
+This bug seems to be solved and closed here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051
+
+Is it solved in 0.12.5 or 0.13.0rc1 yet? 
+
+
+> This bug seems to be solved and closed here: http://bugs.debian.org/cgi-
+> bin/bugreport.cgi?bug=574051
+>
+> Is it solved in 0.12.5 or 0.13.0rc1 yet?
+>
+> ** Bug watch added: Debian Bug tracker #574051
+>    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051
+>   
+#cd qemu-snapshot
+#date
+Fri Sep 17 09:29:01 MSD 2010
+#cat .git/config
+...
+[remote "origin"]
+    url = git://git.savannah.nongnu.org/qemu.git
+    fetch = +refs/heads/*:refs/remotes/origin/*
+[branch "master"]
+    remote = origin
+    merge = refs/heads/master
+
+#git pull
+...
+#./configure --disable-xen --audio-drv-list=alsa,sdl
+#make && make install
+...
+install -m 755 qemu "/usr/local/bin"
+...
+#ls -l /usr/local/bin/qemu
+#-rwxr-xr-x 1 root root 1960900 2010-09-17 09:45 /usr/local/bin/qemu
+#/usr/local/bin/qemu --version
+QEMU emulator version 0.13.50, Copyright (c) 2003-2008 Fabrice Bellard
+#cd /path/to/hd/image
+#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial none 
+-serial none hd.img
+
+In VM
+
+#echo test1 >/dev/ttyS0
+#echo test2 >/dev/ttyS1
+#echo test3 >/dev/ttyS2
+... error...
+#echo test4 >/dev/ttyS3
+... error...
+
+It is right
+
+#halt
+
+
+In host
+
+#ls -l file*
+-rw-r--r-- 1 root root 7 2010-09-17 10:13 file1
+-rw-r--r-- 1 root root  7 2010-09-17 10:12 file2
+
+
+Excellent. Try next.
+
+#rm -f file*
+#/usr/local/bin/qemu -serial file:file1 -serial file:file2 -serial 
+file:file3 -serial none hd.img
+isa irq 4 already assigned
+
+Misfire. Try next.
+
+#/usr/local/bin/qemu -serial none -serial none -serial file:file3 
+-serial file:file4 hd.img
+
+In VM
+
+#echo test1 >/dev/ttyS0
+#echo test2 >/dev/ttyS1
+#echo test3 >/dev/ttyS2
+... error...
+#echo test4 >/dev/ttyS3
+... error...
+
+OOPS! Surprise.
+
+#halt
+
+
+In host
+
+#ls -l file*
+-rw-r--r-- 1 root root 7 2010-09-17 10:40 file3
+-rw-r--r-- 1 root root  7 2010-09-17 10:40 file4
+
+In this case expected.
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/645524 b/results/classifier/118/KVM/645524
new file mode 100644
index 000000000..964fc9f94
--- /dev/null
+++ b/results/classifier/118/KVM/645524
@@ -0,0 +1,42 @@
+KVM: 0.894
+graphic: 0.791
+peripherals: 0.787
+device: 0.735
+performance: 0.686
+kernel: 0.617
+mistranslation: 0.550
+semantic: 0.538
+user-level: 0.534
+vnc: 0.511
+virtual: 0.505
+socket: 0.453
+boot: 0.442
+network: 0.421
+register: 0.405
+ppc: 0.372
+architecture: 0.369
+VMM: 0.349
+PID: 0.341
+risc-v: 0.330
+permissions: 0.327
+arm: 0.290
+hypervisor: 0.289
+assembly: 0.257
+TCG: 0.228
+debug: 0.224
+i386: 0.222
+x86: 0.149
+files: 0.099
+
+No picture from USB webcam (kvm 0.13-rc1)
+
+I export my Linux webcam to KVM using the switches "-usb -usbdevice host:046d:0929". The XP guest sees the webcam and the drivers install, but the camera only shows a black image. When I open the camera in Windows Explorer, it says "0 images" and a black image, while on a real XP, it says "1 image" and shows the video from the camera. Same problem with different webcams. Same cameras work fine on a native XP install.
+
+Thanks for the report.
+
+Can you tell me if it works with a Linux guest?
+
+Can you tell me what kind of camera it is (e.g. the descriptors from lsusb -v for the device)?
+
+Since there hasn't been any response to the question in comment #1, and version 0.13 is very outdated nowadays, I'm closing this ticket now. If you've still got USB problems with the very latest version of QEMU, please feel free to re-open this ticket again, or open a new ticket instead.
+
diff --git a/results/classifier/118/KVM/73 b/results/classifier/118/KVM/73
new file mode 100644
index 000000000..cd8d57603
--- /dev/null
+++ b/results/classifier/118/KVM/73
@@ -0,0 +1,31 @@
+KVM: 0.971
+peripherals: 0.894
+device: 0.860
+virtual: 0.724
+architecture: 0.701
+debug: 0.667
+performance: 0.549
+arm: 0.519
+boot: 0.392
+graphic: 0.365
+risc-v: 0.353
+hypervisor: 0.329
+ppc: 0.289
+mistranslation: 0.268
+semantic: 0.250
+register: 0.250
+PID: 0.194
+TCG: 0.162
+user-level: 0.151
+vnc: 0.147
+network: 0.145
+VMM: 0.092
+socket: 0.087
+files: 0.044
+kernel: 0.029
+permissions: 0.020
+i386: 0.009
+assembly: 0.006
+x86: 0.002
+
+KVM Windows 98 sound card passthrough is not working for DOS programs..
diff --git a/results/classifier/118/KVM/735 b/results/classifier/118/KVM/735
new file mode 100644
index 000000000..1d721abd3
--- /dev/null
+++ b/results/classifier/118/KVM/735
@@ -0,0 +1,56 @@
+KVM: 0.962
+mistranslation: 0.953
+graphic: 0.944
+virtual: 0.917
+debug: 0.908
+kernel: 0.841
+VMM: 0.739
+device: 0.737
+performance: 0.732
+ppc: 0.657
+TCG: 0.640
+x86: 0.636
+vnc: 0.631
+register: 0.628
+risc-v: 0.623
+architecture: 0.613
+hypervisor: 0.611
+PID: 0.515
+user-level: 0.503
+semantic: 0.495
+network: 0.489
+socket: 0.483
+files: 0.456
+permissions: 0.438
+peripherals: 0.403
+i386: 0.390
+arm: 0.384
+boot: 0.329
+assembly: 0.250
+
+softmmu 'at' not behaving
+Description of problem:
+This looks like a bug to me, please correct if I'm wrong. The execution context is EL2 here and we run KVM vms on top of the system emulation. Anyway, here we have stopped in the EL2 and want to translate a virtual address '0' with 'at'. While the '0' itself is not mapped, something in the first gigabyte is, and the softmmu refuses to walk to it:
+
+0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0
+0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1
+
+(gdb) info registers x0 x1
+x0             0x0                 0
+x1             0x809               2057
+
+So that would be translation fault level 0, stage 1 if I'm not mistaken.
+
+(gdb) info all-registers TCR_EL1 VTCR_EL2 TTBR1_EL1
+TCR_EL1        0x400035b5503510    18014629184681232
+VTCR_EL2       0x623590            6436240
+TTBR1_EL1      0x304000041731001   217298683118686209
+
+(gdb) p print_table(0x41731000)
+000:0x000000ffff9803 256:0x000000fffff803 507:0x00000041fbc803
+508:0x000000ff9ef803
+
+The first gigabyte is populated, yet the 'at' knows nothing about it. Did I miss something? This seems to be working fine on the hardware.
+Steps to reproduce:
+1. Stop in the EL2 while the linux is running (GDB)
+2. Use something along the lines of this function to translate any kernel virtual address: https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74
diff --git a/results/classifier/118/KVM/748 b/results/classifier/118/KVM/748
new file mode 100644
index 000000000..15fc6ff4f
--- /dev/null
+++ b/results/classifier/118/KVM/748
@@ -0,0 +1,31 @@
+KVM: 0.888
+hypervisor: 0.874
+architecture: 0.807
+device: 0.807
+network: 0.763
+performance: 0.748
+risc-v: 0.592
+VMM: 0.526
+vnc: 0.526
+PID: 0.514
+TCG: 0.496
+arm: 0.491
+register: 0.483
+boot: 0.480
+kernel: 0.468
+ppc: 0.461
+graphic: 0.437
+socket: 0.403
+files: 0.398
+semantic: 0.327
+debug: 0.289
+virtual: 0.285
+x86: 0.257
+i386: 0.256
+permissions: 0.219
+peripherals: 0.123
+assembly: 0.119
+mistranslation: 0.076
+user-level: 0.074
+
+Enable postcopy migration for mixed Hugepage backed KVM guests and improve handling of dirty-page tracking by QEMU/KVM
diff --git a/results/classifier/118/KVM/916 b/results/classifier/118/KVM/916
new file mode 100644
index 000000000..a297b15da
--- /dev/null
+++ b/results/classifier/118/KVM/916
@@ -0,0 +1,41 @@
+i386: 0.978
+KVM: 0.977
+x86: 0.970
+graphic: 0.881
+device: 0.851
+architecture: 0.793
+register: 0.776
+performance: 0.727
+PID: 0.702
+semantic: 0.689
+ppc: 0.663
+vnc: 0.607
+debug: 0.585
+virtual: 0.552
+socket: 0.514
+network: 0.497
+files: 0.481
+arm: 0.480
+boot: 0.468
+TCG: 0.417
+permissions: 0.372
+risc-v: 0.361
+mistranslation: 0.329
+VMM: 0.308
+assembly: 0.259
+kernel: 0.246
+hypervisor: 0.189
+user-level: 0.177
+peripherals: 0.103
+
+QEMU system emulators immediately crash on AMD hosts when KVM is used
+Description of problem:
+```
+$ qemu-system-x86_64  -accel kvm
+qemu-system-x86_64: ../target/i386/kvm/kvm-cpu.c:105: kvm_cpu_xsave_init: Assertion `esa->size == eax' failed.
+Aborted (core dumped)
+```
+
+This is a regression introduced in
+
+https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg04312.html
diff --git a/results/classifier/118/KVM/922355 b/results/classifier/118/KVM/922355
new file mode 100644
index 000000000..b86691877
--- /dev/null
+++ b/results/classifier/118/KVM/922355
@@ -0,0 +1,44 @@
+KVM: 0.881
+architecture: 0.816
+device: 0.810
+socket: 0.803
+vnc: 0.772
+ppc: 0.730
+graphic: 0.708
+mistranslation: 0.695
+network: 0.694
+PID: 0.677
+kernel: 0.588
+arm: 0.548
+hypervisor: 0.540
+x86: 0.532
+performance: 0.527
+user-level: 0.502
+semantic: 0.487
+i386: 0.419
+virtual: 0.398
+debug: 0.365
+peripherals: 0.360
+permissions: 0.340
+TCG: 0.331
+risc-v: 0.314
+boot: 0.298
+files: 0.291
+assembly: 0.275
+register: 0.271
+VMM: 0.143
+
+qemu crashes when invoked on Pandaboard
+
+root@omap:~# uname -a
+Linux omap 3.1.6-x6 #1 SMP Thu Dec 22 11:17:51 UTC 2011 armv7l armv7l
+armv7l GNU/Linux
+
+root@omap:~# qemu
+Could not initialize KVM, will disable KVM support
+/build/buildd/qemu-kvm-0.14.1+noroms/tcg/arm/tcg-target.c:848: tcg fatal error
+
+QEMU 0.14 is pretty much outdated nowadays ... Can you still reproduce this problem with the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/118/KVM/957 b/results/classifier/118/KVM/957
new file mode 100644
index 000000000..e5995a800
--- /dev/null
+++ b/results/classifier/118/KVM/957
@@ -0,0 +1,101 @@
+KVM: 0.905
+user-level: 0.897
+hypervisor: 0.857
+VMM: 0.839
+TCG: 0.837
+vnc: 0.830
+peripherals: 0.826
+graphic: 0.819
+ppc: 0.819
+risc-v: 0.797
+x86: 0.793
+debug: 0.783
+virtual: 0.778
+permissions: 0.773
+i386: 0.771
+arm: 0.770
+register: 0.758
+mistranslation: 0.752
+semantic: 0.741
+boot: 0.740
+performance: 0.739
+socket: 0.712
+assembly: 0.709
+device: 0.705
+kernel: 0.702
+PID: 0.699
+architecture: 0.694
+network: 0.690
+files: 0.640
+
+qemu-m68k: python runtime failures, "The futex facility returned an unexpected error code."
+Description of problem:
+The python interpreter (both Python 3.9 and Python 3.10) crashes during a rebuild of Python itself (fairly reproducible but not always at the same point of the build; using MAKEOPTS=-j1 or running under high system load decreases the probability, as does using the qemu -systrace switch). The output is
+```
+The futex facility returned an unexpected error code.
+```
+
+Digging into glibc sources, this error together with an abort occurs when the return value of a futex call is not in a short list of allowed values, see ``nptl/futex-internal.c`` and ``sysdeps/nptl/futex-internal.h``.
+
+Running qemu with QEMU_STRACE=1 decreases the probability of the error greatly, but after some attempts I was able to get a log. Several threads seem to write at the same time, leading to rather garbled output, but my interpretation is an error value of "Invalid argument".
+
+
+```
+116876 get_thread_area(0x00000001) = 989882672
+116876 116876 get_thread_area(0x00000001)get_thread_area(0x00000018) = 989882672
+ = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 futex(0x3f5003fa,FUTEX_PRIVATE_FLAG|FUTEX_WAIT116876 ,2,116876 NULL,0x3fffda10,get_thread_area(0xffffffff) = 1065219744
+futex(0x3f5003fa,1073732112)FUTEX_PRIVATE_FLAG|FUTEX_WAIT = ,2,NULL,-1 errno=22 (Invalid argument)116876 get_thread_area(0x00000000)
+ = 1065219744
+0x3fffda10,116876 get_thread_area(0x00000000)1073732112 = )1065219744
+116876 futex(0x3f7d4c34,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL, = 0)-1 errno=22 (Invalid argument)
+ = 0
+ = 116876 get_thread_area(0x3f7d4c34)1 = 
+116876 get_thread_area(0x00000000) = 1065219744
+926968112
+116876 get_thread_area(0x00000016) = 926968112
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000000) = 1065219744
+116876 get_thread_area(0x00000001)116876  = futex(116876 0x3f5003fa,get_thread_area(0x00000000)FUTEX_PRIVATE_FLAG| = 926968112
+116876 get_thread_area(0x00000000) = 926968112FUTEX_WAKE
+,1,116876 NULL,0x3fffda10,get_thread_area(0x00000000) = 926968112
+1065219744
+116876 get_thread_area(0x00000001)116876  = 1065219744
+1073732112) = 116876 -1 errno=22 (Invalid argument)
+futex(0x3ba005fc,FUTEX_PRIVATE_FLAG|FUTEX_CLOCK_REALTIME|FUTEX_WAIT_BITSET,0,NULL,NULL,get_thread_area(0x00000000)0 = 926968112)
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c38,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,0x40007bf8,1073773560) = 0
+116876 futex(0x40053a8c,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+ = 0
+116876 get_thread_area(0x40053a8c) = 885025072
+116876 get_thread_area(0x00000001) = 885025072
+116876 get_thread_area(0x00b4b456) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00000000) = 885025072
+116876 Unknown syscall 403
+116876 get_thread_area(0x00000000) = 885025072
+116876 get_thread_area(0x00003baa) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 get_thread_area(0x00003b01) = 885025072
+116876 116876 futex(get_thread_area(0x00b4b456)0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAIT_BITSET,0,0x34bfe62c,NULL,0) = 926968112
+116876 get_thread_area(0x00000018) = 926968112
+116876 get_thread_area(0x3ed5b9c8) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000000) = 926968112
+116876 futex(0x3f7d4c30,FUTEX_PRIVATE_FLAG|FUTEX_WAKE,1,NULL,NULL,0) = 1
+116876 get_thread_area(0x00000000) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x0000000f) = 926968112116876  = 0
+
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001) = 926968112
+116876 get_thread_area(0x00000001)writev(2,0x3affed88,0x1) = 926968112
+The futex facility returned an unexpected error code.
+116876 get_thread_area(0x3f7d4c30) = 885025072
+```
+
+Advice on how to do further debuggging is appreciated.
diff --git a/results/classifier/118/KVM/966316 b/results/classifier/118/KVM/966316
new file mode 100644
index 000000000..dfcb28592
--- /dev/null
+++ b/results/classifier/118/KVM/966316
@@ -0,0 +1,54 @@
+x86: 0.953
+KVM: 0.939
+graphic: 0.893
+ppc: 0.876
+semantic: 0.818
+user-level: 0.818
+mistranslation: 0.813
+kernel: 0.789
+device: 0.785
+VMM: 0.777
+performance: 0.762
+architecture: 0.755
+network: 0.673
+files: 0.610
+PID: 0.601
+hypervisor: 0.593
+virtual: 0.592
+socket: 0.591
+vnc: 0.499
+permissions: 0.464
+boot: 0.433
+arm: 0.408
+peripherals: 0.405
+risc-v: 0.396
+debug: 0.396
+i386: 0.383
+TCG: 0.382
+register: 0.360
+assembly: 0.351
+
+Can't load Android VBOX image or even linux test image as well
+
+Can't load Android X86 ICS 4.0 VBOX image.
+It worked with previous version before adding /qemu/hw/pc_sysfw.c file ( tested with version 1.0 ). 
+
+x86_64-softmmu# ./qemu-system-x86_64 ~/kvm-test-image/x86-linux-0.2.img
+qemu: PC system firmware (pflash) must be a multiple of 0x1000
+
+In QEMU website (http://wiki.qemu.org/Testing), there is a test image for linux
+but, new version can't load the image as well because of upper error.
+linux-0.2.img.bz2 (8 MB) 	Small Linux disk image containing a 2.6.20 Linux kernel, X11 and various utilities to test QEMU
+
+I'm getting this same error with qemu v1.1.1 on a RAW formatted disk image of windows XP that used to work.
+
+> qemu -m 1024 -hda xp.img -localtime -net user
+qemu: PC system firmware (pflash) must be a multiple of 0x1000
+
+I've no idea what this error could mean =)
+
+Triaging old bug tickets ... Can you still reproduce this problem with
+the latest version of QEMU?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
author	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:00 +0000
committer	Christian Krinitsin <mail@krinitsin.com>	2025-06-16 16:59:33 +0000
commit	9aba81d8eb048db908c94a3c40c25a5fde0caee6 (patch)
tree	b765e7fb5e9a3c2143c68b0414e0055adb70e785 /results/classifier/118/KVM
parent	b89a938452613061c0f1f23e710281cf5c83cb29 (diff)
download	qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.tar.gz qemu-analysis-9aba81d8eb048db908c94a3c40c25a5fde0caee6.zip