add new results

19 files changed, 3989 insertions, 0 deletions

diff --git a/results/classifier/111/KVM/04472277 b/results/classifier/111/KVM/04472277
new file mode 100644
index 000000000..878322499
--- /dev/null
+++ b/results/classifier/111/KVM/04472277
@@ -0,0 +1,600 @@
+KVM: 0.105
+device: 0.075
+vnc: 0.074
+PID: 0.073
+network: 0.073
+other: 0.071
+permissions: 0.070
+socket: 0.069
+performance: 0.068
+semantic: 0.067
+debug: 0.067
+boot: 0.066
+graphic: 0.063
+files: 0.060
+KVM: 0.359
+debug: 0.236
+files: 0.223
+boot: 0.034
+other: 0.031
+PID: 0.020
+performance: 0.020
+socket: 0.017
+semantic: 0.016
+device: 0.013
+network: 0.011
+graphic: 0.008
+vnc: 0.006
+permissions: 0.005
+
+[BUG][KVM_SET_USER_MEMORY_REGION] KVM_SET_USER_MEMORY_REGION failed
+
+Hi all,
+I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR.
+Is there any one know this?
+The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log
+```
+2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument
+kvm_set_phys_mem: error registering slot: Invalid argument
+2023-03-14 10:09:18.198+0000: shutting down, reason=crashed
+```
+The xml file
+```
+root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml
+<!--
+WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
+OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
+  virsh edit instance-0000000e
+or other application using the libvirt API.
+-->
+<domain type='kvm'>
+  <name>instance-0000000e</name>
+  <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid>
+  <metadata>
+    <nova:instance xmlns:nova="
+http://openstack.org/xmlns/libvirt/nova/1.1
+">
+      <nova:package version="25.1.0"/>
+      <nova:name>provider-instance</nova:name>
+      <nova:creationTime>2023-03-14 10:09:13</nova:creationTime>
+      <nova:flavor name="cirros-os-dpu-test-1">
+        <nova:memory>64</nova:memory>
+        <nova:disk>1</nova:disk>
+        <nova:swap>0</nova:swap>
+        <nova:ephemeral>0</nova:ephemeral>
+        <nova:vcpus>1</nova:vcpus>
+      </nova:flavor>
+      <nova:owner>
+        <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user>
+        <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project>
+      </nova:owner>
+      <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/>
+      <nova:ports>
+        <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340">
+          <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/>
+        </nova:port>
+      </nova:ports>
+    </nova:instance>
+  </metadata>
+  <memory unit='KiB'>65536</memory>
+  <currentMemory unit='KiB'>65536</currentMemory>
+  <vcpu placement='static'>1</vcpu>
+  <sysinfo type='smbios'>
+    <system>
+      <entry name='manufacturer'>OpenStack Foundation</entry>
+      <entry name='product'>OpenStack Nova</entry>
+      <entry name='version'>25.1.0</entry>
+      <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='family'>Virtual Machine</entry>
+    </system>
+  </sysinfo>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type>
+    <boot dev='hd'/>
+    <smbios mode='sysinfo'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmcoreinfo state='on'/>
+  </features>
+  <cpu mode='host-model' check='partial'>
+    <topology sockets='1' dies='1' cores='1' threads='1'/>
+  </cpu>
+  <clock offset='utc'>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='piix3-uhci'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <interface type='hostdev' managed='yes'>
+      <mac address='fa:16:3e:aa:d9:23'/>
+      <source>
+        <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='serial' port='0'/>
+    </console>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
+      <listen type='address' address='0.0.0.0'/>
+    </graphics>
+    <audio id='1' type='none'/>
+    <video>
+      <model type='virtio' heads='1' primary='yes'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <source>
+        <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </hostdev>
+    <memballoon model='virtio'>
+      <stats period='10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/urandom</backend>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </rng>
+  </devices>
+</domain>
+```
+----
+Simon Jones
+
+This is happened in ubuntu22.04.
+QEMU is install by apt like this:
+apt install -y qemu qemu-kvm qemu-system
+and QEMU version is 6.2.0
+----
+Simon Jones
+Simon Jones <
+batmanustc@gmail.com
+> 于2023年3月21日周二 08:40写道：
+Hi all,
+I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR.
+Is there any one know this?
+The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log
+```
+2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument
+kvm_set_phys_mem: error registering slot: Invalid argument
+2023-03-14 10:09:18.198+0000: shutting down, reason=crashed
+```
+The xml file
+```
+root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml
+<!--
+WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
+OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
+  virsh edit instance-0000000e
+or other application using the libvirt API.
+-->
+<domain type='kvm'>
+  <name>instance-0000000e</name>
+  <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid>
+  <metadata>
+    <nova:instance xmlns:nova="
+http://openstack.org/xmlns/libvirt/nova/1.1
+">
+      <nova:package version="25.1.0"/>
+      <nova:name>provider-instance</nova:name>
+      <nova:creationTime>2023-03-14 10:09:13</nova:creationTime>
+      <nova:flavor name="cirros-os-dpu-test-1">
+        <nova:memory>64</nova:memory>
+        <nova:disk>1</nova:disk>
+        <nova:swap>0</nova:swap>
+        <nova:ephemeral>0</nova:ephemeral>
+        <nova:vcpus>1</nova:vcpus>
+      </nova:flavor>
+      <nova:owner>
+        <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user>
+        <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project>
+      </nova:owner>
+      <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/>
+      <nova:ports>
+        <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340">
+          <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/>
+        </nova:port>
+      </nova:ports>
+    </nova:instance>
+  </metadata>
+  <memory unit='KiB'>65536</memory>
+  <currentMemory unit='KiB'>65536</currentMemory>
+  <vcpu placement='static'>1</vcpu>
+  <sysinfo type='smbios'>
+    <system>
+      <entry name='manufacturer'>OpenStack Foundation</entry>
+      <entry name='product'>OpenStack Nova</entry>
+      <entry name='version'>25.1.0</entry>
+      <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='family'>Virtual Machine</entry>
+    </system>
+  </sysinfo>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type>
+    <boot dev='hd'/>
+    <smbios mode='sysinfo'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmcoreinfo state='on'/>
+  </features>
+  <cpu mode='host-model' check='partial'>
+    <topology sockets='1' dies='1' cores='1' threads='1'/>
+  </cpu>
+  <clock offset='utc'>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='piix3-uhci'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <interface type='hostdev' managed='yes'>
+      <mac address='fa:16:3e:aa:d9:23'/>
+      <source>
+        <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='serial' port='0'/>
+    </console>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
+      <listen type='address' address='0.0.0.0'/>
+    </graphics>
+    <audio id='1' type='none'/>
+    <video>
+      <model type='virtio' heads='1' primary='yes'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <source>
+        <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </hostdev>
+    <memballoon model='virtio'>
+      <stats period='10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/urandom</backend>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </rng>
+  </devices>
+</domain>
+```
+----
+Simon Jones
+
+This is full ERROR log
+2023-03-23 08:00:52.362+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt <
+christian.ehrhardt@canonical.com
+> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
+HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-4-instance-0000000e/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=instance-0000000e,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-instance-0000000e/master-key.aes"}' \
+-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \
+-accel kvm \
+-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \
+-m 64 \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,dies=1,cores=1,threads=1 \
+-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \
+-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=33,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-hpet \
+-no-shutdown \
+-boot strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \
+-add-fd set=1,fd=34 \
+-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-device usb-tablet,id=input0,bus=usb.0,port=1 \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-vnc
+0.0.0.0:0
+,audiodev=audio1 \
+-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \
+-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \
+-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
+-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \
+-device vmcoreinfo \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/3 (label charserial0)
+2023-03-23T08:00:53.728550Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument
+kvm_set_phys_mem: error registering slot: Invalid argument
+2023-03-23 08:00:54.201+0000: shutting down, reason=crashed
+2023-03-23 08:54:43.468+0000: starting up libvirt version: 8.0.0, package: 1ubuntu7.4 (Christian Ehrhardt <
+christian.ehrhardt@canonical.com
+> Tue, 22 Nov 2022 15:59:28 +0100), qemu version: 6.2.0Debian 1:6.2+dfsg-2ubuntu6.6, kernel: 5.19.0-35-generic, hostname: c1c2
+LC_ALL=C \
+PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
+HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e \
+XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.local/share \
+XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.cache \
+XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-5-instance-0000000e/.config \
+/usr/bin/qemu-system-x86_64 \
+-name guest=instance-0000000e,debug-threads=on \
+-S \
+-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-5-instance-0000000e/master-key.aes"}' \
+-machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram \
+-accel kvm \
+-cpu Cooperlake,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,sha-ni=on,umip=on,waitpkg=on,gfni=on,vaes=on,vpclmulqdq=on,rdpid=on,movdiri=on,movdir64b=on,fsrm=on,md-clear=on,avx-vnni=on,xsaves=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,hle=off,rtm=off,avx512f=off,avx512dq=off,avx512cd=off,avx512bw=off,avx512vl=off,avx512vnni=off,avx512-bf16=off,taa-no=off \
+-m 64 \
+-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":67108864}' \
+-overcommit mem-lock=off \
+-smp 1,sockets=1,dies=1,cores=1,threads=1 \
+-uuid ff91d2dc-69a1-43ef-abde-c9e4e9a0305b \
+-smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.1.0,serial=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,uuid=ff91d2dc-69a1-43ef-abde-c9e4e9a0305b,family=Virtual Machine' \
+-no-user-config \
+-nodefaults \
+-chardev socket,id=charmonitor,fd=33,server=on,wait=off \
+-mon chardev=charmonitor,id=monitor,mode=control \
+-rtc base=utc,driftfix=slew \
+-global kvm-pit.lost_tick_policy=delay \
+-no-hpet \
+-no-shutdown \
+-boot strict=on \
+-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
+-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/_base/8b58db82a488248e7c5e769599954adaa47a5314","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \
+-blockdev '{"driver":"file","filename":"/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \
+-blockdev '{"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"}' \
+-device virtio-blk-pci,bus=pci.0,addr=0x3,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on \
+-add-fd set=1,fd=34 \
+-chardev pty,id=charserial0,logfile=/dev/fdset/1,logappend=on \
+-device isa-serial,chardev=charserial0,id=serial0 \
+-device usb-tablet,id=input0,bus=usb.0,port=1 \
+-audiodev '{"id":"audio1","driver":"none"}' \
+-vnc
+0.0.0.0:0
+,audiodev=audio1 \
+-device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 \
+-device vfio-pci,host=0000:01:00.5,id=hostdev0,bus=pci.0,addr=0x4 \
+-device vfio-pci,host=0000:01:00.6,id=hostdev1,bus=pci.0,addr=0x5 \
+-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 \
+-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
+-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 \
+-device vmcoreinfo \
+-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
+-msg timestamp=on
+char device redirected to /dev/pts/3 (label charserial0)
+2023-03-23T08:54:44.755039Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument
+kvm_set_phys_mem: error registering slot: Invalid argument
+2023-03-23 08:54:45.230+0000: shutting down, reason=crashed
+----
+Simon Jones
+Simon Jones <
+batmanustc@gmail.com
+> 于2023年3月23日周四 05:49写道：
+This is happened in ubuntu22.04.
+QEMU is install by apt like this:
+apt install -y qemu qemu-kvm qemu-system
+and QEMU version is 6.2.0
+----
+Simon Jones
+Simon Jones <
+batmanustc@gmail.com
+> 于2023年3月21日周二 08:40写道：
+Hi all,
+I start a VM in openstack, and openstack use libvirt to start qemu VM, but now log show this ERROR.
+Is there any one know this?
+The ERROR log from /var/log/libvirt/qemu/instance-0000000e.log
+```
+2023-03-14T10:09:17.674114Z qemu-system-x86_64: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=4, start=0xfffffffffe000000, size=0x2000: Invalid argument
+kvm_set_phys_mem: error registering slot: Invalid argument
+2023-03-14 10:09:18.198+0000: shutting down, reason=crashed
+```
+The xml file
+```
+root@c1c2:~# cat /etc/libvirt/qemu/instance-0000000e.xml
+<!--
+WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
+OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
+  virsh edit instance-0000000e
+or other application using the libvirt API.
+-->
+<domain type='kvm'>
+  <name>instance-0000000e</name>
+  <uuid>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</uuid>
+  <metadata>
+    <nova:instance xmlns:nova="
+http://openstack.org/xmlns/libvirt/nova/1.1
+">
+      <nova:package version="25.1.0"/>
+      <nova:name>provider-instance</nova:name>
+      <nova:creationTime>2023-03-14 10:09:13</nova:creationTime>
+      <nova:flavor name="cirros-os-dpu-test-1">
+        <nova:memory>64</nova:memory>
+        <nova:disk>1</nova:disk>
+        <nova:swap>0</nova:swap>
+        <nova:ephemeral>0</nova:ephemeral>
+        <nova:vcpus>1</nova:vcpus>
+      </nova:flavor>
+      <nova:owner>
+        <nova:user uuid="ff627ad39ed94479b9c5033bc462cf78">admin</nova:user>
+        <nova:project uuid="512866f9994f4ad8916d8539a7cdeec9">admin</nova:project>
+      </nova:owner>
+      <nova:root type="image" uuid="9e58cb69-316a-4093-9f23-c1d1bd8edffe"/>
+      <nova:ports>
+        <nova:port uuid="77c1dc00-af39-4463-bea0-12808f4bc340">
+          <nova:ip type="fixed" address="172.1.1.43" ipVersion="4"/>
+        </nova:port>
+      </nova:ports>
+    </nova:instance>
+  </metadata>
+  <memory unit='KiB'>65536</memory>
+  <currentMemory unit='KiB'>65536</currentMemory>
+  <vcpu placement='static'>1</vcpu>
+  <sysinfo type='smbios'>
+    <system>
+      <entry name='manufacturer'>OpenStack Foundation</entry>
+      <entry name='product'>OpenStack Nova</entry>
+      <entry name='version'>25.1.0</entry>
+      <entry name='serial'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='uuid'>ff91d2dc-69a1-43ef-abde-c9e4e9a0305b</entry>
+      <entry name='family'>Virtual Machine</entry>
+    </system>
+  </sysinfo>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type>
+    <boot dev='hd'/>
+    <smbios mode='sysinfo'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <vmcoreinfo state='on'/>
+  </features>
+  <cpu mode='host-model' check='partial'>
+    <topology sockets='1' dies='1' cores='1' threads='1'/>
+  </cpu>
+  <clock offset='utc'>
+    <timer name='pit' tickpolicy='delay'/>
+    <timer name='rtc' tickpolicy='catchup'/>
+    <timer name='hpet' present='no'/>
+  </clock>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>destroy</on_crash>
+  <devices>
+    <emulator>/usr/bin/qemu-system-x86_64</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='none'/>
+      <source file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/disk'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </disk>
+    <controller type='usb' index='0' model='piix3-uhci'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <controller type='pci' index='0' model='pci-root'/>
+    <interface type='hostdev' managed='yes'>
+      <mac address='fa:16:3e:aa:d9:23'/>
+      <source>
+        <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x5'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
+    </interface>
+    <serial type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='isa-serial' port='0'>
+        <model name='isa-serial'/>
+      </target>
+    </serial>
+    <console type='pty'>
+      <log file='/var/lib/nova/instances/ff91d2dc-69a1-43ef-abde-c9e4e9a0305b/console.log' append='off'/>
+      <target type='serial' port='0'/>
+    </console>
+    <input type='tablet' bus='usb'>
+      <address type='usb' bus='0' port='1'/>
+    </input>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
+      <listen type='address' address='0.0.0.0'/>
+    </graphics>
+    <audio id='1' type='none'/>
+    <video>
+      <model type='virtio' heads='1' primary='yes'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <hostdev mode='subsystem' type='pci' managed='yes'>
+      <source>
+        <address domain='0x0000' bus='0x01' slot='0x00' function='0x6'/>
+      </source>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
+    </hostdev>
+    <memballoon model='virtio'>
+      <stats period='10'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
+    </memballoon>
+    <rng model='virtio'>
+      <backend model='random'>/dev/urandom</backend>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
+    </rng>
+  </devices>
+</domain>
+```
+----
+Simon Jones
+
diff --git a/results/classifier/111/KVM/1063807 b/results/classifier/111/KVM/1063807
new file mode 100644
index 000000000..34d804f5a
--- /dev/null
+++ b/results/classifier/111/KVM/1063807
@@ -0,0 +1,102 @@
+KVM: 0.108
+vnc: 0.094
+permissions: 0.089
+other: 0.079
+device: 0.077
+PID: 0.076
+boot: 0.074
+debug: 0.071
+semantic: 0.062
+files: 0.060
+graphic: 0.056
+network: 0.056
+performance: 0.052
+socket: 0.045
+KVM: 0.797
+boot: 0.093
+debug: 0.048
+PID: 0.013
+performance: 0.009
+files: 0.009
+socket: 0.006
+device: 0.005
+other: 0.005
+network: 0.003
+semantic: 0.003
+graphic: 0.003
+vnc: 0.002
+permissions: 0.002
+
+KVM crashes when booting a PointSec encrypted Windows 7
+
+Hi all,
+
+KVM crashes each time the VM boots after installing PointSec.
+
+Steps to reproduce are:
+1) install win7 64bits
+2) install PointSec FDE (Full Disk Encryption => http://www.checkpoint.com/products/full-disk-encryption/index.html)
+3) regardless any other qemu parameters, one gets a "KVM internal error. Suberror: 1 / emulation failure" error message and a qemu dump like this one:
+
+KVM internal error. Suberror: 1
+emulation failure
+EAX=00000130 EBX=00000000 ECX=00014000 EDX=00050000
+ESI=00000000 EDI=00000000 EBP=00008e3f ESP=0001802d
+EIP=000006d3 EFL=00017087 [--S--PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0048 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
+CS =25a1 00025a10 0000ffff 00009b00 DPL=0 CS16 [-RA]
+SS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
+DS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
+FS =0130 00300000 ffffffff 00c09300 DPL=0 DS [-WA]
+GS =0040 00028050 ffffffff 00c09300 DPL=0 DS [-WA]
+LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
+TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
+GDT= 00028050 00001dd8
+IDT= 00029e40 00000188
+CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=00 8e c0 b8 30 01 8e e0 66 b9 00 00 00 00 66 ba 00 00 00 00 <66> 26 67 8b 9a 00 00 05 00 66 64 67 89 1a 66 83 c2 04 66 41 66 81 f9 00 80 01 00 75 e3 0f
+
+
+My system info:
+root@RJZ-LNX:/home/rjz# cat /proc/cpuinfo | tail -24
+cpu family : 6
+model : 37
+model name : Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz
+stepping : 5
+microcode : 0x2
+cpu MHz : 1199.000
+cache size : 3072 KB
+physical id : 0
+siblings : 4
+core id : 2
+cpu cores : 2
+apicid : 5
+initial apicid : 5
+fpu : yes
+fpu_exception : yes
+cpuid level : 11
+wp : yes
+flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid
+bogomips : 5319.72
+clflush size : 64
+cache_alignment : 64
+address sizes : 36 bits physical, 48 bits virtual
+power management:
+
+
+
+and qemu (Ubuntu distribution) info is:
+
+root@RJZ-LNX:/home/rjz# qemu-system-x86_64 --version
+QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
+
+
+
+Best regards,
+Rolando.
+
+Since this is very likely rather a KVM kernel bug than a QEMU userspace bug, could you please report it to the KVM mailing list / bug tracker instead (see http://www.linux-kvm.org/page/Bugs)? Thanks!
+
diff --git a/results/classifier/111/KVM/1073952 b/results/classifier/111/KVM/1073952
new file mode 100644
index 000000000..0faaa6c21
--- /dev/null
+++ b/results/classifier/111/KVM/1073952
@@ -0,0 +1,63 @@
+KVM: 0.163
+device: 0.149
+semantic: 0.108
+other: 0.108
+files: 0.091
+vnc: 0.071
+performance: 0.050
+boot: 0.049
+graphic: 0.041
+network: 0.038
+socket: 0.036
+PID: 0.035
+debug: 0.035
+permissions: 0.026
+KVM: 0.555
+debug: 0.105
+network: 0.096
+socket: 0.036
+performance: 0.034
+other: 0.032
+files: 0.032
+PID: 0.029
+device: 0.029
+semantic: 0.015
+boot: 0.012
+vnc: 0.011
+graphic: 0.008
+permissions: 0.008
+
+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/111/KVM/1175089 b/results/classifier/111/KVM/1175089
new file mode 100644
index 000000000..a504a149d
--- /dev/null
+++ b/results/classifier/111/KVM/1175089
@@ -0,0 +1,94 @@
+KVM: 0.088
+other: 0.088
+vnc: 0.078
+permissions: 0.076
+device: 0.075
+files: 0.071
+socket: 0.067
+boot: 0.067
+graphic: 0.066
+network: 0.066
+PID: 0.066
+performance: 0.065
+debug: 0.065
+semantic: 0.062
+KVM: 0.725
+debug: 0.140
+boot: 0.025
+files: 0.019
+PID: 0.017
+device: 0.012
+semantic: 0.011
+other: 0.010
+socket: 0.010
+performance: 0.009
+graphic: 0.007
+network: 0.006
+vnc: 0.004
+permissions: 0.004
+
+Crash why dragon fly 3.4.1
+
+Hello, all is here (kernel 3.8, qemu 1.2.2-r3):
+/usr/bin/qemu-system-x86_64 -k fr -alt-grab -m 2048 -vga vmware -net nic,vlan=0,model=virtio -net user -rtc base=localtime -smp 4,cores=4,sockets=1 -boot once=d -cdrom dfly-x86_64-gui-3.4.1_REL.iso 
+KVM internal error. Suberror: 1
+emulation failure
+EAX=00000010 EBX=00009338 ECX=00000000 EDX=00000000
+ESI=000017fc EDI=000017c8 EBP=000364a0 ESP=000017b8
+EIP=00009318 EFL=00003002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 00000000 ffffffff 00c09300
+CS =0018 00000000 0000ffff 00009b00
+SS =0010 00000000 ffffffff 00c09300
+DS =0010 00000000 ffffffff 00c09300
+FS =0033 0000a000 ffffffff 00c0f300
+GS =0033 0000a000 ffffffff 00c0f300
+LDT=0000 00000000 0000ffff 00008200
+TR =0038 00005f98 00002067 00008b00
+GDT=     00009590 0000003f
+IDT=     00005e00 00000197
+CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=00 a3 ea 5d 00 00 66 ea 10 93 18 00 0f 20 c0 fe c8 0f 22 c0 <ea> 1d 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea
+
+Same code for FreeBSD on older devices under openstack/qemu:
+LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-00000968 -S -machine pc-i440fx-1.5,accel=kvm,usb=off -cpu host -m 2096 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 387ce256-de98-4ae9-89f4-a4c26e970bf1 -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2013.2.4,serial=4c4c4544-0034-5210-8058-b4c04f5a344a,uuid=387ce256-de98-4ae9-89f4-a4c26e970bf1 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000968.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/nova/instances/387ce256-de98-4ae9-89f4-a4c26e970bf1/disk,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:0e:59:74,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/387ce256-de98-4ae9-89f4-a4c26e970bf1/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 0.0.0.0:4 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
+
+Domain id=41 is tainted: host-cpu
+W: kvm binary is deprecated, please use qemu-system-x86_64 instead
+Warning: option deprecated, use lost_tick_policy property of kvm-pit instead.
+char device redirected to /dev/pts/5 (label charserial1)
+KVM internal error. Suberror: 1
+emulation failure
+EAX=00000010 EBX=00009336 ECX=00000000 EDX=00000000
+ESI=000017fc EDI=000017c8 EBP=0003b500 ESP=000017b8
+EIP=00009316 EFL=00003002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
+ES =0010 00000000 ffffffff 00c09300
+CS =0018 00000000 0000ffff 00009b00
+SS =0010 00000000 ffffffff 00c09300
+DS =0010 00000000 ffffffff 00c09300
+FS =0033 0000a000 ffffffff 00c0f300
+GS =0033 0000a000 ffffffff 00c0f300
+LDT=0000 00000000 0000ffff 00008200
+TR =0038 00005f98 00002067 00008b00
+GDT=     00009590 0000003f
+IDT=     00005e00 00000197
+CR0=00000010 CR2=00000000 CR3=00000000 CR4=00000000
+DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
+DR6=00000000ffff0ff0 DR7=0000000000000400
+EFER=0000000000000000
+Code=00 a3 ea 5d 00 00 66 ea 0e 93 18 00 0f 20 c0 fe c8 0f 22 c0 <ea> 1b 93 00 00 31 c0 8e d8 8e d0 0f 01 1e dc 95 66 07 66 1f 66 0f a1 66 0f a9 66 61 bc ea
+qemu: terminating on signal 15 from pid 12541
+2015-01-29 14:11:08.678+0000: shutting down
+
+PowerEdge R210
+qemu: 1.5.0+dfsg-3ubuntu5.4~cloud0
+cpu flags: flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept vpid
+
+3.8.0-44-generic x86_64
+
+Triaging 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/111/KVM/1187529 b/results/classifier/111/KVM/1187529
new file mode 100644
index 000000000..dd8bb99a1
--- /dev/null
+++ b/results/classifier/111/KVM/1187529
@@ -0,0 +1,46 @@
+KVM: 0.219
+device: 0.201
+vnc: 0.110
+semantic: 0.083
+other: 0.073
+graphic: 0.057
+boot: 0.046
+files: 0.041
+performance: 0.038
+PID: 0.038
+network: 0.028
+socket: 0.027
+permissions: 0.022
+debug: 0.018
+KVM: 0.490
+debug: 0.227
+PID: 0.058
+device: 0.040
+other: 0.036
+vnc: 0.035
+socket: 0.022
+files: 0.020
+performance: 0.019
+network: 0.016
+semantic: 0.013
+boot: 0.012
+permissions: 0.006
+graphic: 0.006
+
+Devices on PCI bridge stop working when live-migrated
+
+qemu version: 1.4.50 (0ca5aa4f4c4a8bcc73988dd52a536241d35e5223)
+host: x86_64, Linux 3.6.10 (Fedora 17)
+client: x86_64 Centos 6.3 (doesn't matter, really)
+
+If a device, e.g. an lsi53c895a, is on a pci-bridge, after migration, the device stops working (e.g., commands like "poweroff"
+get an Input/Output error. Fails under either xen or kvm. If "top" was running, some cpus go to ~100% wait.
+
+Sample KVM invocation line:
+qemu-system-x86_64 -machine type=pc,accel=kvm -m 4096 -device pci-bridgemsi=on,chassis_nr=1,id=pciBridge1.0,addr=0x11.0 -device lsi53c895a,id=sas,bus=pciBridge1.0,addr=0x1.0x0 -drive if=none,id=disk0,file=/path/to/disk/image -device scsi-disk,bus=sas.0,scsi-id=0,drive=disk0 -vnc 127.0.0.1:0,to=99 -serial pty -boot order=cda -smp 4,maxcpus=4 -monitor vc
+
+Triaging 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/111/KVM/1224444 b/results/classifier/111/KVM/1224444
new file mode 100644
index 000000000..fce9b5a03
--- /dev/null
+++ b/results/classifier/111/KVM/1224444
@@ -0,0 +1,673 @@
+KVM: 0.129
+vnc: 0.101
+boot: 0.076
+network: 0.074
+debug: 0.073
+PID: 0.071
+socket: 0.070
+other: 0.069
+device: 0.067
+permissions: 0.065
+semantic: 0.064
+performance: 0.055
+files: 0.046
+graphic: 0.039
+KVM: 0.359
+debug: 0.215
+device: 0.092
+boot: 0.085
+socket: 0.061
+semantic: 0.034
+PID: 0.031
+files: 0.030
+other: 0.029
+performance: 0.026
+network: 0.012
+permissions: 0.011
+graphic: 0.009
+vnc: 0.005
+
+virtio-serial loses writes when used over virtio-mmio
+
+virtio-serial appears to lose writes, but only when used on top of virtio-mmio.  The scenario is this:
+
+/home/rjones/d/qemu/arm-softmmu/qemu-system-arm \
+    -global virtio-blk-device.scsi=off \
+    -nodefconfig \
+    -nodefaults \
+    -nographic \
+    -M vexpress-a15 \
+    -machine accel=kvm:tcg \
+    -m 500 \
+    -no-reboot \
+    -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1001/kernel.27944 \
+    -dtb /home/rjones/d/libguestfs/tmp/.guestfs-1001/dtb.27944 \
+    -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1001/initrd.27944 \
+    -device virtio-scsi-device,id=scsi \
+    -drive file=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \
+    -device scsi-hd,drive=hd0 \
+    -drive file=/home/rjones/d/libguestfs/tmp/.guestfs-1001/root.27944,snapshot=on,id=appliance,cache=unsafe,if=none \
+    -device scsi-hd,drive=appliance \
+    -device virtio-serial-device \
+    -serial stdio \
+    -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \
+    -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \
+    -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=600 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color'
+
+After the guest starts up, a daemon writes 4 bytes to a virtio-serial socket.  The host side reads these 4 bytes correctly and writes a 64 byte message.  The guest never sees this message.
+
+I enabled virtio-mmio debugging, and this is what is printed (## = my comment):
+
+## guest opens the socket:
+trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
+virtio_mmio: virtio_mmio_write offset 0x50 value 0x3
+opened the socket, sock = 3
+udevadm settle
+## guest writes 4 bytes to the socket:
+virtio_mmio: virtio_mmio_write offset 0x50 value 0x5
+virtio_mmio: virtio_mmio setting IRQ 1
+virtio_mmio: virtio_mmio_read offset 0x60
+virtio_mmio: virtio_mmio_write offset 0x64 value 0x1
+virtio_mmio: virtio_mmio setting IRQ 0
+sent magic GUESTFS_LAUNCH_FLAG
+## host reads 4 bytes successfully:
+main_loop libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
+libguestfs: [14605ms] appliance is up
+Guest launched OK.
+## host writes 64 bytes to socket:
+libguestfs: writing the data to the socket (size = 64)
+waiting for next request
+libguestfs: data written OK
+## hangs here forever with guest in read() call never receiving any data
+
+I am using qemu from git today (2d1fe1873a984).
+
+strace -f of qemu when it fails.
+
+Notes:
+
+ - fd = 6 is the Unix domain socket connected to virtio-serial
+ - only one 4 byte write occurs to this socket (expected guest -> host communication)
+ - the socket isn't read at all (even though the library on the other side has written)
+ - the socket is never added to any poll/ppoll syscall, so it's no wonder that qemu never sees any data on the socket
+
+
+Recall this bug only happens intermittently.  This is an strace -f of qemu when it happens to work.
+
+Notes:
+
+ - fd = 6 is the Unix domain socket
+ - there are an expected number of recvmsg & writes, all with the correct sizes
+ - this time qemu adds the socket to ppoll
+
+I can reproduce this bug on a second ARM machine which doesn't have KVM (ie. using TCG).  Note it's still linked to virtio-mmio.
+
+On 09/12/13 14:04, Richard Jones wrote:
+
+> +     -chardev socket,path=/home/rjones/d/libguestfs/tmp/libguestfsLa9dE2/guestfsd.sock,id=channel0 \
+
+Is this a socket that libguestfs pre-creates on the host-side?
+
+> the socket is never added to any poll/ppoll syscall, so it's no
+> wonder that qemu never sees any data on the socket
+
+
+This should be happening:
+
+qemu_chr_open_socket() [qemu-char.c]
+  unix_connect_opts() [util/qemu-sockets.c]
+    qemu_socket()
+    connect()
+  qemu_set_nonblock() [util/oslib-posix.c]
+  qemu_chr_open_socket_fd()
+    socket_set_nodelay() [util/osdep.c]
+    io_channel_from_socket()
+      g_io_channel_unix_new()
+    tcp_chr_connect()
+      io_add_watch_poll()
+        g_source_new()
+        g_source_attach()
+        g_source_unref()
+      qemu_chr_be_generic_open()
+
+io_add_watch_poll() should make sure the fd is polled starting with the
+next main loop iteration.
+
+Interestingly, even in the "successful" case, there's a slew of ppoll()
+calls between connect() returning 6, and the first ppoll() that actually
+covers fd=6.
+
+Laszlo
+
+
+> Is this a socket that libguestfs pre-creates on the host-side?
+
+Yes it is:
+https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c#L208
+
+You mention a scenario that might cause this.  But that appears to be when the socket is opened.  Note that the guest did send 4 bytes successfully (received OK at the host).  The lost write occurs when the host next tries to send a message back to the guest.
+
+On 09/16/13 16:39, Richard Jones wrote:
+>> Is this a socket that libguestfs pre-creates on the host-side?
+> 
+> Yes it is:
+> https://github.com/libguestfs/libguestfs/blob/master/src/launch-direct.c#L208
+> 
+> You mention a scenario that might cause this.  But that appears to be
+> when the socket is opened.  Note that the guest did send 4 bytes
+> successfully (received OK at the host).  The lost write occurs when the
+> host next tries to send a message back to the guest.
+
+Which is the first time ever that a GLib event loop context messed up
+only for reading would be exposed.
+
+In other words, if the action
+
+  register fd 6 for reading in the GLib main loop context
+
+fails, that wouldn't prevent qemu from *writing* to the UNIX domain socket.
+
+In both traces, the IO-thread (thread-id 8488 in the successful case,
+and thread-id 7586 in the failing case) is the one opening / registering
+etc. fd 6. The IO-thread is also the one calling ppoll().
+
+However, all write(6, ...) syscalls are issued by one of the VCPU
+threads (thread-id 8490 in the successful case, and thread-id 7588 in
+the failing case).
+
+Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM)
+executes guest code that sends data to the host via virtio, KVM kicks
+the "host notifier" eventfd.
+
+Once this "host notifier" eventfd is kicked, the IO thread should do:
+
+  virtio_queue_host_notifier_read()
+    virtio_queue_notify_vq()
+      vq->handle_output()
+        handle_output() [hw/char/virtio-serial-bus.c]
+          do_flush_queued_data()
+            vsc->have_data()
+              flush_buf() [hw/char/virtio-console.c]
+                qemu_chr_fe_write()
+                  ... goes to the unix domain socket ...
+
+When virtio-mmio is used though, the same seems to happen in VCPU thread:
+
+  virtio_mmio_write()
+    virtio_queue_notify()
+      virtio_queue_notify_vq()
+        ...same as above...
+
+
+
+A long shot:
+
+(a) With virtio-pci:
+
+(a1) guest writes to virtio-serial port,
+(a2) KVM sets the host notifier eventfd "pending",
+(a3) the IO thread sees that in the main loop / ppoll(), and copies the
+data to the UNIX domain socket (the backend),
+(a4) host-side libguestfs reads the data and responds,
+(a5) the IO-thread reads the data from the UNIX domain socket,
+(a6) the IO-thread pushes the data to the guest.
+
+(b) with virtio-mmio:
+
+(b1) guest writes to virtio-serial port,
+(b2) the VCPU thread in qemu reads the data (virtio-mmio) and copies it
+to the UNIX domain socket,
+(b3) host-side libguestfs reads the data and responds,
+(b4) the IO-thread is not (yet?) ready to read the data from the UNIX
+domain socket.
+
+I can't quite pin it down, but I think that in the virtio-pci case, the
+fact that everything runs through the IO-thread automatically serializes
+the connection to the UNIX domain socket (and its addition to the GLib
+main loop context) with the message from the guest. Due to the KVM
+eventfd (the "host notifier") everything goes through the same ppoll().
+Maybe it doesn't enforce any theoretical serialization, it might just
+add a sufficiently long delay that there's never a problem in practice.
+
+Whereas in the virtio-mmio case, the initial write to the UNIX domain
+socket, and the response from host-side libguestfs, runs unfettered. I
+imagine something like:
+
+- (IO thread)       connect to socket
+- (IO thread)       add fd to main loop context
+- (guest)           write to virtio-serial port
+- (VCPU thread)     copy data to UNIX domain socket
+- (host libguestfs) read req, write resp to UNIX domain socket
+- (IO thread)       "I should probably check readiness on that socket
+                    sometime"
+
+I don't know why the IO-thread doesn't get there *eventually*.
+
+What happens if you add a five second delay to libguestfs, before
+writing the response?
+
+Laszlo
+
+
+
+On 16 September 2013 17:13, Laszlo Ersek <email address hidden> wrote:
+> Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM)
+> executes guest code that sends data to the host via virtio, KVM kicks
+> the "host notifier" eventfd.
+
+What happens in the virtio-pci without eventfd case?
+(eg virtio-pci on a non-x86 host)
+
+Also, IIRC Alex said they'd had an annoying "data gets lost"
+issue with the s390 virtio transports too...
+
+-- PMM
+
+
+> What happens if you add a five second delay to libguestfs,
+> before writing the response?
+
+No change.  Still hangs in the same place.
+
+On 09/17/13 10:09, Peter Maydell wrote:
+> On 16 September 2013 17:13, Laszlo Ersek <email address hidden> wrote:
+>> Hmmmm. Normally (as in, virtio-pci), when a VCPU thread (running KVM)
+>> executes guest code that sends data to the host via virtio, KVM kicks
+>> the "host notifier" eventfd.
+> 
+> What happens in the virtio-pci without eventfd case?
+> (eg virtio-pci on a non-x86 host)
+
+I'm confused. I think Anthony or Michael could answer better.
+
+There's at least three cases here I guess (KVM + eventfd, KVM without
+eventfd (enforceable eg. with the "ioeventfd" property for virtio
+devices), and TCG). We're probably talking about the third case.
+
+I think we end up in
+
+  virtio_pci_config_ops.write == virtio_pci_config_write
+    virtio_ioport_write()
+      virtio_queue_notify()
+        ... the "usual" stuff ...
+
+As far as I know TCG supports exactly one VCPU thread but that's still
+separate from the IO-thread. In that case the above could trigger the
+problem similarly to virtio-mmio I guess...
+
+I think we should debug into GLib, independently of virtio. What annoys
+me mostly is the huge number of ppoll()s in Rich's trace between
+connecting to the UNIX domain socket and actually checking it for
+read-readiness. The fd in question should show up in the first ppoll()
+after connect().
+
+My email might not make any sense. Sorry.
+Laszlo
+
+
+> There's at least three cases here I guess (KVM + eventfd, KVM without
+> eventfd (enforceable eg. with the "ioeventfd" property for virtio
+> devices), and TCG). We're probably talking about the third case.
+
+To clarify on this point: I have reproduced this bug on two different ARM
+machines, one using KVM and one using TCG.
+
+In both cases they are ./configure'd without any special ioeventfd-related
+options, which appears to mean CONFIG_EVENTFD=y (in both cases).
+
+In both cases I'm using a single vCPU.
+
+On 09/17/13 11:51, Richard Jones wrote:
+>> There's at least three cases here I guess (KVM + eventfd, KVM without
+>> eventfd (enforceable eg. with the "ioeventfd" property for virtio
+>> devices), and TCG). We're probably talking about the third case.
+> 
+> To clarify on this point: I have reproduced this bug on two different ARM
+> machines, one using KVM and one using TCG.
+> 
+> In both cases they are ./configure'd without any special ioeventfd-related
+> options, which appears to mean CONFIG_EVENTFD=y (in both cases).
+> 
+> In both cases I'm using a single vCPU.
+> 
+
+I think I have a theory now; it's quite convoluted.
+
+The problem is a deadlock in ppoll() that is *masked* by unrelated file
+descriptor traffic in all of the apparently working cases.
+
+I wrote some ad-hoc debug patches, and this is the log leading up to the
+hang:
+
+  io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0
+  qemu_poll_ns: timeout=4281013151888
+  poll entry #0 fd 3
+  poll entry #1 fd 5
+  poll entry #2 fd 0
+  poll entry #3 fd 11
+  poll entry #4 fd 4
+  trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
+  opened the socket, sock = 3
+  udevadm settle
+  libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
+  libguestfs: [21734ms] appliance is up
+  Guest launched OK.
+  libguestfs: writing the data to the socket (size = 64)
+  sent magic GUESTFS_LAUNCH_FLAG
+  main_loop waiting for next request
+  libguestfs: data written OK
+  <HANG>
+
+Setup call tree for the backend (ie. the UNIX domain socket):
+
+   1  qemu_chr_open_socket() [qemu-char.c]
+   2    unix_connect_opts() [util/qemu-sockets.c]
+   3      qemu_socket()
+   4      connect()
+   5    qemu_chr_open_socket_fd() [qemu-char.c]
+   6      io_channel_from_socket()
+   7        g_io_channel_unix_new()
+   8      tcp_chr_connect()
+   9        io_add_watch_poll()
+  10          g_source_new()
+  11          g_source_attach()
+
+This part connects to libguestfs's UNIX domain socket (the new socket
+file descriptor, returned on line 3, is fd 6), and it registers a few
+callbacks. Notably, the above doesn't try to add fd 6 to the set of
+polled file descriptors.
+
+
+Then, the setup call tree for the frontend (the virtio-serial port) is
+as follows:
+
+  12  virtconsole_initfn() [hw/char/virtio-console.c]
+  13    qemu_chr_add_handlers() [qemu-char.c]
+
+This reaches into the chardev (ie. the backend referenced by the
+frontend, label "channel0"), and sets further callbacks.
+
+
+The following seems to lead up to the hang:
+
+  14 os_host_main_loop_wait() [main-loop.c]
+  15   glib_pollfds_fill()
+  16     g_main_context_prepare()
+  17       io_watch_poll_prepare() [qemu-char.c]
+  18         chr_can_read() [hw/char/virtio-console.c]
+  19           virtio_serial_guest_ready() [hw/char/virtio-serial-bus.c]
+  20
+  21             if (use_multiport(port->vser) && !port->guest_connected) {
+  22                 return 0;
+  23             }
+  24
+  25             virtqueue_get_avail_bytes()
+  26         g_io_create_watch() // conditionally
+  27   qemu_poll_ns() [qemu-timer.c]
+  28     ppoll()
+
+Line 15: glib_pollfds_fill() prepares the array of file descriptors for
+polling. As first step,
+
+Line 16: it calls g_main_context_prepare(). This GLib function runs the
+"prepare" callbacks for the GSource's in the main context.
+
+The GSource for fd 6 has been allocated on line 10 above, and its
+"prepare" callback has been set to io_watch_poll_prepare() there. It is
+called on line 17.
+
+Line 17: io_watch_poll_prepare() is a crucial function. It decides
+whether fd 6 (the backend fd) will be added to the set of pollfds or
+not.
+
+It checks whether the frontend has become writeable (ie. it must have
+been unwriteable up to now, but it must be writeable now). If so, a
+(persistent) watch is created (on line 26), which is the action that
+includes fd 6 in the set of pollfds after all. If there is no change in
+the status of the frontend, the watch is not changed.
+
+io_watch_poll_prepare() checks for the writeability of the frontend (ie.
+virtio serial port) by the "fd_can_read" callback. This has been set to
+chr_can_read() on line 13, inside virtconsole_initfn().
+
+So, the frontend-writeability check happens in chr_can_read(), which
+simply calls:
+
+Line 19: virtio_serial_guest_ready(). This function *normally* checks
+for the available room in the virtqueue (the guest receives serial port
+data from the host by submitting "receive requests" that must be filled
+in by the host); see line 25.
+
+However, virtio_serial_guest_ready() first verifies whether the guest
+has connected to the virtio-serial port at all. If not, then the
+function will report the frontend unwriteable (lines 21-23).
+
+
+Now, right before the hang, the guest hasn't yet connected to the
+virtio-serial port. Therefore line 22 fires (= virtio-serial port is
+unwriteable), which in turn results in *no* watch being created for the
+backend. Consequently, the UNIX domain socket (fd 6) is not added to the
+set of pollfds:
+
+  io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0
+  qemu_poll_ns: timeout=4281013151888
+  poll entry #0 fd 3
+  poll entry #1 fd 5
+  poll entry #2 fd 0
+  poll entry #3 fd 11
+  poll entry #4 fd 4
+
+At this point the IO thread is blocked in ppoll().
+
+Then, the guest connects to the serial port, and sends data.
+
+  trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
+  opened the socket, sock = 3
+  udevadm settle
+
+As discussed before, this guest-to-host transfer is handled by the VCPU
+thread, and the data is written to fd 6 (the UNIX domain socket). The
+host-side libguestfs component reads it, and answers.
+
+  libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
+  libguestfs: [21734ms] appliance is up
+  Guest launched OK.
+  libguestfs: writing the data to the socket (size = 64)
+  sent magic GUESTFS_LAUNCH_FLAG
+  main_loop waiting for next request  # note, this is a libguestfs message!
+  libguestfs: data written OK
+  <HANG>
+
+Unfortunately, ppoll() is not watching out for fd 6 at all, hence this
+deadlocks.
+
+
+What about the successful cases though? A good proportion of the
+attempts succeed.
+
+This is explained by the fact that *other* file descriptors can break
+out the IO-thread from ppoll().
+
+- The most common example is KVM *with* eventfd support. The KVM eventfd
+  (the host notifier) is part of the pollfd set, and whenever the guest
+  sends some data, KVM kicks the eventfd, and ppoll() returns. This
+  masks the problem universally.
+
+- In the other two cases, we either have KVM *without* eventfd support,
+  or TCG. Rich reproduced the hang under both, and he's seen successful
+  (actually: masked deadlock) cases as well, on both.
+
+  In these setups the file descriptor traffic that masks the problem is
+  not from a KVM eventfd, hence the wakeup is quite random. There is
+  sometimes a perceivable pause between ppoll() going to sleep and
+  waking up. At other times there's no other fd traffic, and the
+  deadlock persists.
+
+In my testing on Rich's ARM box, the unrelated fd that breaks out the IO-thread
+from ppoll() is the eventfd that belongs to the AIO thread pool. It is fd 11,
+and it is allocated in:
+
+  0x00512d3c in event_notifier_init (e=0x1f4ad80, active=0) at util/event_notifier-posix.c:34
+  34          ret = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
+  (gdb) n
+  39          if (ret >= 0) {
+  (gdb) print ret
+  $2 = 11
+  (gdb) where
+  #0  event_notifier_init (e=0x1f4ad80, active=0) at util/event_notifier-posix.c:39
+  #1  0x00300b4c in thread_pool_init_one (pool=0x1f4ad80, ctx=0x1f39e18) at thread-pool.c:295
+  #2  0x00300c6c in thread_pool_new (ctx=0x1f39e18) at thread-pool.c:313
+  #3  0x0001686c in aio_get_thread_pool (ctx=0x1f39e18) at async.c:238
+  #4  0x0006f9d8 in paio_submit (bs=0x1f4a020, fd=10, sector_num=0, qiov=0xbe88c164, nb_sectors=4,
+      cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4, type=1) at block/raw-posix.c:799
+  #5  0x0006fb84 in raw_aio_submit (bs=0x1f4a020, sector_num=0, qiov=0xbe88c164, nb_sectors=4,
+      cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4, type=1) at block/raw-posix.c:828
+  #6  0x0006fc28 in raw_aio_readv (bs=0x1f4a020, sector_num=0, qiov=0xbe88c164, nb_sectors=4,
+      cb=0x389d8 <bdrv_co_io_em_complete>, opaque=0xb6505ec4) at block/raw-posix.c:836
+  #7  0x00038b2c in bdrv_co_io_em (bs=0x1f4a020, sector_num=0, nb_sectors=4, iov=0xbe88c164, is_write=false)
+      at block.c:3957
+  #8  0x00038bf0 in bdrv_co_readv_em (bs=0x1f4a020, sector_num=0, nb_sectors=4, iov=0xbe88c164) at block.c:3974
+  #9  0x000349d4 in bdrv_co_do_readv (bs=0x1f4a020, sector_num=0, nb_sectors=4, qiov=0xbe88c164, flags=(unknown: 0))
+      at block.c:2619
+  #10 0x00033804 in bdrv_rw_co_entry (opaque=0xbe88c0e8) at block.c:2236
+  #11 0x0009ba54 in coroutine_trampoline (i0=32811528, i1=0) at coroutine-ucontext.c:118
+  #12 0x492fd160 in setcontext () from /usr/lib/libc.so.6
+  #13 0x492fd160 in setcontext () from /usr/lib/libc.so.6
+  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
+
+And the transitory hang looks like:
+
+  io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:0
+  qemu_poll_ns: timeout=4281193192443
+  poll entry #0 fd 3
+  poll entry #1 fd 5
+  poll entry #2 fd 0
+  poll entry #3 fd 11
+  poll entry #4 fd 4
+
+Again, at this point IO thread is blocked in ppoll(),
+
+  trying to open virtio-serial channel   '/dev/virtio-ports/org.libguestfs.channel.0'
+  opened the socket, sock = 3
+  udevadm settle
+
+the guest transferred out some data,
+
+  libguestfs: recv_from_daemon: received GUESTFS_LAUNCH_FLAG
+  libguestfs: [20921ms] appliance is up
+  Guest launched OK.
+  libguestfs: writing the data to the socket (size = 64)
+  sent magic GUESTFS_LAUNCH_FLAG
+  main_loop waiting for next request
+  libguestfs: data written OK
+
+and the host side libguestfs has responded. The IO-thread is  blocked in
+ppoll(), guaranteed, and it doesn't notice readiness of fd 6 for
+reading.
+
+However, the (completely unrelated) AIO thread-pool eventfd is kicked at
+that point, and poll returns:
+
+  ppoll(): 1, errno=Success
+  poll entry #0 fd 3 events 25 revents 0
+  poll entry #1 fd 5 events 1 revents 0
+  poll entry #2 fd 0 events 1 revents 0
+  poll entry #3 fd 11 events 1 revents 1
+  poll entry #4 fd 4 events 1 revents 0
+
+Which in turn allows the IO-thread to run os_host_main_loop_wait()
+again, and *now* we're seeing the activation of fd 6 (its frontend, the
+virtio-serial port has been connected by the guest in the meantime and
+is now writeable):
+
+  io_watch_poll_prepare: chardev:channel0 was_active:0 now_active:1
+  qemu_poll_ns: timeout=0
+  poll entry #0 fd 3
+  poll entry #1 fd 5
+  poll entry #2 fd 0
+  poll entry #3 fd 11
+  poll entry #4 fd 4
+  poll entry #5 fd 6
+
+And stuff works as expected from here on.
+
+
+The VCPU thread needs to interrupt the IO-thread's ppoll() call
+explicitly.
+
+Basically, when the chardev's attached frontend (in this case, the
+virtio serial port) experiences a change that would cause it to report
+writeability in io_watch_poll_prepare() -- lines 17-18 --, it must
+interrupt ppoll().
+
+The following call tree seems relevant, but I'm not sure if it would be
+appropriate. When the guest message
+
+  trying to open virtio-serial channel '/dev/virtio-ports/org.libguestfs.channel.0'
+
+is printed, the following call chain is executed in the VCPU thread:
+
+  #0  qemu_chr_fe_set_open (chr=0xf22190, fe_open=1) at qemu-char.c:3404
+  #1  0x001079dc in set_guest_connected (port=0x1134f00, guest_connected=1) at hw/char/virtio-console.c:83
+  #2  0x003cfd94 in handle_control_message (vser=0x1124360, buf=0xb50005f8, len=8)
+      at /home/rjones/d/qemu/hw/char/virtio-serial-bus.c:379
+  #3  0x003d0020 in control_out (vdev=0x1124360, vq=0x11246b0) at /home/rjones/d/qemu/hw/char/virtio-serial-bus.c:416
+  #4  0x0044afe4 in virtio_queue_notify_vq (vq=0x11246b0) at /home/rjones/d/qemu/hw/virtio/virtio.c:720
+  #5  0x0044b054 in virtio_queue_notify (vdev=0x1124360, n=3) at /home/rjones/d/qemu/hw/virtio/virtio.c:726
+  #6  0x00271f30 in virtio_mmio_write (opaque=0x11278c8, offset=80, value=3, size=4) at hw/virtio/virtio-mmio.c:264
+  #7  0x00456aac in memory_region_write_accessor (mr=0x1128ba8, addr=80, value=0xb5972b08, size=4, shift=0,
+      mask=4294967295) at /home/rjones/d/qemu/memory.c:440
+  #8  0x00456c90 in access_with_adjusted_size (addr=80, value=0xb5972b08, size=4, access_size_min=1,
+      access_size_max=4, access=0x4569d0 <memory_region_write_accessor>, mr=0x1128ba8)
+      at /home/rjones/d/qemu/memory.c:477
+  #9  0x0045955c in memory_region_dispatch_write (mr=0x1128ba8, addr=80, data=3, size=4)
+      at /home/rjones/d/qemu/memory.c:984
+  #10 0x0045cee0 in io_mem_write (mr=0x1128ba8, addr=80, val=3, size=4) at /home/rjones/d/qemu/memory.c:1748
+  #11 0x0035d8dc in address_space_rw (as=0xa982f8 <address_space_memory>, addr=471008336, buf=0xb6f3d028 "\003",
+      len=4, is_write=true) at /home/rjones/d/qemu/exec.c:1954
+  #12 0x0035ddf0 in cpu_physical_memory_rw (addr=471008336, buf=0xb6f3d028 "\003", len=4, is_write=1)
+      at /home/rjones/d/qemu/exec.c:2033
+  #13 0x00453000 in kvm_cpu_exec (cpu=0x1097020) at /home/rjones/d/qemu/kvm-all.c:1665
+  #14 0x0034ca94 in qemu_kvm_cpu_thread_fn (arg=0x1097020) at /home/rjones/d/qemu/cpus.c:802
+  #15 0x494c6bc0 in start_thread () from /usr/lib/libpthread.so.0
+
+Unfortunately, the leaf (ie. qemu_chr_fe_set_open()) doesn't do anything
+here; the only chardev that sets the "chr_set_fe_open" callback is the
+spicevmc backend.
+
+I think the "socket" chardev might want to implement "chr_set_fe_open",
+kicking a (new) global eventfd, sending some signal to the IO-thread, or
+interrupting ppoll() in some other way. A new global eventfd just for
+this purpose seems quite the kludge, but it shouldn't be hard to
+implement. It needs no handler at all.
+
+Thanks
+Laszlo
+
+
+
+FWIW I am able to reproduce this quite easily on aarch64 too.
+
+My test program is:
+https://github.com/libguestfs/libguestfs/blob/master/tests/qemu/qemu-speed-test.c
+
+and you use it like this:
+qemu-speed-test --virtio-serial-upload
+
+(You can also test virtio-serial downloads and a few other things, but those don't appear to deadlock)
+
+Slowing down the upload, even just by enabling debugging, is sufficient to make the problem go away most of the time.
+
+I am testing with qemu from git (f45c56e0166e86d3b309ae72f4cb8e3d0949c7ef).
+
+I don't know how to close bugs in launchpad, but this one can be closed
+for a couple of reasons:
+
+(1) I benchmarked virtio-mmio the other day using qemu-speed-test on aarch64
+and I did not encounter the bug.
+
+(2) aarch64 has supported virtio-pci for a while, for virtio-mmio is effectively
+obsolete.
+
+Fixed upstream, see previous comment.
+
diff --git a/results/classifier/111/KVM/1307281 b/results/classifier/111/KVM/1307281
new file mode 100644
index 000000000..0cc916e8b
--- /dev/null
+++ b/results/classifier/111/KVM/1307281
@@ -0,0 +1,44 @@
+KVM: 0.089
+performance: 0.082
+other: 0.081
+device: 0.076
+permissions: 0.076
+socket: 0.072
+boot: 0.071
+network: 0.070
+semantic: 0.069
+graphic: 0.069
+vnc: 0.064
+PID: 0.064
+debug: 0.059
+files: 0.059
+KVM: 0.355
+socket: 0.207
+debug: 0.116
+PID: 0.074
+performance: 0.053
+device: 0.047
+other: 0.031
+files: 0.028
+boot: 0.026
+semantic: 0.025
+permissions: 0.012
+network: 0.010
+graphic: 0.009
+vnc: 0.006
+
+qemu crash with assertion in usb_packet_complete_one
+
+qemu release verison: 1.7.1
+guest os : win7 32bits
+qemu cmdline:
+/usr/bin/qemu-system-x86_64 -name hch_test -S -machine pc-i440fx-1.7,accel=kvm,usb=off -cpu SandyBridge,+erms,+smep,+fsgsbase,+pdpe1gb,+rdrand,+f16c,+osxsave,+dca,+pcid,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=12,threads=2 -uuid 5ad433c9-e490-42f3-b365-c30d756fbd70 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/hch_test.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=0 -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/opt/cvm/hch_test/hch_test.inst,if=none,id=drive-virtio-disk0,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/opt/data/hugedisk/hch_test/hch_test_share.add,if=none,id=drive-virtio-disk1,format=qcow2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f2:05:b7,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/hch_test.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -spice port=5903,addr=0.0.0.0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0
+
+i use spice to connect to vm and utilize usb redirection. i plug a u-disk into a remote computer and start copy a big file (3G+) to u-disk and qemu was crashed in the middle of the transmission. 
+
+i check the qemu log and found this log: "qemu-system-x86_64: hw/usb/core.c:438: usb_packet_complete_one: Assertion `p->stream || ((&ep->queue)->tqh_first) == p' failed". this crash can be reproduced every time.
+
+Triaging old bug tickets ... Can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/KVM/1500935 b/results/classifier/111/KVM/1500935
new file mode 100644
index 000000000..0937f5bfe
--- /dev/null
+++ b/results/classifier/111/KVM/1500935
@@ -0,0 +1,48 @@
+KVM: 0.258
+other: 0.134
+semantic: 0.129
+graphic: 0.095
+device: 0.085
+files: 0.048
+permissions: 0.045
+debug: 0.036
+performance: 0.033
+socket: 0.031
+vnc: 0.031
+PID: 0.030
+network: 0.023
+boot: 0.022
+KVM: 0.815
+debug: 0.035
+files: 0.033
+other: 0.032
+PID: 0.014
+socket: 0.012
+network: 0.011
+semantic: 0.011
+performance: 0.010
+device: 0.008
+graphic: 0.006
+boot: 0.006
+permissions: 0.004
+vnc: 0.003
+
+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/111/KVM/1562653 b/results/classifier/111/KVM/1562653
new file mode 100644
index 000000000..974306a64
--- /dev/null
+++ b/results/classifier/111/KVM/1562653
@@ -0,0 +1,179 @@
+KVM: 0.102
+permissions: 0.091
+device: 0.091
+vnc: 0.084
+boot: 0.082
+graphic: 0.081
+PID: 0.074
+other: 0.071
+network: 0.064
+socket: 0.061
+performance: 0.055
+semantic: 0.050
+files: 0.047
+debug: 0.046
+KVM: 0.572
+debug: 0.157
+performance: 0.081
+device: 0.043
+PID: 0.036
+boot: 0.031
+files: 0.021
+socket: 0.018
+other: 0.016
+semantic: 0.008
+permissions: 0.005
+graphic: 0.005
+network: 0.004
+vnc: 0.003
+
+Ubuntu 15.10: QEMU VM hang if memory >= 1T
+
+1. Ubuntu 15.10 x86_64 installed on HP SuperDome X with 8CPUs and 4T memory.
+
+2. Create a VM, install Ubuntu 15.10, if memory >= 1T , VM hang when start. If memory < 1T, it is good.
+<domain type='kvm'>
+  <name>u1510-1</name>
+  <uuid>39eefe1e-4829-4843-b892-026d143f3ec7</uuid>
+  <memory unit='KiB'>1073741824</memory>
+  <currentMemory unit='KiB'>1073741824</currentMemory>
+  <vcpu placement='static'>16</vcpu>
+  <os>
+    <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type>
+    <boot dev='hd'/>
+    <boot dev='cdrom'/>
+  </os>
+  <features>
+    <acpi/>
+    <apic/>
+    <pae/>
+  </features>
+  <clock offset='utc'/>
+  <on_poweroff>destroy</on_poweroff>
+  <on_reboot>restart</on_reboot>
+  <on_crash>restart</on_crash>
+  <devices>
+    <emulator>/usr/bin/kvm</emulator>
+    <disk type='file' device='disk'>
+      <driver name='qemu' type='qcow2' cache='directsync'/>
+      <source file='/vms/images/u1510-1.img'/>
+      <target dev='vda' bus='virtio'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
+    </disk>
+    <disk type='file' device='cdrom'>
+      <driver name='qemu' type='raw'/>
+      <target dev='hdc' bus='ide'/>
+      <readonly/>
+      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
+    </disk>
+    <controller type='pci' index='0' model='pci-root'/>
+    <controller type='ide' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
+    </controller>
+    <controller type='usb' index='0'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+    </controller>
+    <interface type='bridge'>
+      <mac address='0c:da:41:1d:ae:f1'/>
+      <source bridge='vswitch0'/>
+      <model type='virtio'/>
+      <driver name='vhost'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+    </interface>
+    <input type='mouse' bus='ps2'/>
+    <input type='keyboard' bus='ps2'/>
+    <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0'>
+      <listen type='address' address='0.0.0.0'/>
+    </graphics>
+    <video>
+      <model type='cirrus' vram='16384' heads='1'/>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+    </video>
+    <memballoon model='virtio'>
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
+    </memballoon>
+  </devices>
+</domain>
+
+3. The panic stack is
+  ... cannot show
+  async_page_fault+0x28
+  ioread32_rep+0x38
+  ata_sff_data_xfer32+0x8a
+  ata_pio_sector+0x93
+  ata_pio_sectors+0x34
+  ata_sff_hsm_move+0x226
+  RIP: kthread_data+0x10
+  CR2: FFFFFFFF_FFFFFFD8
+
+4. Change the host os to Redhat 7.2 , the vm is good even memory >=3.8T.
+
+I delete cdrom and IDE controller, the vm start sucessfully.
+
+But when I increate memory to 1100G, vm hang at hpet_enable when start.
+
+The panic is page_fault when execute   hpet_period = hpet_readl(HPET_PERIOD);
+
+It seems that ioremap_nocache does not works correctly.
+
+hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE);
+
+Hi,
+
+just to be sure, if you run
+
+kvm -vnc :1 -m 1.5G
+kvm -vnc :1 -m 1.5G --no-hpet
+
+do those also crash?
+
+Can you please show the contents of
+
+/var/log/libvirt/qemu/u1510-1.log
+
+I mean vm hang when memory >= 1100G (1024G when enable ide cdrom)  instead of 1.5G.
+
+If disable hpet, the vm will hang at  acpi_ex_system_memory_space_handler  when memory >= 1100G
+
+If disable kvm, vm is good when memory <= 1020G, but also hang when memory >= 1024G.
+
+There is no critical information in vm.log:
+
+
+After I changed PHYS_ADDR_MASK, qemu vm can start when memory >=1024G , but kvm vm still hang.
+
+-# define PHYS_ADDR_MASK 0xffffffffffLL
++# define PHYS_ADDR_MASK 0xfffffffffffLL
+
+
+The issue is sloved after change cpuid[80000008];
+
+--- a/target-i386/cpu.c
++++ b/target-i386/cpu.c
+@@ -2547,7 +2547,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count,
+         if (env->features[FEAT_8000_0001_EDX] & CPUID_EXT2_LM) {
+             /* 64 bit processor */
+ /* XXX: The physical address space is limited to 42 bits in exec.c. */
+-            *eax = 0x00003028; /* 48 bits virtual, 40 bits physical */
++            *eax = 0x00003029; /* 48 bits virtual, 41 bits physical */
+         } else {
+             if (env->features[FEAT_1_EDX] & CPUID_PSE36) {
+                 *eax = 0x00000024; /* 36 bits physical */
+
+
+For cpus which have not EPT feature, should change CR3_L_MODE_RESERVED_BITS in arch/x86/include/asm/kvm_host.h:
+
+-#define CR3_L_MODE_RESERVED_BITS 0xFFFFFF0000000000ULL
++#define CR3_L_MODE_RESERVED_BITS 0xFFFFFE0000000000ULL
+
+
+Can you still reproduce this problem with the latest version of upstream QEMU?
+
+[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.]
+
+I only saw this because it expired now :-/
+
+Anyone affected by this might want to take a look at bug 1776189 where Ubuntu added a special machine type to more easily set "host-phys-bits" which is the qemu flag to have more (usually the host has more) available (at the cost of migratability). That allows <1TB as the default bits in qemu are chosen on the base of TCG (to be able to emulate what is virtualized) and that is limited to 1TB.
+
diff --git a/results/classifier/111/KVM/1579645 b/results/classifier/111/KVM/1579645
new file mode 100644
index 000000000..19ba35c7f
--- /dev/null
+++ b/results/classifier/111/KVM/1579645
@@ -0,0 +1,47 @@
+KVM: 0.189
+boot: 0.149
+other: 0.110
+graphic: 0.101
+semantic: 0.098
+device: 0.071
+PID: 0.051
+files: 0.050
+performance: 0.039
+vnc: 0.035
+network: 0.031
+permissions: 0.030
+debug: 0.024
+socket: 0.022
+KVM: 0.757
+debug: 0.054
+boot: 0.030
+files: 0.028
+other: 0.023
+device: 0.020
+socket: 0.017
+PID: 0.015
+performance: 0.014
+semantic: 0.013
+network: 0.012
+vnc: 0.007
+permissions: 0.006
+graphic: 0.004
+
+ [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/111/KVM/1675458 b/results/classifier/111/KVM/1675458
new file mode 100644
index 000000000..b092eabf6
--- /dev/null
+++ b/results/classifier/111/KVM/1675458
@@ -0,0 +1,110 @@
+KVM: 0.130
+other: 0.090
+network: 0.085
+device: 0.084
+semantic: 0.076
+boot: 0.073
+PID: 0.067
+socket: 0.064
+permissions: 0.062
+files: 0.057
+graphic: 0.056
+vnc: 0.055
+debug: 0.054
+performance: 0.049
+KVM: 0.827
+debug: 0.044
+other: 0.031
+PID: 0.016
+semantic: 0.012
+device: 0.012
+network: 0.011
+files: 0.011
+socket: 0.009
+vnc: 0.008
+performance: 0.005
+boot: 0.005
+permissions: 0.005
+graphic: 0.004
+
+attach-interface - unexpected action
+
+Hello,
+
+Not sure where to report this, or if it is a bug. However, I feel like the behaviour is not what would/should be expected.
+
+----------------------------------------------------------------------------------------------------------
+
+Environment:
+KVM Version:		root@hostname:~# virsh version
+      			Compiled against library: libvirt 1.2.9
+			Using library: libvirt 1.2.9
+			Using API: QEMU 1.2.9
+			Running hypervisor: QEMU 2.1.2
+uname -a:		Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
+CPU:			Intel(R) Xeon(R) CPU E3-1240 V2 @ 3.40GHz
+Host Debian Version:	8.7 (Jessie)
+Guest Debian Version:	8.7 (Jessie)
+
+----------------------------------------------------------------------------------------------------------
+
+Issue:
+When adding an interface to a live VM, the position of interfaces within the VM may change post reboot.
+It appears a new interface takes up the first available “pci slot”. If you have removed an interface in the past, this will be the one that is taken up.
+
+----------------------------------------------------------------------------------------------------------
+
+Example:
+
+If the VM Has the following interfaces layout:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 11:11:11:11:11:11
+eth2  HWaddr 22:22:22:22:22:22
+eth3  HWaddr 33:33:33:33:33:33
+
+Now I delete the interface with MAC address 11:11:11:11:11:11, you now have this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 22:22:22:22:22:22
+eth2  HWaddr 33:33:33:33:33:33
+
+And then you add a new interface with MAC address 44:44:44:44:44:44, using virsh:
+
+virsh attach-interface --domain guest --type bridge --source br3 --mac 44:44:44:44:44:44 --model e1000 --target vmeth3 --live --persistent
+
+It will now look like this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 22:22:22:22:22:22
+eth2  HWaddr 33:33:33:33:33:33
+eth3  HWaddr 44:44:44:44:44:44
+
+However, after a reboot, it will look like this:
+
+eth0  HWaddr 00:00:00:00:00:00
+eth1  HWaddr 44:44:44:44:44:44
+eth2  HWaddr 22:22:22:22:22:22
+eth3  HWaddr 33:33:33:33:33:33 
+
+This can be a problem, as /etc/network/interfaces file, etc., will be pointing to the wrong interfaces. I.E. originally eth1 was connected to br1 (for example), after reboot eth1 is now connected to br3.
+
+To resolve this issue, I need to edit the .xml file in the KVM machine, and edit the following lines:
+
+      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
+
+Changing these into the order I want them to be loaded in, i.e. eth0, eth1, eth2…. (I know 4 are taken already and not usable by ethernet interfaces.)
+
+----------------------------------------------------------------------------------------------------------
+
+
+Thanks in advance.
+
+Kind regards,
+
+Aaron Doyle
+
+Looking through old bug tickets ... Have you tried to discuss this issue with the libvirt people? They might need to have a look at your virsh commands first before one could decide whether this is a libvirt or a qemu problem...
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/KVM/1686350 b/results/classifier/111/KVM/1686350
new file mode 100644
index 000000000..41007feec
--- /dev/null
+++ b/results/classifier/111/KVM/1686350
@@ -0,0 +1,80 @@
+KVM: 0.371
+semantic: 0.101
+device: 0.079
+permissions: 0.061
+PID: 0.056
+performance: 0.055
+socket: 0.053
+other: 0.050
+graphic: 0.039
+debug: 0.033
+network: 0.029
+boot: 0.027
+files: 0.024
+vnc: 0.021
+KVM: 0.823
+debug: 0.110
+files: 0.011
+socket: 0.009
+other: 0.008
+PID: 0.007
+device: 0.007
+boot: 0.005
+semantic: 0.005
+performance: 0.005
+network: 0.003
+permissions: 0.003
+graphic: 0.002
+vnc: 0.001
+
+[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/111/KVM/1807052 b/results/classifier/111/KVM/1807052
new file mode 100644
index 000000000..39e61fd92
--- /dev/null
+++ b/results/classifier/111/KVM/1807052
@@ -0,0 +1,391 @@
+KVM: 0.110
+vnc: 0.097
+permissions: 0.080
+other: 0.071
+files: 0.068
+network: 0.066
+boot: 0.066
+device: 0.066
+performance: 0.066
+graphic: 0.065
+debug: 0.064
+socket: 0.061
+PID: 0.060
+semantic: 0.060
+KVM: 0.689
+debug: 0.188
+performance: 0.021
+PID: 0.016
+files: 0.015
+device: 0.013
+socket: 0.012
+semantic: 0.011
+other: 0.010
+boot: 0.009
+permissions: 0.006
+network: 0.004
+graphic: 0.003
+vnc: 0.002
+
+Qemu hangs during migration
+
+Source server: linux 4.19.5 qemu-3.0.0 from source, libvirt 4.9
+Dest server: linux 4.18.19 qemu-3.0.0 from source, libvirt 4.9
+
+When this VM is running on source server:
+
+/usr/bin/qemu-system-x86_64 -name guest=testvm,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-testvm/master-key.aes -machine pc-q35-3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_reset,hv_vendor_id=KVM Hv -m 4096 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -object iothread,id=iothread1 -uuid 3b00b788-ee91-4e45-80a6-c7319da71225 -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=23,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-pci-bridge,id=pci.3,bus=pci.1,addr=0x0 -device pcie-root-port,port=0x12,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x3 -device piix3-usb-uhci,id=usb,bus=pci.3,addr=0x1 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,bus=pci.4,addr=0x0 -drive file=/dev/zvol/datastore/vm/testvm-vda,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback,aio=threads -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=2,write-cache=on -drive if=none,id=drive-sata0-0-4,media=cdrom,readonly=on -device ide-cd,bus=ide.4,drive=drive-sata0-0-4,id=sata0-0-4,bootindex=1 -netdev tap,fd=25,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a2:b7:a1,bus=pci.2,addr=0x0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pcie.0,addr=0x1 -s -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
+
+I try to migrate it and the disks to the other side:
+
+virsh migrate --live --undefinesource --persistent --verbose --copy-storage-all testvm qemu+ssh://wasvirt1/system
+
+We get to 99% then hang with both sides in the pause state.
+
+Source server is stuck here:
+(gdb) bt full
+#0  0x00007f327994f3c1 in ppoll () at /lib64/libc.so.6
+#1  0x000000000086167b in qemu_poll_ns (fds=<optimized out>, nfds=nfds@entry=1, timeout=<optimized out>) at util/qemu-timer.c:322
+#2  0x0000000000863302 in aio_poll (ctx=0x21044e0, blocking=blocking@entry=true) at util/aio-posix.c:629
+        node = <optimized out>
+        i = <optimized out>
+        ret = 0
+        progress = <optimized out>
+        timeout = <optimized out>
+        start = <optimized out>
+        __PRETTY_FUNCTION__ = "aio_poll"
+#3  0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:62
+        waited_ = <optimized out>
+        wait_ = 0x2ba563c
+        ctx_ = 0x2109bb0
+        bs_ = 0x2ba2400
+        client = 0x31287e0
+        client = <optimized out>
+        request = {handle = 0, from = 0, len = 0, flags = 0, type = 2}
+#4  0x00000000007e0d52 in nbd_client_close (bs=0x2ba2400) at block/nbd-client.c:965
+        client = <optimized out>
+        request = {handle = 0, from = 0, len = 0, flags = 0, type = 2}
+#5  0x00000000007de5ca in nbd_close (bs=<optimized out>) at block/nbd.c:491
+        s = 0x31287e0
+#6  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3352
+        ban = <optimized out>
+        ban_next = <optimized out>
+        child = <optimized out>
+        next = <optimized out>
+#7  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:3560
+#8  0x00000000007823d6 in bdrv_unref (bs=0x2ba2400) at block.c:4616
+#9  0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3359
+        ban = <optimized out>
+        ban_next = <optimized out>
+        child = <optimized out>
+        next = <optimized out>
+#10 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:3560
+#11 0x0000000000782403 in bdrv_unref (bs=0x2af96f0) at block.c:4616
+#12 0x0000000000785784 in block_job_remove_all_bdrv (job=job@entry=0x2f32570) at blockjob.c:200
+        c = 0x23bac30
+        l = 0x20dd330 = {0x23bac30, 0x2b89410}
+#13 0x00000000007ceb5f in mirror_exit (job=0x2f32570, opaque=0x7f326407a350) at block/mirror.c:700
+        s = 0x2f32570
+        bjob = 0x2f32570
+        data = 0x7f326407a350
+        bs_opaque = 0x30d5600
+        replace_aio_context = <optimized out>
+        src = 0x2131080
+        target_bs = 0x2af96f0
+        mirror_top_bs = 0x210eb70
+        local_err = 0x0
+#14 0x0000000000786452 in job_defer_to_main_loop_bh (opaque=0x7f32640786a0) at job.c:973
+        data = 0x7f32640786a0
+        job = <optimized out>
+        aio_context = 0x2109bb0
+#15 0x000000000085fd3f in aio_bh_poll (ctx=ctx@entry=0x21044e0) at util/async.c:118
+---Type <return> to continue, or q <return> to quit---
+        bh = <optimized out>
+        bhp = <optimized out>
+        next = 0x2ea86e0
+        ret = 1
+        deleted = false
+#16 0x00000000008631b0 in aio_dispatch (ctx=0x21044e0) at util/aio-posix.c:436
+#17 0x000000000085fc1e in aio_ctx_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at util/async.c:261
+        ctx = <optimized out>
+#18 0x00007f327f17d797 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
+#19 0x00000000008622ed in main_loop_wait () at util/main-loop.c:215
+        context = 0x2104900
+        pfds = <optimized out>
+        context = 0x2104900
+        ret = 1
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#20 0x00000000008622ed in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:238
+        context = 0x2104900
+        ret = 1
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#21 0x00000000008622ed in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#22 0x0000000000595dee in main_loop () at vl.c:1866
+#23 0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 71
+        optarg = 0x7ffdfc94df69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7ffdfc94d864 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x0
+        userconfig = <optimized out>
+---Type <return> to continue, or q <return> to quit---
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdfc94c170}
+        __func__ = "main"
+
+Strace shows:
+ppoll([{fd=9, events=POLLIN|POLLERR|POLLHUP}], 1, NULL, NULL, 8
+
+Which points to this:
+
+ls -al /proc/2286/fd/9
+lrwx------    1 root     users           64 Dec  5 13:04 /proc/2286/fd/9 -> anon_inode:[eventfd]
+
+The dest side is stuck here:
+
+(gdb) bt full
+#0  0x00007f21f070d3c1 in ppoll () at /lib64/libc.so.6
+#1  0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999926258) at util/qemu-timer.c:334
+        ts = {tv_sec = 2, tv_nsec = 999926258}
+Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.:
+#2  0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233
+        context = 0x2142900
+        ret = <optimized out>
+        ret = -1295041038
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#3  0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = -1295041038
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#4  0x0000000000595dee in main_loop () at vl.c:1866
+#5  0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 73
+        optarg = 0x7ffdd6ee8f69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7ffdd6ee8854 "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x7ffdd6ee8f0a "defer"
+        userconfig = <optimized out>
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffdd6ee6630}
+---Type <return> to continue, or q <return> to quit---
+        __func__ = "main"
+
+Strace show this over and over
+ppoll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=27, events=POLLIN}], 9, {0, 594527977}, NULL, 8) = 0 (Timeout)
+
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/10 -> anon_inode:[eventfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/21 -> socket:[42631161]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/22 -> socket:[42631165]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/23 -> socket:[42631167]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/24 -> socket:[42631168]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/27 -> socket:[42690422]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/6 -> anon_inode:[eventfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/7 -> anon_inode:[signalfd]
+lrwx------    1 root     users           64 Dec  5 13:15 /proc/20170/fd/9 -> anon_inode:[eventfd]
+
+If I remote iothreads and writeback caching, it seems more reliable, but I can still get it to hang.
+
+This time the source server shows the VM as running, backtrace looks like:
+
+(gdb) bt full
+#0  0x00007f27eab0028c in __lll_lock_wait () at /lib64/libpthread.so.0
+#1  0x00007f27eaaf9d35 in pthread_mutex_lock () at /lib64/libpthread.so.0
+#2  0x0000000000865419 in qemu_mutex_lock_impl (mutex=mutex@entry=0x115b8e0 <qemu_global_mutex>, file=file@entry=0x8fdf14 "/tmp/qemu-3.0.0/cpus.c", line=line@entry=1768)
+    at util/qemu-thread-posix.c:66
+        err = <optimized out>
+        __PRETTY_FUNCTION__ = "qemu_mutex_lock_impl"
+        __func__ = "qemu_mutex_lock_impl"
+#3  0x0000000000477578 in qemu_mutex_lock_iothread () at /tmp/qemu-3.0.0/cpus.c:1768
+#4  0x00000000008622b0 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:236
+        context = 0x1e72810
+        ret = 1
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#5  0x00000000008622b0 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = 1
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#6  0x0000000000595dee in main_loop () at vl.c:1866
+#7  0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 71
+        optarg = 0x7fff5edcff69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7fff5edcf88a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x7fff5edcff0a "defer"
+        userconfig = <optimized out>
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+---Type <return> to continue, or q <return> to quit---
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7fff5edcd670}
+        __func__ = "main"
+
+
+Dest server is paused, and looks like this:
+
+#0  0x00007f11c48bc3c1 in ppoll () at /lib64/libc.so.6
+#1  0x0000000000861659 in qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=timeout@entry=2999892383) at util/qemu-timer.c:334
+        ts = {tv_sec = 2, tv_nsec = 999892383}
+Python Exception <class 'gdb.error'> That operation is not available on integers of more than 8 bytes.:
+#2  0x00000000008622a4 in main_loop_wait (timeout=<optimized out>) at util/main-loop.c:233
+        context = 0x2342810
+        ret = <optimized out>
+        ret = -1295074913
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#3  0x00000000008622a4 in main_loop_wait (nonblocking=nonblocking@entry=0) at util/main-loop.c:497
+        ret = -1295074913
+        timeout = 4294967295
+        timeout_ns = <optimized out>
+#4  0x0000000000595dee in main_loop () at vl.c:1866
+#5  0x000000000041f35d in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4644
+        i = <optimized out>
+        snapshot = 0
+        linux_boot = <optimized out>
+        initrd_filename = 0x0
+        kernel_filename = <optimized out>
+        kernel_cmdline = <optimized out>
+        boot_order = 0x918f44 "cad"
+        boot_once = 0x0
+        ds = <optimized out>
+        opts = <optimized out>
+        machine_opts = <optimized out>
+        icount_opts = <optimized out>
+        accel_opts = 0x0
+        olist = <optimized out>
+        optind = 71
+        optarg = 0x7ffe6b899f69 "timestamp=on"
+        loadvm = 0x0
+        machine_class = 0x0
+        cpu_model = 0x7ffe6b89988a "Skylake-Server-IBRS,ss=on,hypervisor=on,tsc_adjust=on,clflushopt=on,umip=on,pku=on,ssbd=on,xsaves=on,topoext=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vpindex,hv_runtime,hv_synic,hv_stimer"...
+        vga_model = 0x0
+        qtest_chrdev = 0x0
+        qtest_log = 0x0
+        pid_file = <optimized out>
+        incoming = 0x7ffe6b899f0a "defer"
+        userconfig = <optimized out>
+        nographic = false
+        display_remote = <optimized out>
+        log_mask = <optimized out>
+        log_file = <optimized out>
+        trace_file = <optimized out>
+        maxram_size = 4294967296
+        ram_slots = 0
+        vmstate_dump_file = 0x0
+        main_loop_err = 0x0
+        err = 0x0
+        list_data_dirs = false
+        dir = <optimized out>
+        dirs = <optimized out>
+        bdo_queue = {sqh_first = 0x0, sqh_last = 0x7ffe6b8988e0}
+---Type <return> to continue, or q <return> to quit---
+        __func__ = "main"
+
+Honestly looks pretty much like the same bug....
+
+
+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/111/KVM/25892827 b/results/classifier/111/KVM/25892827
new file mode 100644
index 000000000..ea8441f41
--- /dev/null
+++ b/results/classifier/111/KVM/25892827
@@ -0,0 +1,1101 @@
+KVM: 0.090
+other: 0.086
+permissions: 0.081
+debug: 0.077
+boot: 0.076
+device: 0.073
+vnc: 0.069
+network: 0.069
+semantic: 0.067
+socket: 0.066
+PID: 0.065
+performance: 0.062
+graphic: 0.059
+files: 0.059
+KVM: 0.484
+debug: 0.221
+PID: 0.067
+performance: 0.042
+files: 0.041
+boot: 0.027
+other: 0.026
+device: 0.020
+socket: 0.019
+semantic: 0.015
+permissions: 0.011
+vnc: 0.011
+network: 0.010
+graphic: 0.007
+
+[Qemu-devel] [BUG/RFC] Two cpus are not brought up normally in SLES11 sp3 VM after reboot
+
+Hi,
+
+Recently we encountered a problem in our project: 2 CPUs in VM are not brought 
+up normally after reboot.
+
+Our host is using KVM kmod 3.6 and QEMU 2.1.
+A SLES 11 sp3 VM configured with 8 vcpus,
+cpu model is configured with 'host-passthrough'.
+
+After VM's first time started up, everything seems to be OK.
+and then VM is paniced and rebooted.
+After reboot, only 6 cpus are brought up in VM, cpu1 and cpu7 are not online.
+
+This is the only message we can get from VM:
+VM dmesg shows:
+[    0.069867] Booting Node   0, Processors  #1
+[    5.060042] CPU1: Stuck ??
+[    5.060499]  #2
+[    5.088322] kvm-clock: cpu 2, msr 6:3fc90901, secondary cpu clock
+[    5.088335] KVM setup async PF for cpu 2
+[    5.092967] NMI watchdog enabled, takes one hw-pmu counter.
+[    5.094405]  #3
+[    5.108324] kvm-clock: cpu 3, msr 6:3fcd0901, secondary cpu clock
+[    5.108333] KVM setup async PF for cpu 3
+[    5.113553] NMI watchdog enabled, takes one hw-pmu counter.
+[    5.114970]  #4
+[    5.128325] kvm-clock: cpu 4, msr 6:3fd10901, secondary cpu clock
+[    5.128336] KVM setup async PF for cpu 4
+[    5.134576] NMI watchdog enabled, takes one hw-pmu counter.
+[    5.135998]  #5
+[    5.152324] kvm-clock: cpu 5, msr 6:3fd50901, secondary cpu clock
+[    5.152334] KVM setup async PF for cpu 5
+[    5.154764] NMI watchdog enabled, takes one hw-pmu counter.
+[    5.156467]  #6
+[    5.172327] kvm-clock: cpu 6, msr 6:3fd90901, secondary cpu clock
+[    5.172341] KVM setup async PF for cpu 6
+[    5.180738] NMI watchdog enabled, takes one hw-pmu counter.
+[    5.182173]  #7 Ok.
+[   10.170815] CPU7: Stuck ??
+[   10.171648] Brought up 6 CPUs
+[   10.172394] Total of 6 processors activated (28799.97 BogoMIPS).
+
+From host, we found that QEMU vcpu1 thread and vcpu7 thread were not consuming 
+any cpu (Should be in idle state),
+All of VCPUs' stacks in host is like bellow:
+
+[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+[<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+[<ffffffffffffffff>] 0xffffffffffffffff
+
+We looked into the kernel codes that could leading to the above 'Stuck' warning,
+and found that the only possible is the emulation of 'cpuid' instruct in 
+kvm/qemu has something wrong.
+But since we can’t reproduce this problem, we are not quite sure.
+Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+
+Has anyone come across these problem before? Or any idea?
+
+Thanks,
+zhanghailiang
+
+On 06/07/2015 09:54, zhanghailiang wrote:
+>
+>
+From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+>
+consuming any cpu (Should be in idle state),
+>
+All of VCPUs' stacks in host is like bellow:
+>
+>
+[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+>
+[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+>
+[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+>
+[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+>
+[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+>
+[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+>
+[<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+>
+[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+>
+[<ffffffffffffffff>] 0xffffffffffffffff
+>
+>
+We looked into the kernel codes that could leading to the above 'Stuck'
+>
+warning,
+>
+and found that the only possible is the emulation of 'cpuid' instruct in
+>
+kvm/qemu has something wrong.
+>
+But since we can’t reproduce this problem, we are not quite sure.
+>
+Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+Can you explain the relationship to the cpuid emulation?  What do the
+traces say about vcpus 1 and 7?
+
+Paolo
+
+On 2015/7/6 16:45, Paolo Bonzini wrote:
+On 06/07/2015 09:54, zhanghailiang wrote:
+From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+consuming any cpu (Should be in idle state),
+All of VCPUs' stacks in host is like bellow:
+
+[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+[<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+[<ffffffffffffffff>] 0xffffffffffffffff
+
+We looked into the kernel codes that could leading to the above 'Stuck'
+warning,
+and found that the only possible is the emulation of 'cpuid' instruct in
+kvm/qemu has something wrong.
+But since we can’t reproduce this problem, we are not quite sure.
+Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+Can you explain the relationship to the cpuid emulation?  What do the
+traces say about vcpus 1 and 7?
+OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is 
+located in
+do_boot_cpu(). It's in BSP context, the call process is:
+BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() 
+-> wakeup_secondary_via_INIT() to trigger APs.
+It will wait 5s for APs to startup, if some AP not startup normally, it will 
+print 'CPU%d Stuck' or 'CPU%d: Not responding'.
+
+If it prints 'Stuck', it means the AP has received the SIPI interrupt and 
+begins to execute the code
+'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before 
+smp_callin()(smpboot.c).
+The follow is the starup process of BSP and AP.
+BSP:
+start_kernel()
+  ->smp_init()
+     ->smp_boot_cpus()
+       ->do_boot_cpu()
+           ->start_ip = trampoline_address(); //set the address that AP will go 
+to execute
+           ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
+           ->for (timeout = 0; timeout < 50000; timeout++)
+               if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if AP 
+startup or not
+
+APs:
+ENTRY(trampoline_data) (trampoline_64.S)
+      ->ENTRY(secondary_startup_64) (head_64.S)
+         ->start_secondary() (smpboot.c)
+            ->cpu_init();
+            ->smp_callin();
+                ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP comes 
+here, the BSP will not prints the error message.
+
+From above call process, we can be sure that, the AP has been stuck between 
+trampoline_data and the cpumask_set_cpu() in
+smp_callin(), we look through these codes path carefully, and only found a 
+'hlt' instruct that could block the process.
+It is located in trampoline_data():
+
+ENTRY(trampoline_data)
+        ...
+
+        call    verify_cpu              # Verify the cpu supports long mode
+        testl   %eax, %eax              # Check for return code
+        jnz     no_longmode
+
+        ...
+
+no_longmode:
+        hlt
+        jmp no_longmode
+
+For the process verify_cpu(),
+we can only find the 'cpuid' sensitive instruct that could lead VM exit from 
+No-root mode.
+This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to 
+the fail in verify_cpu.
+
+From the message in VM, we know vcpu1 and vcpu7 is something wrong.
+[    5.060042] CPU1: Stuck ??
+[   10.170815] CPU7: Stuck ??
+[   10.171648] Brought up 6 CPUs
+
+Besides, the follow is the cpus message got from host.
+80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command 
+instance-0000000
+* CPU #0: pc=0x00007f64160c683d thread_id=68570
+  CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+  CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+  CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+  CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+  CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+  CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+  CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+
+Oh, i also forgot to mention in the above message that, we have bond each vCPU 
+to different physical CPU in
+host.
+
+Thanks,
+zhanghailiang
+
+On 06/07/2015 11:59, zhanghailiang wrote:
+>
+>
+>
+Besides, the follow is the cpus message got from host.
+>
+80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh
+>
+qemu-monitor-command instance-0000000
+>
+* CPU #0: pc=0x00007f64160c683d thread_id=68570
+>
+CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+>
+CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+>
+CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+>
+CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+>
+CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+>
+CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+>
+CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+>
+>
+Oh, i also forgot to mention in the above message that, we have bond
+>
+each vCPU to different physical CPU in
+>
+host.
+Can you capture a trace on the host (trace-cmd record -e kvm) and send
+it privately?  Please note which CPUs get stuck, since I guess it's not
+always 1 and 7.
+
+Paolo
+
+On Mon, 6 Jul 2015 17:59:10 +0800
+zhanghailiang <address@hidden> wrote:
+
+>
+On 2015/7/6 16:45, Paolo Bonzini wrote:
+>
+>
+>
+>
+>
+> On 06/07/2015 09:54, zhanghailiang wrote:
+>
+>>
+>
+>>  From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+>
+>> consuming any cpu (Should be in idle state),
+>
+>> All of VCPUs' stacks in host is like bellow:
+>
+>>
+>
+>> [<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+>
+>> [<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+>
+>> [<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+>
+>> [<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+>
+>> [<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+>
+>> [<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+>
+>> [<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+>
+>> [<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+>
+>> [<ffffffffffffffff>] 0xffffffffffffffff
+>
+>>
+>
+>> We looked into the kernel codes that could leading to the above 'Stuck'
+>
+>> warning,
+in current upstream there isn't any printk(...Stuck...) left since that code 
+path
+has been reworked.
+I've often seen this on over-committed host during guest CPUs up/down torture 
+test.
+Could you update guest kernel to upstream and see if issue reproduces?
+
+>
+>> and found that the only possible is the emulation of 'cpuid' instruct in
+>
+>> kvm/qemu has something wrong.
+>
+>> But since we can’t reproduce this problem, we are not quite sure.
+>
+>> Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+>
+>
+>
+> Can you explain the relationship to the cpuid emulation?  What do the
+>
+> traces say about vcpus 1 and 7?
+>
+>
+OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is
+>
+located in
+>
+do_boot_cpu(). It's in BSP context, the call process is:
+>
+BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu()
+>
+-> wakeup_secondary_via_INIT() to trigger APs.
+>
+It will wait 5s for APs to startup, if some AP not startup normally, it will
+>
+print 'CPU%d Stuck' or 'CPU%d: Not responding'.
+>
+>
+If it prints 'Stuck', it means the AP has received the SIPI interrupt and
+>
+begins to execute the code
+>
+'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places
+>
+before smp_callin()(smpboot.c).
+>
+The follow is the starup process of BSP and AP.
+>
+BSP:
+>
+start_kernel()
+>
+->smp_init()
+>
+->smp_boot_cpus()
+>
+->do_boot_cpu()
+>
+->start_ip = trampoline_address(); //set the address that AP will
+>
+go to execute
+>
+->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
+>
+->for (timeout = 0; timeout < 50000; timeout++)
+>
+if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if
+>
+AP startup or not
+>
+>
+APs:
+>
+ENTRY(trampoline_data) (trampoline_64.S)
+>
+->ENTRY(secondary_startup_64) (head_64.S)
+>
+->start_secondary() (smpboot.c)
+>
+->cpu_init();
+>
+->smp_callin();
+>
+->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP
+>
+comes here, the BSP will not prints the error message.
+>
+>
+From above call process, we can be sure that, the AP has been stuck between
+>
+trampoline_data and the cpumask_set_cpu() in
+>
+smp_callin(), we look through these codes path carefully, and only found a
+>
+'hlt' instruct that could block the process.
+>
+It is located in trampoline_data():
+>
+>
+ENTRY(trampoline_data)
+>
+...
+>
+>
+call    verify_cpu              # Verify the cpu supports long mode
+>
+testl   %eax, %eax              # Check for return code
+>
+jnz     no_longmode
+>
+>
+...
+>
+>
+no_longmode:
+>
+hlt
+>
+jmp no_longmode
+>
+>
+For the process verify_cpu(),
+>
+we can only find the 'cpuid' sensitive instruct that could lead VM exit from
+>
+No-root mode.
+>
+This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to
+>
+the fail in verify_cpu.
+>
+>
+From the message in VM, we know vcpu1 and vcpu7 is something wrong.
+>
+[    5.060042] CPU1: Stuck ??
+>
+[   10.170815] CPU7: Stuck ??
+>
+[   10.171648] Brought up 6 CPUs
+>
+>
+Besides, the follow is the cpus message got from host.
+>
+80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh
+>
+qemu-monitor-command instance-0000000
+>
+* CPU #0: pc=0x00007f64160c683d thread_id=68570
+>
+CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+>
+CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+>
+CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+>
+CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+>
+CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+>
+CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+>
+CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+>
+>
+Oh, i also forgot to mention in the above message that, we have bond each
+>
+vCPU to different physical CPU in
+>
+host.
+>
+>
+Thanks,
+>
+zhanghailiang
+>
+>
+>
+>
+>
+--
+>
+To unsubscribe from this list: send the line "unsubscribe kvm" in
+>
+the body of a message to address@hidden
+>
+More majordomo info at
+http://vger.kernel.org/majordomo-info.html
+
+On 2015/7/7 19:23, Igor Mammedov wrote:
+On Mon, 6 Jul 2015 17:59:10 +0800
+zhanghailiang <address@hidden> wrote:
+On 2015/7/6 16:45, Paolo Bonzini wrote:
+On 06/07/2015 09:54, zhanghailiang wrote:
+From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+consuming any cpu (Should be in idle state),
+All of VCPUs' stacks in host is like bellow:
+
+[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+[<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+[<ffffffffffffffff>] 0xffffffffffffffff
+
+We looked into the kernel codes that could leading to the above 'Stuck'
+warning,
+in current upstream there isn't any printk(...Stuck...) left since that code 
+path
+has been reworked.
+I've often seen this on over-committed host during guest CPUs up/down torture 
+test.
+Could you update guest kernel to upstream and see if issue reproduces?
+Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to 
+reproduce it.
+
+For your test case, is it a kernel bug?
+Or is there any related patch could solve your test problem been merged into
+upstream ?
+
+Thanks,
+zhanghailiang
+and found that the only possible is the emulation of 'cpuid' instruct in
+kvm/qemu has something wrong.
+But since we can’t reproduce this problem, we are not quite sure.
+Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+Can you explain the relationship to the cpuid emulation?  What do the
+traces say about vcpus 1 and 7?
+OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is 
+located in
+do_boot_cpu(). It's in BSP context, the call process is:
+BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() 
+-> wakeup_secondary_via_INIT() to trigger APs.
+It will wait 5s for APs to startup, if some AP not startup normally, it will 
+print 'CPU%d Stuck' or 'CPU%d: Not responding'.
+
+If it prints 'Stuck', it means the AP has received the SIPI interrupt and 
+begins to execute the code
+'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before 
+smp_callin()(smpboot.c).
+The follow is the starup process of BSP and AP.
+BSP:
+start_kernel()
+    ->smp_init()
+       ->smp_boot_cpus()
+         ->do_boot_cpu()
+             ->start_ip = trampoline_address(); //set the address that AP will 
+go to execute
+             ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
+             ->for (timeout = 0; timeout < 50000; timeout++)
+                 if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if 
+AP startup or not
+
+APs:
+ENTRY(trampoline_data) (trampoline_64.S)
+        ->ENTRY(secondary_startup_64) (head_64.S)
+           ->start_secondary() (smpboot.c)
+              ->cpu_init();
+              ->smp_callin();
+                  ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP 
+comes here, the BSP will not prints the error message.
+
+  From above call process, we can be sure that, the AP has been stuck between 
+trampoline_data and the cpumask_set_cpu() in
+smp_callin(), we look through these codes path carefully, and only found a 
+'hlt' instruct that could block the process.
+It is located in trampoline_data():
+
+ENTRY(trampoline_data)
+          ...
+
+        call    verify_cpu              # Verify the cpu supports long mode
+        testl   %eax, %eax              # Check for return code
+        jnz     no_longmode
+
+          ...
+
+no_longmode:
+        hlt
+        jmp no_longmode
+
+For the process verify_cpu(),
+we can only find the 'cpuid' sensitive instruct that could lead VM exit from 
+No-root mode.
+This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to 
+the fail in verify_cpu.
+
+  From the message in VM, we know vcpu1 and vcpu7 is something wrong.
+[    5.060042] CPU1: Stuck ??
+[   10.170815] CPU7: Stuck ??
+[   10.171648] Brought up 6 CPUs
+
+Besides, the follow is the cpus message got from host.
+80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command 
+instance-0000000
+* CPU #0: pc=0x00007f64160c683d thread_id=68570
+    CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+    CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+    CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+    CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+    CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+    CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+    CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+
+Oh, i also forgot to mention in the above message that, we have bond each vCPU 
+to different physical CPU in
+host.
+
+Thanks,
+zhanghailiang
+
+
+
+
+--
+To unsubscribe from this list: send the line "unsubscribe kvm" in
+the body of a message to address@hidden
+More majordomo info at
+http://vger.kernel.org/majordomo-info.html
+.
+
+On Tue, 7 Jul 2015 19:43:35 +0800
+zhanghailiang <address@hidden> wrote:
+
+>
+On 2015/7/7 19:23, Igor Mammedov wrote:
+>
+> On Mon, 6 Jul 2015 17:59:10 +0800
+>
+> zhanghailiang <address@hidden> wrote:
+>
+>
+>
+>> On 2015/7/6 16:45, Paolo Bonzini wrote:
+>
+>>>
+>
+>>>
+>
+>>> On 06/07/2015 09:54, zhanghailiang wrote:
+>
+>>>>
+>
+>>>>   From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+>
+>>>> consuming any cpu (Should be in idle state),
+>
+>>>> All of VCPUs' stacks in host is like bellow:
+>
+>>>>
+>
+>>>> [<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+>
+>>>> [<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+>
+>>>> [<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+>
+>>>> [<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+>
+>>>> [<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+>
+>>>> [<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+>
+>>>> [<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+>
+>>>> [<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+>
+>>>> [<ffffffffffffffff>] 0xffffffffffffffff
+>
+>>>>
+>
+>>>> We looked into the kernel codes that could leading to the above 'Stuck'
+>
+>>>> warning,
+>
+> in current upstream there isn't any printk(...Stuck...) left since that
+>
+> code path
+>
+> has been reworked.
+>
+> I've often seen this on over-committed host during guest CPUs up/down
+>
+> torture test.
+>
+> Could you update guest kernel to upstream and see if issue reproduces?
+>
+>
+>
+>
+Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to
+>
+reproduce it.
+>
+>
+For your test case, is it a kernel bug?
+>
+Or is there any related patch could solve your test problem been merged into
+>
+upstream ?
+I don't remember all prerequisite patches but you should be able to find
+http://marc.info/?l=linux-kernel&m=140326703108009&w=2
+"x86/smpboot: Initialize secondary CPU only if master CPU will wait for it"
+and then look for dependencies.
+
+
+>
+>
+Thanks,
+>
+zhanghailiang
+>
+>
+>>>> and found that the only possible is the emulation of 'cpuid' instruct in
+>
+>>>> kvm/qemu has something wrong.
+>
+>>>> But since we can’t reproduce this problem, we are not quite sure.
+>
+>>>> Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+>
+>>>
+>
+>>> Can you explain the relationship to the cpuid emulation?  What do the
+>
+>>> traces say about vcpus 1 and 7?
+>
+>>
+>
+>> OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is
+>
+>> located in
+>
+>> do_boot_cpu(). It's in BSP context, the call process is:
+>
+>> BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() ->
+>
+>> do_boot_cpu() -> wakeup_secondary_via_INIT() to trigger APs.
+>
+>> It will wait 5s for APs to startup, if some AP not startup normally, it
+>
+>> will print 'CPU%d Stuck' or 'CPU%d: Not responding'.
+>
+>>
+>
+>> If it prints 'Stuck', it means the AP has received the SIPI interrupt and
+>
+>> begins to execute the code
+>
+>> 'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places
+>
+>> before smp_callin()(smpboot.c).
+>
+>> The follow is the starup process of BSP and AP.
+>
+>> BSP:
+>
+>> start_kernel()
+>
+>>     ->smp_init()
+>
+>>        ->smp_boot_cpus()
+>
+>>          ->do_boot_cpu()
+>
+>>              ->start_ip = trampoline_address(); //set the address that AP
+>
+>> will go to execute
+>
+>>              ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
+>
+>>              ->for (timeout = 0; timeout < 50000; timeout++)
+>
+>>                  if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;//
+>
+>> check if AP startup or not
+>
+>>
+>
+>> APs:
+>
+>> ENTRY(trampoline_data) (trampoline_64.S)
+>
+>>         ->ENTRY(secondary_startup_64) (head_64.S)
+>
+>>            ->start_secondary() (smpboot.c)
+>
+>>               ->cpu_init();
+>
+>>               ->smp_callin();
+>
+>>                   ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP
+>
+>> comes here, the BSP will not prints the error message.
+>
+>>
+>
+>>   From above call process, we can be sure that, the AP has been stuck
+>
+>> between trampoline_data and the cpumask_set_cpu() in
+>
+>> smp_callin(), we look through these codes path carefully, and only found a
+>
+>> 'hlt' instruct that could block the process.
+>
+>> It is located in trampoline_data():
+>
+>>
+>
+>> ENTRY(trampoline_data)
+>
+>>           ...
+>
+>>
+>
+>>    call    verify_cpu              # Verify the cpu supports long mode
+>
+>>    testl   %eax, %eax              # Check for return code
+>
+>>    jnz     no_longmode
+>
+>>
+>
+>>           ...
+>
+>>
+>
+>> no_longmode:
+>
+>>    hlt
+>
+>>    jmp no_longmode
+>
+>>
+>
+>> For the process verify_cpu(),
+>
+>> we can only find the 'cpuid' sensitive instruct that could lead VM exit
+>
+>> from No-root mode.
+>
+>> This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading
+>
+>> to the fail in verify_cpu.
+>
+>>
+>
+>>   From the message in VM, we know vcpu1 and vcpu7 is something wrong.
+>
+>> [    5.060042] CPU1: Stuck ??
+>
+>> [   10.170815] CPU7: Stuck ??
+>
+>> [   10.171648] Brought up 6 CPUs
+>
+>>
+>
+>> Besides, the follow is the cpus message got from host.
+>
+>> 80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh
+>
+>> qemu-monitor-command instance-0000000
+>
+>> * CPU #0: pc=0x00007f64160c683d thread_id=68570
+>
+>>     CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+>
+>>     CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+>
+>>     CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+>
+>>     CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+>
+>>     CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+>
+>>     CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+>
+>>     CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+>
+>>
+>
+>> Oh, i also forgot to mention in the above message that, we have bond each
+>
+>> vCPU to different physical CPU in
+>
+>> host.
+>
+>>
+>
+>> Thanks,
+>
+>> zhanghailiang
+>
+>>
+>
+>>
+>
+>>
+>
+>>
+>
+>> --
+>
+>> To unsubscribe from this list: send the line "unsubscribe kvm" in
+>
+>> the body of a message to address@hidden
+>
+>> More majordomo info at
+http://vger.kernel.org/majordomo-info.html
+>
+>
+>
+>
+>
+> .
+>
+>
+>
+>
+>
+
+On 2015/7/7 20:21, Igor Mammedov wrote:
+On Tue, 7 Jul 2015 19:43:35 +0800
+zhanghailiang <address@hidden> wrote:
+On 2015/7/7 19:23, Igor Mammedov wrote:
+On Mon, 6 Jul 2015 17:59:10 +0800
+zhanghailiang <address@hidden> wrote:
+On 2015/7/6 16:45, Paolo Bonzini wrote:
+On 06/07/2015 09:54, zhanghailiang wrote:
+From host, we found that QEMU vcpu1 thread and vcpu7 thread were not
+consuming any cpu (Should be in idle state),
+All of VCPUs' stacks in host is like bellow:
+
+[<ffffffffa07089b5>] kvm_vcpu_block+0x65/0xa0 [kvm]
+[<ffffffffa071c7c1>] __vcpu_run+0xd1/0x260 [kvm]
+[<ffffffffa071d508>] kvm_arch_vcpu_ioctl_run+0x68/0x1a0 [kvm]
+[<ffffffffa0709cee>] kvm_vcpu_ioctl+0x38e/0x580 [kvm]
+[<ffffffff8116be8b>] do_vfs_ioctl+0x8b/0x3b0
+[<ffffffff8116c251>] sys_ioctl+0xa1/0xb0
+[<ffffffff81468092>] system_call_fastpath+0x16/0x1b
+[<00002ab9fe1f99a7>] 0x2ab9fe1f99a7
+[<ffffffffffffffff>] 0xffffffffffffffff
+
+We looked into the kernel codes that could leading to the above 'Stuck'
+warning,
+in current upstream there isn't any printk(...Stuck...) left since that code 
+path
+has been reworked.
+I've often seen this on over-committed host during guest CPUs up/down torture 
+test.
+Could you update guest kernel to upstream and see if issue reproduces?
+Hmm, Unfortunately, it is very hard to reproduce, and we are still trying to 
+reproduce it.
+
+For your test case, is it a kernel bug?
+Or is there any related patch could solve your test problem been merged into
+upstream ?
+I don't remember all prerequisite patches but you should be able to find
+http://marc.info/?l=linux-kernel&m=140326703108009&w=2
+"x86/smpboot: Initialize secondary CPU only if master CPU will wait for it"
+and then look for dependencies.
+Er, we have investigated this patch, and it is not related to our problem, :)
+
+Thanks.
+Thanks,
+zhanghailiang
+and found that the only possible is the emulation of 'cpuid' instruct in
+kvm/qemu has something wrong.
+But since we can’t reproduce this problem, we are not quite sure.
+Is there any possible that the cupid emulation in kvm/qemu has some bug ?
+Can you explain the relationship to the cpuid emulation?  What do the
+traces say about vcpus 1 and 7?
+OK, we searched the VM's kernel codes with the 'Stuck' message, and  it is 
+located in
+do_boot_cpu(). It's in BSP context, the call process is:
+BSP executes start_kernel() -> smp_init() -> smp_boot_cpus() -> do_boot_cpu() 
+-> wakeup_secondary_via_INIT() to trigger APs.
+It will wait 5s for APs to startup, if some AP not startup normally, it will 
+print 'CPU%d Stuck' or 'CPU%d: Not responding'.
+
+If it prints 'Stuck', it means the AP has received the SIPI interrupt and 
+begins to execute the code
+'ENTRY(trampoline_data)' (trampoline_64.S) , but be stuck in some places before 
+smp_callin()(smpboot.c).
+The follow is the starup process of BSP and AP.
+BSP:
+start_kernel()
+     ->smp_init()
+        ->smp_boot_cpus()
+          ->do_boot_cpu()
+              ->start_ip = trampoline_address(); //set the address that AP will 
+go to execute
+              ->wakeup_secondary_cpu_via_init(); // kick the secondary CPU
+              ->for (timeout = 0; timeout < 50000; timeout++)
+                  if (cpumask_test_cpu(cpu, cpu_callin_mask)) break;// check if 
+AP startup or not
+
+APs:
+ENTRY(trampoline_data) (trampoline_64.S)
+         ->ENTRY(secondary_startup_64) (head_64.S)
+            ->start_secondary() (smpboot.c)
+               ->cpu_init();
+               ->smp_callin();
+                   ->cpumask_set_cpu(cpuid, cpu_callin_mask); ->Note: if AP 
+comes here, the BSP will not prints the error message.
+
+   From above call process, we can be sure that, the AP has been stuck between 
+trampoline_data and the cpumask_set_cpu() in
+smp_callin(), we look through these codes path carefully, and only found a 
+'hlt' instruct that could block the process.
+It is located in trampoline_data():
+
+ENTRY(trampoline_data)
+           ...
+
+        call    verify_cpu              # Verify the cpu supports long mode
+        testl   %eax, %eax              # Check for return code
+        jnz     no_longmode
+
+           ...
+
+no_longmode:
+        hlt
+        jmp no_longmode
+
+For the process verify_cpu(),
+we can only find the 'cpuid' sensitive instruct that could lead VM exit from 
+No-root mode.
+This is why we doubt if cpuid emulation is wrong in KVM/QEMU that leading to 
+the fail in verify_cpu.
+
+   From the message in VM, we know vcpu1 and vcpu7 is something wrong.
+[    5.060042] CPU1: Stuck ??
+[   10.170815] CPU7: Stuck ??
+[   10.171648] Brought up 6 CPUs
+
+Besides, the follow is the cpus message got from host.
+80FF72F5-FF6D-E411-A8C8-000000821800:/home/fsp/hrg # virsh qemu-monitor-command 
+instance-0000000
+* CPU #0: pc=0x00007f64160c683d thread_id=68570
+     CPU #1: pc=0xffffffff810301f1 (halted) thread_id=68573
+     CPU #2: pc=0xffffffff810301e2 (halted) thread_id=68575
+     CPU #3: pc=0xffffffff810301e2 (halted) thread_id=68576
+     CPU #4: pc=0xffffffff810301e2 (halted) thread_id=68577
+     CPU #5: pc=0xffffffff810301e2 (halted) thread_id=68578
+     CPU #6: pc=0xffffffff810301e2 (halted) thread_id=68583
+     CPU #7: pc=0xffffffff810301f1 (halted) thread_id=68584
+
+Oh, i also forgot to mention in the above message that, we have bond each vCPU 
+to different physical CPU in
+host.
+
+Thanks,
+zhanghailiang
+
+
+
+
+--
+To unsubscribe from this list: send the line "unsubscribe kvm" in
+the body of a message to address@hidden
+More majordomo info at
+http://vger.kernel.org/majordomo-info.html
+.
+.
+
diff --git a/results/classifier/111/KVM/587993 b/results/classifier/111/KVM/587993
new file mode 100644
index 000000000..1642c0b00
--- /dev/null
+++ b/results/classifier/111/KVM/587993
@@ -0,0 +1,162 @@
+KVM: 0.099
+PID: 0.090
+graphic: 0.089
+device: 0.083
+permissions: 0.079
+semantic: 0.074
+other: 0.071
+socket: 0.065
+boot: 0.064
+debug: 0.063
+files: 0.060
+performance: 0.060
+network: 0.056
+vnc: 0.047
+KVM: 0.775
+debug: 0.082
+PID: 0.044
+files: 0.025
+other: 0.015
+semantic: 0.014
+device: 0.008
+performance: 0.007
+socket: 0.007
+network: 0.005
+graphic: 0.005
+boot: 0.005
+permissions: 0.004
+vnc: 0.003
+
+qemu-kvm 0.12.4+dfsg-1 from debian squeeze crashes "BUG: unable to handle kernel NULL pointer" (sym53c8xx)
+
+I use eucalyptus software (1.6.2) on debian squeeze with kvm 0.12.4+dfsg-1. Kernel 2.6.32-3-amd64. After a few days machines crash. There are no logs in host system. Guest is the same kernel and OS as host. The kvm process use 100% of cpu time. I can not even ping the guest. Here is the log from virtual machine:
+
+[ 3577.816666] sd 0:0:0:0: [sda] ABORT operation started
+[ 3582.816047] sd 0:0:0:0: ABORT operation timed-out.
+[ 3582.816781] sd 0:0:0:0: [sda] ABORT operation started
+[ 3587.816649] sd 0:0:0:0: ABORT operation timed-out.
+[ 3587.817379] sd 0:0:0:0: [sda] DEVICE RESET operation started
+[ 3592.816062] sd 0:0:0:0: DEVICE RESET operation timed-out.
+[ 3592.816882] sd 0:0:0:0: [sda] BUS RESET operation started
+[ 3592.820056] sym0: SCSI BUS reset detected.
+[ 3592.831538] sym0: SCSI BUS has been reset.
+[ 3592.831968] BUG: unable to handle kernel NULL pointer dereference at 0000000000000358
+[ 3592.832003] IP: [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx]
+[ 3592.832003] PGD 5f73e067 PUD 5fa53067 PMD 0 
+[ 3592.832003] Oops: 0000 [#1] SMP 
+[ 3592.832003] last sysfs file: /sys/devices/pci0000:00/0000:00:05.0/host0/target0:0:0/0:0:0:0/vendor
+[ 3592.832003] CPU 0 
+[ 3592.832003] Modules linked in: dm_mod openafs(P) ext2 snd_pcsp snd_pcm snd_timer serio_raw i2c_piix4 snd virtio_balloon evdev i2c_core soundcore psmouse button processor snd_page_alloc ext3 jbd mbcache sd_mod crc_t10dif ata_generic libata ide_pci_generic sym53c8xx scsi_transport_spi thermal piix uhci_hcd ehci_hcd floppy thermal_sys scsi_mod virtio_pci virtio_ring virtio e1000 ide_core usbcore nls_base [last unloaded: scsi_wait_scan]
+[ 3592.832003] Pid: 193, comm: scsi_eh_0 Tainted: P           2.6.32-3-amd64 #1 Bochs
+[ 3592.832003] RIP: 0010:[<ffffffffa01147c4>]  [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx]
+[ 3592.832003] RSP: 0018:ffff880001803cb0  EFLAGS: 00010287
+[ 3592.832003] RAX: 000000000000000a RBX: 000000000000000b RCX: 000000005f410090
+[ 3592.832003] RDX: 0000000000000000 RSI: ffff88005c450800 RDI: ffffc90000a5e006
+[ 3592.832003] RBP: ffff88005f410000 R08: 0000000000000000 R09: 0000000000000000
+[ 3592.832003] R10: 000000000000003a R11: ffffffff813b871e R12: ffff88005f410090
+[ 3592.832003] R13: 0000000000000084 R14: 0000000000000000 R15: 0000000000000001
+[ 3592.832003] FS:  0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000
+[ 3592.832003] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
+[ 3592.832003] CR2: 0000000000000358 CR3: 000000005e269000 CR4: 00000000000006f0
+[ 3592.832003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 3592.832003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+[ 3592.832003] Process scsi_eh_0 (pid: 193, threadinfo ffff88005f6fa000, task ffff88005f697880)
+[ 3592.832003] Stack:
+[ 3592.832003]  ffff88005f3fd000 0000000000000000 0000000000000130 0000000000000000
+[ 3592.832003] <0> ffff88005f407710 ffffc90000a64710 ffffffffffffff10 ffffffff81195301
+[ 3592.832003] <0> 0000000000000010 0000000000010212 ffff880001803d18 0000000000000018
+[ 3592.832003] Call Trace:
+[ 3592.832003]  <IRQ> 
+[ 3592.832003]  [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19
+[ 3592.832003]  [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx]
+[ 3592.832003]  [<ffffffff8103fea0>] ? update_curr+0xa6/0x147
+[ 3592.832003]  [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx]
+[ 3592.832003]  [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126
+[ 3592.832003]  [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5
+[ 3592.832003]  [<ffffffff81013957>] ? handle_irq+0x17/0x1d
+[ 3592.832003]  [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6
+[ 3592.832003]  [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
+[ 3592.832003]  [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f
+[ 3592.832003]  [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95
+[ 3592.832003]  [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
+[ 3592.832003]  [<ffffffff81013903>] ? do_softirq+0x3f/0x7c
+[ 3592.832003]  [<ffffffff810537e1>] ? irq_exit+0x36/0x76
+[ 3592.832003]  [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95
+[ 3592.832003]  [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
+[ 3592.832003]  <EOI> 
+[ 3592.832003]  [<ffffffff8118e009>] ? delay_tsc+0x0/0x73
+[ 3592.832003]  [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx]
+[ 3592.832003]  [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod]
+[ 3592.832003]  [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod]
+[ 3592.832003]  [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod]
+[ 3592.832003]  [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod]
+[ 3592.832003]  [<ffffffff81064789>] ? kthread+0x79/0x81
+[ 3592.832003]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
+[ 3592.832003]  [<ffffffff81064710>] ? kthread+0x0/0x81
+[ 3592.832003]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
+[ 3592.832003] Code: 48 c7 c7 82 92 11 a0 eb 63 48 8b 98 38 01 00 00 48 8d b8 28 01 00 00 e8 df d5 0f e1 48 89 da 48 89 c6 48 c7 c7 bc 92 11 a0 eb 6d <49> 8b 96 58 03 00 00 48 8b 82 80 00 00 00 48 8b a8 b0 00 00 00 
+[ 3592.832003] RIP  [<ffffffffa01147c4>] sym_int_sir+0x62f/0x14e0 [sym53c8xx]
+[ 3592.832003]  RSP <ffff880001803cb0>
+[ 3592.832003] CR2: 0000000000000358
+[ 3592.867935] ---[ end trace 06f90ebbdbd172ee ]---
+[ 3592.868360] Kernel panic - not syncing: Fatal exception in interrupt
+[ 3592.868906] Pid: 193, comm: scsi_eh_0 Tainted: P      D    2.6.32-3-amd64 #1
+[ 3592.869511] Call Trace:
+[ 3592.869727]  <IRQ>  [<ffffffff812ed349>] ? panic+0x86/0x141
+[ 3592.870225]  [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
+[ 3592.870778]  [<ffffffff811afbdc>] ? dummycon_dummy+0x0/0x3
+[ 3592.871250]  [<ffffffff81014a37>] ? oops_end+0x64/0xb4
+[ 3592.871694]  [<ffffffff81014a7a>] ? oops_end+0xa7/0xb4
+[ 3592.872150]  [<ffffffff810322b8>] ? no_context+0x1e9/0x1f8
+[ 3592.872626]  [<ffffffff8103246d>] ? __bad_area_nosemaphore+0x1a6/0x1ca
+[ 3592.873185]  [<ffffffff8106807c>] ? up+0xe/0x36
+[ 3592.873576]  [<ffffffff8104e219>] ? release_console_sem+0x17e/0x1af
+[ 3592.874125]  [<ffffffff81024d72>] ? lapic_next_event+0x18/0x1d
+[ 3592.874642]  [<ffffffff812ef595>] ? page_fault+0x25/0x30
+[ 3592.875103]  [<ffffffffa01147c4>] ? sym_int_sir+0x62f/0x14e0 [sym53c8xx]
+[ 3592.875678]  [<ffffffff81195301>] ? __memcpy_toio+0x9/0x19
+[ 3592.876162]  [<ffffffffa01164ed>] ? sym_interrupt+0x46c/0x6a3 [sym53c8xx]
+[ 3592.876748]  [<ffffffff8103fea0>] ? update_curr+0xa6/0x147
+[ 3592.877224]  [<ffffffffa010fbde>] ? sym53c8xx_intr+0x43/0x6a [sym53c8xx]
+[ 3592.877800]  [<ffffffff81093bfc>] ? handle_IRQ_event+0x58/0x126
+[ 3592.878319]  [<ffffffff810954e2>] ? handle_fasteoi_irq+0x7d/0xb5
+[ 3592.878848]  [<ffffffff81013957>] ? handle_irq+0x17/0x1d
+[ 3592.879305]  [<ffffffff81012fb1>] ? do_IRQ+0x57/0xb6
+[ 3592.879744]  [<ffffffff810114d3>] ? ret_from_intr+0x0/0x11
+[ 3592.880237]  [<ffffffff81053903>] ? __do_softirq+0x6e/0x19f
+[ 3592.880723]  [<ffffffff8106fa87>] ? tick_dev_program_event+0x2d/0x95
+[ 3592.881284]  [<ffffffff81011cac>] ? call_softirq+0x1c/0x30
+[ 3592.881762]  [<ffffffff81013903>] ? do_softirq+0x3f/0x7c
+[ 3592.882230]  [<ffffffff810537e1>] ? irq_exit+0x36/0x76
+[ 3592.882691]  [<ffffffff81025837>] ? smp_apic_timer_interrupt+0x87/0x95
+[ 3592.883258]  [<ffffffff81011673>] ? apic_timer_interrupt+0x13/0x20
+[ 3592.883795]  <EOI>  [<ffffffff8118e009>] ? delay_tsc+0x0/0x73
+[ 3592.884319]  [<ffffffffa010f900>] ? sym_eh_handler+0x22e/0x2e2 [sym53c8xx]
+[ 3592.884917]  [<ffffffffa008e5de>] ? scsi_try_bus_reset+0x50/0xd9 [scsi_mod]
+[ 3592.885522]  [<ffffffffa008f565>] ? scsi_eh_ready_devs+0x50c/0x781 [scsi_mod]
+[ 3592.886152]  [<ffffffffa008fd6b>] ? scsi_error_handler+0x3c1/0x5b5 [scsi_mod]
+[ 3592.886789]  [<ffffffffa008f9aa>] ? scsi_error_handler+0x0/0x5b5 [scsi_mod]
+[ 3592.887398]  [<ffffffff81064789>] ? kthread+0x79/0x81
+[ 3592.887836]  [<ffffffff81011baa>] ? child_rip+0xa/0x20
+[ 3592.888290]  [<ffffffff81064710>] ? kthread+0x0/0x81
+[ 3592.888721]  [<ffffffff81011ba0>] ? child_rip+0x0/0x20
+
+Unfortunatelly I have no idea how to reproduce the problem.
+
+If you can recreate the issue, please update the bug report with information about to how recreate the problem.
+
+Looks like the SCSI driver is causing problems. QEMU's SCSI emulation is known to be broken, please use IDE
+or virtio-blk.
+
+Jes
+
+
+Looks a duplicate of https://sourceforge.net/tracker/index.php?func=detail&aid=2042889&group_id=180599&atid=893831
+
+Closed the SF bug, lets focus on this issue here.
+
+Jes
+
+
+QEMU 0.12 is way outdated nowadays, so I assume this problem has been fixed sometime in the last years... so I'm closing this ticket now. If you still have problems with the latest version of QEMU, please feel free to open this bug again.
+
diff --git a/results/classifier/111/KVM/642304 b/results/classifier/111/KVM/642304
new file mode 100644
index 000000000..80262ecbe
--- /dev/null
+++ b/results/classifier/111/KVM/642304
@@ -0,0 +1,75 @@
+KVM: 0.199
+other: 0.143
+semantic: 0.127
+PID: 0.101
+device: 0.097
+graphic: 0.071
+boot: 0.057
+vnc: 0.041
+socket: 0.034
+permissions: 0.033
+performance: 0.026
+debug: 0.026
+files: 0.024
+network: 0.022
+KVM: 0.550
+semantic: 0.096
+other: 0.045
+debug: 0.045
+boot: 0.043
+network: 0.043
+files: 0.038
+PID: 0.033
+socket: 0.027
+device: 0.021
+vnc: 0.021
+performance: 0.015
+graphic: 0.013
+permissions: 0.009
+
+Solaris/x86 v10 hangs under KVM
+
+Solaris/x86 10 guest hangs when running under KVM with the message "Running Configuration Assistant".  It runs fine when -enable-kvm isn't given as a command option.
+
+Host OS:  Linux/x86_64
+Guest OS: Solaris/x86
+Command Line: qemu -hda solaris.img -m 192 -boot c -enable-kvm
+Build Configure:  ./configure --enable-linux-aio --enable-io-thread --enable-kvm
+GIT commit: 58aebb946acff82c62383f350cab593e55cc13dc
+
+Your bug report doesn't tell us anything about the host system (AMD, Intel, which CPU model etc),
+nor which version of KVM you are running, which distro etc?
+
+Did it work with older versions of qemu-kvm?
+
+Which version of Solaris/x86 (pointer to version preferably)
+
+Please provide appropriate information if you want a chance that anyone will look at this.
+
+Jes
+
+
+1) Host CPU: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
+2) KVM doesn't have specific "versions" on Debian. The kernel is built with KVM included. The kernel is version 2.6.32-5
+3) Debian 5.0
+4) No - it's never worked for me, but I've only just got around to posting the bug
+5) 10
+
+
+
+As I mentioned in email reply, _every_ package in almost every distribution (the ones I know anyway), Debian included, has a version number attached.
+
+The git commit ID (58aebb946acff82c62383f350cab593e55cc13dc) appears to be in qemu or qemu-kvm git tree (it's found on both), somewhere past 0.13.0-rc0 (dated Sep 18 2010).  But from this commit ID it's impossible to tell if you're using qemu or qemu-kvm.
+
+What are you using --enable-io-thread for?
+
+
+
+
+
+1: If you can give instructions on how to get a version number for kvm on Debian I'll follow them.  "dpkg -l | fgrep kvm" lists nothing.
+2: I'm using the qemu git tree.  
+3: Why are you asking?  Are you saying that enable-io-thread is broken with --enable-kvm?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/KVM/712337 b/results/classifier/111/KVM/712337
new file mode 100644
index 000000000..efbba4f59
--- /dev/null
+++ b/results/classifier/111/KVM/712337
@@ -0,0 +1,78 @@
+KVM: 0.123
+other: 0.097
+semantic: 0.086
+vnc: 0.086
+device: 0.077
+PID: 0.076
+files: 0.071
+graphic: 0.064
+performance: 0.063
+permissions: 0.058
+debug: 0.050
+network: 0.050
+boot: 0.050
+socket: 0.049
+KVM: 0.669
+debug: 0.161
+PID: 0.042
+files: 0.035
+other: 0.017
+semantic: 0.013
+network: 0.013
+device: 0.012
+performance: 0.009
+socket: 0.007
+boot: 0.007
+graphic: 0.006
+vnc: 0.005
+permissions: 0.004
+
+connecthon basic test5 failed with qemu 0.14 on Virtfs path in guest
+
+connecthon basic test named test5 is failing with bigfile write failed bad address on .L passthru and .L mapped Virtfs path in guest. with fedora12
+
+Bug is with latest qemu-0.14.0-rc0
+
+connecthon tarball /root/project_CI/client/tests/connecthon/cthon04.tgz
+02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| [stderr] 	./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address
+02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 ERROR| Test failed: Command <./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55> failed, rc=1, Command returned non-zero exit status
+02/03 08:55:09 INFO |kvm_subpro:0880| * Command: 
+02/03 08:55:09 INFO |kvm_subpro:0880|     ./runtests -N 100 -b -t /root/mount3/test2011-02-0311:55
+02/03 08:55:09 INFO |kvm_subpro:0880| Exit status: 1
+02/03 08:55:09 INFO |kvm_subpro:0880| Duration: 0
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| stdout:
+02/03 08:55:09 INFO |kvm_subpro:0880| ... Pass 1 ...
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| Starting BASIC tests: test directory /root/mount3/test2011-02-0311:55 (arg: -t)
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| ./test1: File and directory creation test
+02/03 08:55:09 INFO |kvm_subpro:0880| 	created 155 files 62 directories 5 levels deep in 0.6  seconds
+02/03 08:55:09 INFO |kvm_subpro:0880| 	./test1 ok.
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| ./test2: File and directory removal test
+02/03 08:55:09 INFO |kvm_subpro:0880| 	removed 155 files 62 directories 5 levels deep in 0.4  seconds
+02/03 08:55:09 INFO |kvm_subpro:0880| 	./test2 ok.
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| ./test3: lookups across mount point
+02/03 08:55:09 INFO |kvm_subpro:0880| 	500 getcwd and stat calls in 0.0  seconds
+02/03 08:55:09 INFO |kvm_subpro:0880| 	./test3 ok.
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| ./test4: setattr, getattr, and lookup
+02/03 08:55:09 INFO |kvm_subpro:0880| 	1000 chmods and stats on 10 files in 0.24 seconds
+02/03 08:55:09 INFO |kvm_subpro:0880| 	./test4 ok.
+02/03 08:55:09 INFO |kvm_subpro:0880| 
+02/03 08:55:09 INFO |kvm_subpro:0880| ./test5: read and write
+02/03 08:55:09 INFO |kvm_subpro:0880| basic tests failed
+02/03 08:55:09 INFO |kvm_subpro:0880| stderr:
+02/03 08:55:09 INFO |kvm_subpro:0880| 	./test5: (/root/mount3/test2011-02-0311:55) 'bigfile' write failed : Bad address
+02/03 08:55:09 INFO |kvm_subpro:0880| 11:55:08 INFO | Test finished after 1 iterations.
+02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 ERROR| child process failed
+02/03 08:55:10 INFO |kvm_subpro:0880| 11:55:09 INFO | 		FAIL	connecthon.itera-pass-dotl-100-test-bt	connecthon.itera-pass-dotl-100-test-bt	timestamp=1296752109
+
+This defect is not seen with latest qemu. 
+
+According to comment #1, the problem does not occur anymore with the latest version of QEMU, but you've set the status to "In Progress" instead of closing it ... so can we close this ticket nowadays or is there still something left to do?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/KVM/816860 b/results/classifier/111/KVM/816860
new file mode 100644
index 000000000..dba5bc98d
--- /dev/null
+++ b/results/classifier/111/KVM/816860
@@ -0,0 +1,60 @@
+KVM: 0.179
+semantic: 0.136
+device: 0.111
+performance: 0.108
+PID: 0.084
+other: 0.081
+vnc: 0.059
+graphic: 0.043
+network: 0.041
+socket: 0.034
+files: 0.032
+debug: 0.031
+boot: 0.031
+permissions: 0.030
+KVM: 0.766
+debug: 0.035
+performance: 0.030
+PID: 0.028
+network: 0.022
+socket: 0.021
+other: 0.020
+files: 0.018
+device: 0.018
+boot: 0.013
+semantic: 0.010
+vnc: 0.009
+graphic: 0.004
+permissions: 0.004
+
+Guest machine freezes when NFS mount goes offline
+
+I have a virtual KVM machine that has 2 CDROM units with ISOs mounted from a NFS mount point. When NFS server goes offline the virtual machine blocks completely instead of throwing read errors for the CDROM device.
+
+Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0)
+KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel)
+Guest: Windows 7 professional SP 1
+
+On Wed, Jul 27, 2011 at 10:09 AM, Igor Blanco <email address hidden> wrote:
+> Public bug reported:
+>
+> I have a virtual KVM machine that has 2 CDROM units with ISOs mounted
+> from a NFS mount point. When NFS server goes offline the virtual machine
+> blocks completely instead of throwing read errors for the CDROM device.
+>
+> Host: Proxmox VE 1.8-11 (Debian GNU/Linux 5.0)
+> KVM commandline version: QEMU emulator version 0.14.1 (qemu-kvm-devel)
+> Guest: Windows 7 professional SP 1
+
+Thanks for reporting this.  There are instances where QEMU performs
+blocking operations in a thread that will prevent the guest from
+running.  I suspect you are hitting this case and refactoring work
+needs to be done to ensure that QEMU threads never block.
+
+Stefan
+
+
+Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/111/KVM/939443 b/results/classifier/111/KVM/939443
new file mode 100644
index 000000000..25306df56
--- /dev/null
+++ b/results/classifier/111/KVM/939443
@@ -0,0 +1,36 @@
+KVM: 0.284
+semantic: 0.161
+device: 0.148
+graphic: 0.066
+other: 0.065
+performance: 0.054
+permissions: 0.042
+vnc: 0.033
+network: 0.031
+socket: 0.026
+files: 0.025
+boot: 0.024
+PID: 0.023
+debug: 0.017
+KVM: 0.751
+other: 0.052
+files: 0.039
+semantic: 0.033
+graphic: 0.028
+device: 0.020
+boot: 0.014
+debug: 0.012
+performance: 0.010
+permissions: 0.010
+PID: 0.009
+network: 0.009
+socket: 0.008
+vnc: 0.004
+
+qemu-system-x86_64 can no support 1366x768
+
+My laptop resolution is 1366x768, but can not support at -vga vmware the -vga std.
+
+$ kvm -version
+QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
+