6 files changed, 365 insertions, 0 deletions
diff --git a/results/classifier/118/none/133 b/results/classifier/118/none/133
new file mode 100644
index 00000000..e4279bf7
--- /dev/null
+++ b/results/classifier/118/none/133
@@ -0,0 +1,31 @@
+device: 0.796
+performance: 0.771
+network: 0.754
+architecture: 0.728
+permissions: 0.599
+PID: 0.595
+arm: 0.554
+risc-v: 0.519
+graphic: 0.505
+TCG: 0.460
+socket: 0.446
+semantic: 0.435
+register: 0.434
+vnc: 0.432
+VMM: 0.398
+ppc: 0.377
+kernel: 0.362
+peripherals: 0.362
+boot: 0.327
+virtual: 0.263
+debug: 0.230
+mistranslation: 0.210
+files: 0.206
+i386: 0.172
+hypervisor: 0.171
+x86: 0.141
+KVM: 0.120
+user-level: 0.112
+assembly: 0.108
+
+Chardev websocket might not support pasting more than a few chars
diff --git a/results/classifier/118/none/1333216 b/results/classifier/118/none/1333216
new file mode 100644
index 00000000..def69083
--- /dev/null
+++ b/results/classifier/118/none/1333216
@@ -0,0 +1,96 @@
+virtual: 0.786
+device: 0.766
+hypervisor: 0.674
+semantic: 0.658
+architecture: 0.626
+peripherals: 0.569
+graphic: 0.559
+mistranslation: 0.526
+socket: 0.466
+performance: 0.454
+vnc: 0.441
+x86: 0.433
+PID: 0.432
+ppc: 0.415
+arm: 0.398
+user-level: 0.365
+risc-v: 0.356
+VMM: 0.314
+register: 0.313
+debug: 0.291
+KVM: 0.289
+permissions: 0.282
+kernel: 0.280
+network: 0.258
+TCG: 0.211
+files: 0.211
+boot: 0.205
+assembly: 0.187
+i386: 0.131
+
+Xen 4.4 with qemu 1.6.2 VGA passthru NVIDIA
+
+Hi!
+
+Please, give me an advice.
+
+I try use VGA passthough NVidia k40 on SuperMicro Server, but server is having error.
+My Xen is using qemu (a9e8aeb3755bccb7b51174adcf4a3fc427e0d147)2.0.0
+
+My VirtualMachine is have config:
+device_model_version = "qemu-xen"
+device_model_override = "/opt/sources/qemu-a9e8aeb/x86_64-softmmu/qemu-system-x86_64"
+
+When I start VM:
+dmesg
+[    0.906181] pci 0000:00:05.0: BAR 1: can't assign mem pref (size 0x100000000)
+[    0.906187] pci 0000:00:05.0: BAR 1: trying firmware assignment [mem 0x100000000-0x1ffffffff 64bit pref]
+[    0.906193] pci 0000:00:05.0: BAR 1: assigned [mem 0x100000000-0x1ffffffff 64bit pref]
+and lspci -s 00:05.0 -vvv
+        Region 0: Memory at 85000000 (32-bit, non-prefetchable) [size=16M]
+        Region 1: Memory at 100000000 (64-bit, prefetchable) [size=4G]
+        Region 3: Memory at 82000000 (64-bit, prefetchable) [size=32M]
+
+Why?
+
+This is message in DOM0:
+lspci -s 03:00.0 -vvv
+....
+Region 0: Memory at de000000 (32-bit, non-prefetchable) [size=16M]
+Region 1: Memory at 5800000000 (64-bit, prefetchable) [size=16G]
+Region 3: Memory at 5c00000000 (64-bit, prefetchable) [size=32M]
+
+
+Why Qemu don`t mapping BAR1?
+Thanks!
+Regards!
+
+
+
+Can you still reproduce this problem with the latest version of QEMU? If so, have you already tried to report it to the folks from the Xen project?
+
+Hi!
+
+Sorry, I solved this problem. I used another project(qemu-kvm). I don't have a hardware for this.
+
+:(
+
+Thomas Huth @ 2017-07-19 11:27 GMT:
+
+> Can you still reproduce this problem with the latest version of QEMU? If
+> so, have you already tried to report it to the folks from the Xen
+> project?
+>
+> ** Changed in: qemu
+>        Status: New => Incomplete
+
+
+--
+С уважением,
+
+Гордеев Максим Николаевич!
++7 (495) 777-13-10, доб.510
+
+
+Thanks for the answer! So I'm closing this bug ticket now...
+
diff --git a/results/classifier/118/none/1333688 b/results/classifier/118/none/1333688
new file mode 100644
index 00000000..8a5ca4f7
--- /dev/null
+++ b/results/classifier/118/none/1333688
@@ -0,0 +1,90 @@
+device: 0.497
+network: 0.484
+PID: 0.461
+vnc: 0.365
+VMM: 0.333
+ppc: 0.299
+socket: 0.278
+kernel: 0.258
+register: 0.234
+hypervisor: 0.230
+graphic: 0.222
+virtual: 0.221
+arm: 0.217
+architecture: 0.206
+risc-v: 0.206
+i386: 0.191
+TCG: 0.168
+x86: 0.168
+debug: 0.149
+boot: 0.147
+performance: 0.136
+semantic: 0.132
+KVM: 0.131
+peripherals: 0.131
+files: 0.124
+permissions: 0.123
+user-level: 0.109
+mistranslation: 0.108
+assembly: 0.079
+
+vhost-user: VHOST_USER_SET_MEM_TABLE doesn't contain all regions
+
+
+
+vhost-user implementation doesn't provide information about all memory regions, 
+and in some cases client is not able to map buffer memory as he is missing 
+memory region information for specific address.
+
+Same thing is implemented properly for vhost-net. Below gdb outputs are 
+showing memory regions information provided to the vhost-net and vhost-user.
+
+
+
+==== memory regions information provided to vhost-net  ====
+
+(gdb) p/x hdev->mem->regions[0]
+$21 = {
+  guest_phys_addr = 0x100000000,
+  memory_size = 0xc0000000,
+  userspace_addr = 0x2aab6ac00000,
+  flags_padding = 0x0
+}
+(gdb) p/x hdev->mem->regions[1]
+$22 = {
+  guest_phys_addr = 0xfffc0000,
+  memory_size = 0x40000,
+  userspace_addr = 0x7ffff4a00000,
+  flags_padding = 0x0
+}
+(gdb) p/x hdev->mem->regions[2]
+$23 = {
+  guest_phys_addr = 0x0,
+  memory_size = 0xa0000,
+  userspace_addr = 0x2aaaaac00000,
+  flags_padding = 0x0
+}
+(gdb) p/x hdev->mem->regions[3]
+$24 = {
+  guest_phys_addr = 0xc0000,
+  memory_size = 0xbff40000,
+  userspace_addr = 0x2aaaaacc0000,
+  flags_padding = 0x0
+}
+(gdb)
+
+
+==== memory regions information provided to vhost-user  ====
+
+(gdb) p/x msg.memory.nregions
+$28 = 0x1
+(gdb) p/x msg.memory.regions[0]
+$29 = {
+  guest_phys_addr = 0x0,
+  memory_size = 0x180000000,
+  userspace_addr = 0x2aaaaac00000
+}
+(gdb)
+
+Problem fixed in qemu commit 3fd74b84.
+
diff --git a/results/classifier/118/none/1336192 b/results/classifier/118/none/1336192
new file mode 100644
index 00000000..036a8f27
--- /dev/null
+++ b/results/classifier/118/none/1336192
@@ -0,0 +1,40 @@
+device: 0.790
+mistranslation: 0.713
+files: 0.651
+register: 0.626
+kernel: 0.541
+performance: 0.534
+architecture: 0.474
+VMM: 0.423
+PID: 0.418
+socket: 0.415
+boot: 0.397
+risc-v: 0.396
+arm: 0.384
+vnc: 0.382
+semantic: 0.374
+permissions: 0.354
+network: 0.328
+x86: 0.327
+hypervisor: 0.311
+KVM: 0.308
+TCG: 0.308
+debug: 0.302
+i386: 0.295
+graphic: 0.276
+ppc: 0.246
+assembly: 0.222
+peripherals: 0.220
+virtual: 0.203
+user-level: 0.186
+
+delvm does not delete snapshots on every disks
+
+Using more than one block device, using delvm does remove snapshot from the first block device, but does not remove snapshots from other blockdevs (complains about not finding snapshot on 1st blockdev).
+
+Attached patch fixes that.
+
+
+
+fixed by af957387547b05ed6dc4d84c10cca42700a7aeda
+
diff --git a/results/classifier/118/none/1336194 b/results/classifier/118/none/1336194
new file mode 100644
index 00000000..e449479f
--- /dev/null
+++ b/results/classifier/118/none/1336194
@@ -0,0 +1,60 @@
+graphic: 0.597
+ppc: 0.592
+risc-v: 0.548
+performance: 0.534
+PID: 0.526
+device: 0.488
+permissions: 0.485
+x86: 0.484
+peripherals: 0.477
+semantic: 0.472
+architecture: 0.462
+debug: 0.459
+TCG: 0.444
+register: 0.439
+arm: 0.434
+vnc: 0.432
+network: 0.428
+files: 0.417
+socket: 0.400
+hypervisor: 0.398
+mistranslation: 0.394
+VMM: 0.376
+i386: 0.357
+user-level: 0.349
+boot: 0.348
+KVM: 0.343
+virtual: 0.315
+assembly: 0.293
+kernel: 0.282
+
+Errors reporting in do_delvm caused a crash
+
+In case of multiple errors, it leads to a crash.
+
+Typical back trace:
+#0  <in libc> in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
+#1  <in libc> in __GI_abort () at abort.c:90
+#2  <in libc> in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=<in libc> "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
+#3  <in libc> in malloc_printerr (action=3, str=<in libc> "double free or corruption (out)", ptr=<optimized out>) at malloc.c:4902
+#4  <in libc> in _int_free (av=<optimized out>, p=<in heap chunk>, have_lock=0) at malloc.c:3758
+#5  <in qemu binary> in error_free (err=<in heap chunk>) at util/error.c:166
+#6  <in qemu binary> in do_delvm (mon=<in heap chunk>, qdict=<optimized out>) at /home/qemudbg/src/qemu/savevm.c:1132
+#7  <in qemu binary> in handle_user_command (mon=mon@entry=<in heap chunk>, cmdline=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4167
+#8  <in qemu binary> in monitor_command_cb (opaque=<in heap chunk>, cmdline=<optimized out>, readline_opaque=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4878
+#9  <in qemu binary> in readline_handle_byte (rs=<in heap>, ch=<optimized out>) at util/readline.c:371
+#10 <in qemu binary> in monitor_read (opaque=<optimized out>, buf=<optimized out>, size=<optimized out>) at /home/qemudbg/src/qemu/monitor.c:4861
+#11 <in qemu binary> in qemu_chr_be_write (len=<optimized out>, buf=<in stack> "\n\003", s=<in heap chunk>) at qemu-char.c:165
+#12 tcp_chr_read (chan=<optimized out>, cond=<optimized out>, opaque=<in heap chunk>) at qemu-char.c:2487
+#13 <in libglib> in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
+#14 <in qemu binary> in glib_pollfds_poll () at main-loop.c:190
+#15 os_host_main_loop_wait (timeout=<optimized out>) at main-loop.c:235
+#16 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:484
+#17 <in qemu binary> in main_loop () at vl.c:2051
+#18 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4507
+
+
+
+Looks like this had been fixed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ba2b22888c43f
+
diff --git a/results/classifier/118/none/1338957 b/results/classifier/118/none/1338957
new file mode 100644
index 00000000..158007a5
--- /dev/null
+++ b/results/classifier/118/none/1338957
@@ -0,0 +1,48 @@
+performance: 0.761
+semantic: 0.689
+graphic: 0.680
+device: 0.640
+ppc: 0.590
+architecture: 0.539
+files: 0.520
+socket: 0.515
+network: 0.493
+mistranslation: 0.477
+vnc: 0.475
+peripherals: 0.463
+boot: 0.459
+register: 0.455
+risc-v: 0.451
+hypervisor: 0.438
+kernel: 0.419
+virtual: 0.418
+i386: 0.410
+VMM: 0.402
+PID: 0.333
+permissions: 0.305
+TCG: 0.298
+x86: 0.276
+KVM: 0.241
+debug: 0.240
+assembly: 0.231
+arm: 0.225
+user-level: 0.118
+
+RFE: add an event to report block devices watermark
+
+Add an event to report if a block device usage exceeds a threshold. The threshold should be configurable with a monitor command. The event should report the affected block device. Additional useful information could be the offset of the highest sector , like in the query-blockstats output.
+
+Rationale for the RFE
+Managing applications, like oVirt (http://www.ovirt.org), make extensive use of thin-provisioned disk images.
+In order to let the guest run flawlessly and be not unnecessarily paused, oVirt sets a watermark and automatically resized the image once the watermark is reached or exceeded.
+
+In order to detect the mark crossing, the managing application has no choice than aggressively polling the QEMU monitor
+using the query-blockstats command. This lead to unnecessary system load, and is made even worse under scale: scenarios
+with hunderds of VM are becoming not unusual.
+
+patch posted on qemu-devel, reviewd, acked and merged into maintainer's branch:
+https://github.com/stefanha/qemu/commit/f050ea639522e9dd7e501ef285a2a12709b8726a
+
+Upstream here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e2462113b2003085ad16f15e1
+