13 files changed, 597 insertions, 0 deletions
diff --git a/results/classifier/108/other/101 b/results/classifier/108/other/101
new file mode 100644
index 000000000..49cd756d6
--- /dev/null
+++ b/results/classifier/108/other/101
@@ -0,0 +1,16 @@
+device: 0.843
+performance: 0.740
+KVM: 0.615
+vnc: 0.611
+graphic: 0.501
+network: 0.469
+PID: 0.433
+boot: 0.394
+socket: 0.295
+semantic: 0.292
+permissions: 0.191
+files: 0.156
+other: 0.050
+debug: 0.017
+
+Running a virtual machine on a Haswell system produces machine check events
diff --git a/results/classifier/108/other/1010484 b/results/classifier/108/other/1010484
new file mode 100644
index 000000000..d7004124c
--- /dev/null
+++ b/results/classifier/108/other/1010484
@@ -0,0 +1,40 @@
+network: 0.774
+device: 0.707
+socket: 0.645
+graphic: 0.612
+semantic: 0.568
+vnc: 0.552
+files: 0.515
+other: 0.430
+permissions: 0.372
+PID: 0.358
+boot: 0.332
+performance: 0.313
+debug: 0.218
+KVM: 0.174
+
+slirp to accept non-local dns server
+
+current version of slirp doesn't allow feeded dns address to be outside of given network.
+in many scenarios you need to provide dns server that isn't local.
+
+this simple patch removes checking for if dns server isn't in local subnet.
+
+
+
+The feature makes sense and would be acceptable. But please
+- post a patch on qemu-devel, following http://wiki.qemu.org/Contribute/SubmitAPatch
+- reject non-local DNS servers if restrict=on is selected
+
+Thanks!
+
+ping
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+A patch has been sent to the list now:
+https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg00180.html
+
+Fixed here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=120b721f5b590393971673
+... and released with QEMU v4.2
+
diff --git a/results/classifier/108/other/1011 b/results/classifier/108/other/1011
new file mode 100644
index 000000000..1f712fbf4
--- /dev/null
+++ b/results/classifier/108/other/1011
@@ -0,0 +1,36 @@
+device: 0.789
+graphic: 0.772
+vnc: 0.706
+semantic: 0.601
+network: 0.400
+performance: 0.364
+socket: 0.356
+files: 0.347
+PID: 0.344
+debug: 0.332
+permissions: 0.247
+boot: 0.201
+other: 0.125
+KVM: 0.061
+
+hvf: RDTSCP capability not passed to guests
+Description of problem:
+
+Steps to reproduce:
+1. Run:
+wget https://dl-cdn.alpinelinux.org/alpine/v3.15/releases/x86/alpine-standard-3.15.4-x86.iso
+./qemu-system-x86_64 -cpu host,+rdtscp -machine q35,accel=hvf -m 512 -cdrom ./alpine-standard-3.15.4-x86.iso
+
+2. login as "root"
+3. type
+
+cat /etc/cpuinfo | grep rdtscp
+
+Expected result: cpu flag lines including rdtscp
+Actual result: empty, with:
+
+warning: host doesn't support requested feature: CPUID.80000001H:EDX.rdtscp [bit 27]
+Additional information:
+This patch apparently resolves the issue according to my tests:
+
+https://lore.kernel.org/qemu-devel/20211101054836.21471-1-dirty@apple.com/
diff --git a/results/classifier/108/other/1012 b/results/classifier/108/other/1012
new file mode 100644
index 000000000..2b7092371
--- /dev/null
+++ b/results/classifier/108/other/1012
@@ -0,0 +1,56 @@
+other: 0.927
+KVM: 0.858
+permissions: 0.849
+graphic: 0.842
+performance: 0.806
+debug: 0.805
+network: 0.804
+vnc: 0.801
+device: 0.774
+files: 0.743
+boot: 0.739
+semantic: 0.729
+socket: 0.678
+PID: 0.645
+
+9p: newfstatat behaves differently than fstat causing ENOENT for here-documents
+Description of problem:
+After recent gnulib and coreutils update bash here-documents stopped to work producing `cat: -: No such file or directory` error.
+Steps to reproduce:
+1. I have file `a` with:
+```
+cat <<EOF
+x
+EOF
+```
+2. User visible error inside VM:
+```
+root@x86_64:~# grep 9p /proc/mounts
+/dev/root / 9p rw,dirsync,relatime,loose,access=any,msize=262144,trans=virtio 0 0
+root@x86_64:~# bash a
+cat: -: No such file or directory
+```
+3. `strace -fyv bash a` shows:
+```
+  [pid   291] newfstatat(1</dev/ttyS0>, "", {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */,
+st_atime_nsec=969984203, st_mtime=1651577553 /* 2022-05-03T11:32:33.969984203+0000 */, st_mtime_nsec=969984203, st_ctime=1651577069 /* 2022-05-03T11:24:29.969984203+0000 */, st_ctime_nsec=969984203}, AT_EMPTY_PATH) = 0
+  [pid   291] newfstatat(0</usr/src/tmp/sh-thd.420UUL (deleted)>, "", 0x7ffd1b96a3a0, AT_EMPTY_PATH) = -1 ENOENT (No such file or directory)
+  [pid   291] write(2</dev/ttyS0>, "cat: ", 5cat: ) = 5
+  [pid   291] write(2</dev/ttyS0>, "-", 1-) = 1
+  [pid   291] write(2</dev/ttyS0>, ": No such file or directory", 27: No such file or directory) = 27
+  [pid   291] write(2</dev/ttyS0>, "\n", 1
+```
+Additional information:
+In comparison, `strace -fyv bash a` in the old system w/o gnulib/coreutils update shows:
+```
+  [pid   283] fstat(1</dev/ttyS0>, {st_dev=makedev(0, 0x5), st_ino=85, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_rdev=makedev(0x4, 0x40), st_atime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_atime_nsec=238343204,
+st_mtime=1651577784 /* 2022-05-03T11:36:24.238343204+0000 */, st_mtime_nsec=238343204, st_ctime=1651577774 /* 2022-05-03T11:36:14.238343204+0000 */, st_ctime_nsec=238343204}) = 0
+  [pid   283] fstat(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, {st_dev=makedev(0, 0x14), st_ino=17926519, st_mode=S_IFREG|0600, st_nlink=0, st_uid=502, st_gid=502, st_blksize=262144, st_blocks=0, st_size=2, st_atime=1651577786 /* 2022-05-03T11:36:26.295302472+0000 */,
+st_atime_nsec=295302472, st_mtime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_mtime_nsec=0, st_ctime=1651577785 /* 2022-05-03T11:36:25+0000 */, st_ctime_nsec=0}) = 0
+  [pid   283] fadvise64(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
+  [pid   283] mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f715f13e000
+  [pid   283] read(0</usr/src/tmp/sh-thd.3xuISC (deleted)>, "x\n", 262144) = 2
+  [pid   283] write(1</dev/ttyS0>, "x\n", 2x
+```
+
+So it seems that they started to use `newfstatat` instead of `fstat`, which behaves differently.
diff --git a/results/classifier/108/other/1012023 b/results/classifier/108/other/1012023
new file mode 100644
index 000000000..5247268f4
--- /dev/null
+++ b/results/classifier/108/other/1012023
@@ -0,0 +1,113 @@
+other: 0.862
+permissions: 0.840
+graphic: 0.825
+vnc: 0.775
+performance: 0.757
+debug: 0.752
+device: 0.739
+PID: 0.733
+files: 0.731
+semantic: 0.724
+KVM: 0.716
+boot: 0.704
+network: 0.674
+socket: 0.579
+
+Windows 7 bluescreen STOP: 00000005D
+
+Hello, with installed windows, or with install cd I have a blue screen (crash) after the first windows logo, see the screenshot.
+
+Thanks to fix it.
+
+
+
+This is a wonderful bugreport.  With no information whatsoever.
+
+Can we close it with "works for me" resolution already? ;)
+
+Seriously, please provide at least version of qemu and kernel you're using, together with complete qemu command line.
+
+https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/956374 - the same STOP code, fwiw.
+
+Last version of QEMU (1.0.1 -> I have try other minor version, 1.0), I have try with multiple kernel (3.4, 3.5), no dmesg info.
+
+Hardware info:
+
+Intel(R) Core(TM) i5 CPU         750  @ 2.67GHz
+
+00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11)
+00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 1 (rev 11)
+00:05.0 PCI bridge: Intel Corporation Core Processor PCI Express Root Port 3 (rev 11)
+00:08.0 System peripheral: Intel Corporation Core Processor System Management Registers (rev 11)
+00:08.1 System peripheral: Intel Corporation Core Processor Semaphore and Scratchpad Registers (rev 11)
+00:08.2 System peripheral: Intel Corporation Core Processor System Control and Status Registers (rev 11)
+00:08.3 System peripheral: Intel Corporation Core Processor Miscellaneous Registers (rev 11)
+00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11)
+00:10.1 System peripheral: Intel Corporation Core Processor QPI Routing and Protocol Registers (rev 11)
+00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1a.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1a.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1a.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
+00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05)
+00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05)
+00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05)
+00:1c.6 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 7 (rev 05)
+00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1d.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1d.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1d.3 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB Universal Host Controller (rev 05)
+00:1d.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
+00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5)
+00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 05)
+00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05)
+00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05)
+01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Cedar PRO [Radeon HD 5450]
+01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series]
+02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller (rev 11)
+04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
+05:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
+06:00.0 SATA controller: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03)
+06:00.1 IDE interface: JMicron Technology Corp. JMB363 SATA/IDE Controller (rev 03)
+3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-Core Registers (rev 04)
+3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 04)
+3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04)
+3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04)
+3f:03.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller (rev 04)
+3f:03.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Target Address Decoder (rev 04)
+3f:03.4 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Test Registers (rev 04)
+3f:04.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Control Registers (rev 04)
+3f:04.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Address Registers (rev 04)
+3f:04.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Rank Registers (rev 04)
+3f:04.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 0 Thermal Control Registers (rev 04)
+3f:05.0 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Control Registers (rev 04)
+3f:05.1 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Address Registers (rev 04)
+3f:05.2 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Rank Registers (rev 04)
+3f:05.3 Host bridge: Intel Corporation Core Processor Integrated Memory Controller Channel 1 Thermal Control Registers (rev 04)
+Bus 004 Device 002: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
+Bus 009 Device 002: ID 1bcf:0007 Sunplus Innovation Technology Inc. Optical Mouse
+Bus 009 Device 003: ID 0a81:0101 Chesen Electronics Corp. Keyboard
+Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
+Bus 010 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+Bus 011 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+
+
+Can we close this with "works for me" already?
+
+Can you FINALLY provide the command line?
+
+Thanks.
+
+/usr/bin/qemu-system-x86_64 -drive file=hdd.img,if=virtio,cache=unsafe -k fr -alt-grab -m 1024 -vga vmware -net nic,vlan=0,model=virtio -net user
+
+But bug will ALL cli and options.
+
+Looks like this is a duplicate of https://bugs.launchpad.net/qemu/+bug/921208 ... so closing this ticket here.
+
diff --git a/results/classifier/108/other/1013 b/results/classifier/108/other/1013
new file mode 100644
index 000000000..ef07c72f7
--- /dev/null
+++ b/results/classifier/108/other/1013
@@ -0,0 +1,16 @@
+device: 0.834
+network: 0.624
+socket: 0.466
+graphic: 0.456
+boot: 0.394
+permissions: 0.388
+PID: 0.312
+vnc: 0.303
+performance: 0.257
+other: 0.245
+semantic: 0.216
+debug: 0.208
+files: 0.092
+KVM: 0.004
+
+[Bug] user input is not sanitized in QEMU_Elf_init and can lead to buffer overflow
diff --git a/results/classifier/108/other/1013714 b/results/classifier/108/other/1013714
new file mode 100644
index 000000000..cf78b5558
--- /dev/null
+++ b/results/classifier/108/other/1013714
@@ -0,0 +1,68 @@
+semantic: 0.859
+permissions: 0.835
+other: 0.828
+debug: 0.826
+graphic: 0.817
+device: 0.801
+vnc: 0.793
+KVM: 0.790
+performance: 0.762
+PID: 0.759
+network: 0.748
+boot: 0.741
+files: 0.723
+socket: 0.538
+
+Data corruption after block migration (LV->LV)
+
+We quite frequently use the live block migration feature to move VM's between nodes without downtime. These sometimes result in data corruption on the receiving end. It only happens if the VM is actually doing I/O (doesn't have to be all that much to trigger the issue).
+
+We use logical volumes and each VM has two disks.  We use cache=none for all VM disks.
+
+All guests use virtio (a mix of various Linux distro's and Windows 2008R2).
+
+We currently have two stacks in use and have seen the issue on both of them:
+
+Fedora - qemu-kvm 0.13
+Scientific Linux 6.2 (RHEL derived) - qemu-kvm package 0.12.1.2
+
+Even though we don't run the most recent versions of KVM I highly suspect this issue is still unreported and that filing a bug is therefore appropriate. (There doesn't seem to be any similar bug report in launchpad or RedHat's bugzilla and nothing related in change logs, release notes and  git commit logs.)
+
+I have no idea where to look or where to start debugging this issue, but if there is any way I can provide useful debug information please let me know.
+
+Hi, I suggest that you try a newer version. There were several fixes that I think went only in 0.14, in particular commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e, commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e, commit 62155e2b51e3c282ddc30adbb6d7b8d3bb7c386e. RHEL6.2 doesn't have them. With the fixes, it's quite less likely that live block migration will eat your data.
+
+However, we were also thinking of deprecating block migration, so we are interesting of hearing about your setup. The replacement would be more powerful (it would allow migrating storage separately from the VM), more efficient (storage and RAM streams would run in parallel on different TCP ports), and easier for us to test and maintain.
+
+However, it would be more complicated to set the new mechanism up for migration without shared storage. This is what live block migration does, and it sounds like your usecase requires migration without shared storage. Likely, a true replacement of live block migration would not be ready in time for the next release (1.2), hence its removal would also be delayed.
+
+Hello Paolo,
+
+Thank you for your quick response!
+
+Did you intend to mention 3 different commits or did you accidentally paste the same commit thrice? ;) I came across that commit but somehow thought it was already included in 0.13. Thanks!
+
+We're of course in no position to ask, but I'll do it anyway:  Would you be in a position to add patches for these commits to the qemu-kvm package for RHEL6 (assuming they apply at all)? Or perhaps ask one of the RH package maintainers to do so?  We'd be very grateful!
+
+A little bit of background (our use case for using live block migration): We are an ISP and provide virtual private servers on KVM. 
+
+The way we see it traditional centralized shared storage introduces one big, expensive and complicated SPOF into a VM platform. 
+
+We actually have no problems dealing with the limitations of local storage. For example, we have automated (offline) VM migrations to other hosts when customers need to upgrade and the current host doesn't have enough resources. It would be great if live block migration would be stable enough to do this online to reduce downtime for customers.
+
+We sometimes use live block migration to reduce the server load by migrating off a busy VM. It doesn't really matter if the migration takes a while to complete. We also use it to migrate all VM's off a host in case the hardware is being retired or we need to reinstall.
+
+Live block migration is just not very useful for generic system maintenance, like a reboot for a kernel or firmware update. In that case we simply reboot the host (and most customers don't mind that once in a while).
+
+We would appreciate it if live block migration would not be removed until its superior replacement is ready. We don't mind if it's more complex to work with, as long as it's well documented ;)
+
+Hello Paolo,
+
+We backported most of the block migration fixes from upstream to the RHEL6 qemu-kvm package ourselves and are now unable to reproduce the disk corruption problem anymore. So I guess the issues are (mostly) fixed upstream.
+
+You can close this bug, but I would still appreciate it if you could fix this in the RHEL6 package (other RH customers might appreciate that as well ;). We could even provide the patches if you like.
+
+
+
+Closing according to comment #3
+
diff --git a/results/classifier/108/other/1014 b/results/classifier/108/other/1014
new file mode 100644
index 000000000..c947a2dcc
--- /dev/null
+++ b/results/classifier/108/other/1014
@@ -0,0 +1,18 @@
+device: 0.896
+other: 0.812
+network: 0.557
+semantic: 0.506
+debug: 0.429
+graphic: 0.400
+boot: 0.340
+KVM: 0.225
+PID: 0.211
+permissions: 0.205
+performance: 0.182
+socket: 0.157
+vnc: 0.138
+files: 0.013
+
+Make -chardev, -serial and others accept stderr like they accept stdio
+Additional information:
+It's not clear what should happen when the guest tries to read from (instead of write to) the character device. On the other hand, I don't think the specific behavior matters very much.
diff --git a/results/classifier/108/other/1014099 b/results/classifier/108/other/1014099
new file mode 100644
index 000000000..8c9045add
--- /dev/null
+++ b/results/classifier/108/other/1014099
@@ -0,0 +1,43 @@
+network: 0.730
+performance: 0.581
+other: 0.483
+device: 0.479
+files: 0.478
+socket: 0.476
+graphic: 0.457
+semantic: 0.389
+permissions: 0.368
+vnc: 0.359
+boot: 0.341
+PID: 0.332
+debug: 0.307
+KVM: 0.130
+
+hw/esp.c does not properly deal with TEST_UNIT_READY in NetBSD/sparc
+
+The NetBSD ncr53c9x.c driver does a TEST_UNIT_READY command with SELATN but dma disabled sometimes (early during bus enumeration). This is fine, as the command will not produce nor consume any data, and works on real hardware.
+
+However, the qemu emulation does not allow this (for reasons I don't understand).
+
+The change below fixes the problem.
+
+
+
+Guess I understand the code now - so here is a working version - though it may be considered slightly hackish
+
+On Sat, Jun 16, 2012 at 5:50 PM, Martin Husemann <email address hidden> wrote:
+> ** Patch added: "esp.c.patch"
+>   https://bugs.launchpad.net/bugs/1014099/+attachment/3192643/+files/esp.c.patch
+
+Please see this on how to contribute patches to QEMU:
+http://wiki.qemu.org/Contribute/SubmitAPatch
+
+Stefan
+
+
+Patch removed, as it was bogus and your workflow is weird, so I'll post a better patch to the devel list
+
+Has this problem been fixed in 2012, so that we could close this ticket now? Or is there still something left to do?
+
+Yes. Just to make sure I tested qemu 2.8 against an old disk image from 2012 and it boots fine w/o any  complaints during the device probes.
+
diff --git a/results/classifier/108/other/1014681 b/results/classifier/108/other/1014681
new file mode 100644
index 000000000..7dd7b2015
--- /dev/null
+++ b/results/classifier/108/other/1014681
@@ -0,0 +1,122 @@
+other: 0.918
+graphic: 0.916
+device: 0.915
+permissions: 0.912
+vnc: 0.909
+KVM: 0.904
+performance: 0.897
+semantic: 0.894
+files: 0.887
+debug: 0.879
+socket: 0.865
+PID: 0.864
+network: 0.793
+boot: 0.792
+
+BSOD with newer host kernels (x64) and W2k8S guest (x64)
+
+Hallo, I attempted to move virtual machines from one host to another but got stuck with Windows-BSODs on the target host. The host-side console message is "virtio_ioport_write: unexpected address 0x13 value 0x1". Eventually there are overlaps to bug #990364, but I'm not sure.
+
+Host machine: 2x Opteron 4238 a 6 cores, 32GB RAM, Linux x86_64
+Guest machine(s): Windows 2008 Server R2 x64
+
+I tried different combinations of component versions, but only kernel 2.6.34 could run the guests (but has other difficulties):
+
+host kernel	Qemu-KVM	paravirtualization	guest paravirt driver
+=============================================
+2.6.34		1.0.1		virtio				0.1.15		ok
+										0.1.22		ok
+										0.1.prewhql	ok
+			git 20120615	virtio				0.1.15		ok
+										0.1.22		ok
+										0.1.prewhql	ok
+=============================================
+2.6.39		1.0.1		virtio				0.1.15		BSOD
+			git 20120615	virtio				0.1.15		BSOD
+3.0.3		1.0.1		virtio				0.1.15		BSOD
+			git 20120615	virtio				0.1.15		BSOD
+3.3.8		1.0.1		virtio				0.1.15		BSOD
+			git 20120615	virtio				0.1.15		BSOD
+						virtio-pci			0.1.15		BSOD
+3.4.2		1.0.1		virtio				0.1.15		BSOD
+										0.1.prewhql	BSOD
+						virtio-pci			0.1.15		BSOD
+			git 20120615	virtio				0.1.15		BSOD
+										0.1.prewhql	BSOD
+						virtio-pci			0.1.15		BSOD
+=============================================
+
+Run arguments are attached. Minidump follows immediately.
+
+
+
+
+
+
+
+"virtio_ioport_write: unexpected address 0x13 value 0x1" indicates that you got a BSOD.
+
+Could you try switching from virtio to e1000, and ide  and check if you still getting 
+DRIVER_CORRUPTED_EXPOOL (c5) bug check error?
+
+Vadim.
+
+With e1000 and ide I also get BSOD (tried this already), but I don't have a matching dump by hand at the moment. I will "produce" and provide a dump till tomorrow morning (germany).
+
+Arndt
+
+
+
+Does it always crash with the same bug check code? 
+
+
+Most (by far) crashes end with the same bug check code:
+
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-01.dmp]
+BugCheck 3B, {80000003, fffff800016a6700, fffffa6002c89e60, 0}
+Probably caused by : afd.sys ( afd!AfdIssueDeviceControl+18f )
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-02.dmp]
+BugCheck 3B, {80000003, fffff800016b5700, fffffa6002715fa0, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-03.dmp]
+BugCheck 3B, {80000003, fffff8000165e700, fffffa60032a3fa0, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-04.dmp]
+BugCheck 50, {fffffa6000000000, 1, fffff80001615261, 0}
+Could not read faulting driver name
+Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+5d2c )
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-05.dmp]
+BugCheck 3B, {80000003, fffff800016b4700, fffffa6001fc5f00, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-06.dmp]
+BugCheck 3B, {80000003, fffff8000165f700, fffffa6001d95fa0, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-07.dmp]
+BugCheck 3B, {80000003, fffff800016b8700, fffffa600316ffa0, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-08.dmp]
+BugCheck 3B, {80000003, fffff800016b5700, fffffa600292ca10, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-09.dmp]
+BugCheck 3B, {80000003, fffff8000166b700, fffffa6001c1afa0, 0}
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-10.dmp]
+BugCheck 1000007E, {ffffffffc0000005, fffff800016f2e7d, fffffa6001970858, fffffa6001970230}
+Probably caused by : ntkrnlmp.exe ( nt!KiUnwaitThread+19 )
+---------
+Loading Dump File [\\Lw\arndt\Kanzlei\Mini061612-11.dmp]
+BugCheck 3B, {80000003, fffff80001656700, fffffa60032befa0, 0}
+
+
+Could you try booting in safe mode with and without networking?
+
+Booting in safe mode works, but only without networking.
+
+Is there any hope to get this fixed in the near future or probably not? 
+
+Which version of QEMU have you been using here? Can you still reproduce this with the latest version of QEMU (version 2.9)?
+
+Sorry, but I have moved to ESXI more than 4 years ago.
+
diff --git a/results/classifier/108/other/1016 b/results/classifier/108/other/1016
new file mode 100644
index 000000000..7a0f69f83
--- /dev/null
+++ b/results/classifier/108/other/1016
@@ -0,0 +1,18 @@
+other: 0.945
+device: 0.830
+network: 0.592
+graphic: 0.447
+semantic: 0.337
+socket: 0.296
+performance: 0.295
+boot: 0.232
+vnc: 0.164
+debug: 0.091
+permissions: 0.087
+PID: 0.063
+files: 0.020
+KVM: 0.002
+
+In-process sandboxing of the majority of QEMU via WebAssembly or similar
+Additional information:
+This would be in addition to other sandboxes, such as sVirt.
diff --git a/results/classifier/108/other/1017793 b/results/classifier/108/other/1017793
new file mode 100644
index 000000000..22031622f
--- /dev/null
+++ b/results/classifier/108/other/1017793
@@ -0,0 +1,23 @@
+device: 0.816
+graphic: 0.787
+semantic: 0.650
+socket: 0.556
+network: 0.533
+other: 0.490
+vnc: 0.477
+performance: 0.454
+PID: 0.381
+permissions: 0.364
+debug: 0.336
+boot: 0.333
+files: 0.246
+KVM: 0.027
+
+S3 Trio64V+ support
+
+Is it possible to add S3 Trio emulation to QEMU at all? Since 0.12.3 the Cirrus Logic seems no longer working properly (bad font render/corrupted video). Also, S3 is a widely supported device on many OSes and architectures, which will give more compatibility for QEMU.
+
+Thanks!
+
+Sorry, seems like nobody got interested in adding S3 emulation to QEMU within the last 6 years, so this is very unlikely going to happen. Thus I'm closing this bug ticket now.
+
diff --git a/results/classifier/108/other/1019 b/results/classifier/108/other/1019
new file mode 100644
index 000000000..84e575a83
--- /dev/null
+++ b/results/classifier/108/other/1019
@@ -0,0 +1,28 @@
+graphic: 0.877
+device: 0.836
+network: 0.791
+PID: 0.742
+semantic: 0.693
+socket: 0.690
+vnc: 0.571
+performance: 0.551
+other: 0.448
+debug: 0.400
+boot: 0.393
+permissions: 0.382
+files: 0.286
+KVM: 0.014
+
+Cannot create a shared directory between Ubuntu 20.04 host and (sparc) NetBSD 8.2 guest
+Description of problem:
+I am currently trying to set up a shared directory between the Ubuntu 20.04 LTS host and the QEMU guest. However, the error messages that I receive from QEMU immediately are the following, but unfortunately I don't know the proper way to do this given the host and guest OS.
+```
+qemu-system-sparc: warning: hub port hub0port1 has no peer
+qemu-system-sparc: warning: hub 0 with no nics
+qemu-system-sparc: warning: netdev hub0port1 has no peer
+qemu-system-sparc: warning: requested NIC (#net276, model virtio) was not created (not supported by this machine?)
+```
+Steps to reproduce:
+1. Installed `samba` on the host with `sudo apt install samba`
+2. Created `/home/rflint/shared_dir` on the host
+3. Ran the command indicated at the top of the page.