From 256709d2eb3fd80d768a99964be5caa61effa2a0 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Tue, 3 Jun 2025 12:04:13 +0000
Subject: add new classifier result

---
 results/classifier/105/socket/1020484 |  35 ++++++
 results/classifier/105/socket/1030666 | 114 +++++++++++++++++
 results/classifier/105/socket/1031    |  55 +++++++++
 results/classifier/105/socket/1055    |  29 +++++
 results/classifier/105/socket/1064631 |  31 +++++
 results/classifier/105/socket/1067119 |  26 ++++
 results/classifier/105/socket/1067517 |  94 ++++++++++++++
 results/classifier/105/socket/1075272 |  30 +++++
 results/classifier/105/socket/1075339 |  27 ++++
 results/classifier/105/socket/1080086 | 224 ++++++++++++++++++++++++++++++++++
 results/classifier/105/socket/1090    |  28 +++++
 results/classifier/105/socket/1185395 | 113 +++++++++++++++++
 results/classifier/105/socket/1213196 |  37 ++++++
 results/classifier/105/socket/1228285 |  79 ++++++++++++
 results/classifier/105/socket/1253563 |  55 +++++++++
 results/classifier/105/socket/1264    |  14 +++
 results/classifier/105/socket/1299566 |  31 +++++
 results/classifier/105/socket/1381639 |  32 +++++
 results/classifier/105/socket/1410288 |  79 ++++++++++++
 results/classifier/105/socket/1450881 | 125 +++++++++++++++++++
 results/classifier/105/socket/1463812 | 190 ++++++++++++++++++++++++++++
 results/classifier/105/socket/1542965 |  23 ++++
 results/classifier/105/socket/1567    |  47 +++++++
 results/classifier/105/socket/1572329 | 104 ++++++++++++++++
 results/classifier/105/socket/1585432 |  45 +++++++
 results/classifier/105/socket/1586756 | 141 +++++++++++++++++++++
 results/classifier/105/socket/1612908 |  25 ++++
 results/classifier/105/socket/1663079 |  40 ++++++
 results/classifier/105/socket/1673373 | 123 +++++++++++++++++++
 results/classifier/105/socket/1700380 |  34 ++++++
 results/classifier/105/socket/1708462 |  39 ++++++
 results/classifier/105/socket/1721220 |  49 ++++++++
 results/classifier/105/socket/1721222 |  32 +++++
 results/classifier/105/socket/1721224 |  39 ++++++
 results/classifier/105/socket/1725267 | 122 ++++++++++++++++++
 results/classifier/105/socket/1744009 |  41 +++++++
 results/classifier/105/socket/1754605 |  35 ++++++
 results/classifier/105/socket/1756    |  56 +++++++++
 results/classifier/105/socket/1759338 | 140 +++++++++++++++++++++
 results/classifier/105/socket/1777    |  14 +++
 results/classifier/105/socket/1781280 |  27 ++++
 results/classifier/105/socket/1796754 |  51 ++++++++
 results/classifier/105/socket/1801933 | 146 ++++++++++++++++++++++
 results/classifier/105/socket/1823790 | 215 ++++++++++++++++++++++++++++++++
 results/classifier/105/socket/1826401 |  57 +++++++++
 results/classifier/105/socket/1828207 |  52 ++++++++
 results/classifier/105/socket/1828608 |  56 +++++++++
 results/classifier/105/socket/1829779 |  93 ++++++++++++++
 results/classifier/105/socket/1829945 |  62 ++++++++++
 results/classifier/105/socket/1836453 |  50 ++++++++
 results/classifier/105/socket/1837    |  48 ++++++++
 results/classifier/105/socket/1837651 |  34 ++++++
 results/classifier/105/socket/1843590 |  49 ++++++++
 results/classifier/105/socket/1857811 | 202 ++++++++++++++++++++++++++++++
 results/classifier/105/socket/1861884 |  50 ++++++++
 results/classifier/105/socket/1867601 |  34 ++++++
 results/classifier/105/socket/1868221 |  76 ++++++++++++
 results/classifier/105/socket/1870331 |  91 ++++++++++++++
 results/classifier/105/socket/1877015 | 192 +++++++++++++++++++++++++++++
 results/classifier/105/socket/1882784 |  78 ++++++++++++
 results/classifier/105/socket/1885718 |  80 ++++++++++++
 results/classifier/105/socket/1886    |  30 +++++
 results/classifier/105/socket/1887604 |  79 ++++++++++++
 results/classifier/105/socket/1888303 |  67 ++++++++++
 results/classifier/105/socket/1898084 |  49 ++++++++
 results/classifier/105/socket/1901440 | 137 +++++++++++++++++++++
 results/classifier/105/socket/1904    |  29 +++++
 results/classifier/105/socket/1906948 |  73 +++++++++++
 results/classifier/105/socket/1907926 |  51 ++++++++
 results/classifier/105/socket/1923692 |  29 +++++
 results/classifier/105/socket/1925449 |  59 +++++++++
 results/classifier/105/socket/1949    |  25 ++++
 results/classifier/105/socket/2191    |  14 +++
 results/classifier/105/socket/2254    |  14 +++
 results/classifier/105/socket/2292    |  32 +++++
 results/classifier/105/socket/2341    |  45 +++++++
 results/classifier/105/socket/2444    |  14 +++
 results/classifier/105/socket/2584    |  29 +++++
 results/classifier/105/socket/2624    |  52 ++++++++
 results/classifier/105/socket/2678    |  22 ++++
 results/classifier/105/socket/284     |  14 +++
 results/classifier/105/socket/2867    |  26 ++++
 results/classifier/105/socket/2876    |  27 ++++
 results/classifier/105/socket/2925    |  38 ++++++
 results/classifier/105/socket/323     |  14 +++
 results/classifier/105/socket/347     |  14 +++
 results/classifier/105/socket/588735  |  51 ++++++++
 results/classifier/105/socket/761471  |  28 +++++
 results/classifier/105/socket/778032  | 108 ++++++++++++++++
 results/classifier/105/socket/796202  |  83 +++++++++++++
 results/classifier/105/socket/833     |  55 +++++++++
 results/classifier/105/socket/872     |  14 +++
 results/classifier/105/socket/939995  | 114 +++++++++++++++++
 93 files changed, 5776 insertions(+)
 create mode 100644 results/classifier/105/socket/1020484
 create mode 100644 results/classifier/105/socket/1030666
 create mode 100644 results/classifier/105/socket/1031
 create mode 100644 results/classifier/105/socket/1055
 create mode 100644 results/classifier/105/socket/1064631
 create mode 100644 results/classifier/105/socket/1067119
 create mode 100644 results/classifier/105/socket/1067517
 create mode 100644 results/classifier/105/socket/1075272
 create mode 100644 results/classifier/105/socket/1075339
 create mode 100644 results/classifier/105/socket/1080086
 create mode 100644 results/classifier/105/socket/1090
 create mode 100644 results/classifier/105/socket/1185395
 create mode 100644 results/classifier/105/socket/1213196
 create mode 100644 results/classifier/105/socket/1228285
 create mode 100644 results/classifier/105/socket/1253563
 create mode 100644 results/classifier/105/socket/1264
 create mode 100644 results/classifier/105/socket/1299566
 create mode 100644 results/classifier/105/socket/1381639
 create mode 100644 results/classifier/105/socket/1410288
 create mode 100644 results/classifier/105/socket/1450881
 create mode 100644 results/classifier/105/socket/1463812
 create mode 100644 results/classifier/105/socket/1542965
 create mode 100644 results/classifier/105/socket/1567
 create mode 100644 results/classifier/105/socket/1572329
 create mode 100644 results/classifier/105/socket/1585432
 create mode 100644 results/classifier/105/socket/1586756
 create mode 100644 results/classifier/105/socket/1612908
 create mode 100644 results/classifier/105/socket/1663079
 create mode 100644 results/classifier/105/socket/1673373
 create mode 100644 results/classifier/105/socket/1700380
 create mode 100644 results/classifier/105/socket/1708462
 create mode 100644 results/classifier/105/socket/1721220
 create mode 100644 results/classifier/105/socket/1721222
 create mode 100644 results/classifier/105/socket/1721224
 create mode 100644 results/classifier/105/socket/1725267
 create mode 100644 results/classifier/105/socket/1744009
 create mode 100644 results/classifier/105/socket/1754605
 create mode 100644 results/classifier/105/socket/1756
 create mode 100644 results/classifier/105/socket/1759338
 create mode 100644 results/classifier/105/socket/1777
 create mode 100644 results/classifier/105/socket/1781280
 create mode 100644 results/classifier/105/socket/1796754
 create mode 100644 results/classifier/105/socket/1801933
 create mode 100644 results/classifier/105/socket/1823790
 create mode 100644 results/classifier/105/socket/1826401
 create mode 100644 results/classifier/105/socket/1828207
 create mode 100644 results/classifier/105/socket/1828608
 create mode 100644 results/classifier/105/socket/1829779
 create mode 100644 results/classifier/105/socket/1829945
 create mode 100644 results/classifier/105/socket/1836453
 create mode 100644 results/classifier/105/socket/1837
 create mode 100644 results/classifier/105/socket/1837651
 create mode 100644 results/classifier/105/socket/1843590
 create mode 100644 results/classifier/105/socket/1857811
 create mode 100644 results/classifier/105/socket/1861884
 create mode 100644 results/classifier/105/socket/1867601
 create mode 100644 results/classifier/105/socket/1868221
 create mode 100644 results/classifier/105/socket/1870331
 create mode 100644 results/classifier/105/socket/1877015
 create mode 100644 results/classifier/105/socket/1882784
 create mode 100644 results/classifier/105/socket/1885718
 create mode 100644 results/classifier/105/socket/1886
 create mode 100644 results/classifier/105/socket/1887604
 create mode 100644 results/classifier/105/socket/1888303
 create mode 100644 results/classifier/105/socket/1898084
 create mode 100644 results/classifier/105/socket/1901440
 create mode 100644 results/classifier/105/socket/1904
 create mode 100644 results/classifier/105/socket/1906948
 create mode 100644 results/classifier/105/socket/1907926
 create mode 100644 results/classifier/105/socket/1923692
 create mode 100644 results/classifier/105/socket/1925449
 create mode 100644 results/classifier/105/socket/1949
 create mode 100644 results/classifier/105/socket/2191
 create mode 100644 results/classifier/105/socket/2254
 create mode 100644 results/classifier/105/socket/2292
 create mode 100644 results/classifier/105/socket/2341
 create mode 100644 results/classifier/105/socket/2444
 create mode 100644 results/classifier/105/socket/2584
 create mode 100644 results/classifier/105/socket/2624
 create mode 100644 results/classifier/105/socket/2678
 create mode 100644 results/classifier/105/socket/284
 create mode 100644 results/classifier/105/socket/2867
 create mode 100644 results/classifier/105/socket/2876
 create mode 100644 results/classifier/105/socket/2925
 create mode 100644 results/classifier/105/socket/323
 create mode 100644 results/classifier/105/socket/347
 create mode 100644 results/classifier/105/socket/588735
 create mode 100644 results/classifier/105/socket/761471
 create mode 100644 results/classifier/105/socket/778032
 create mode 100644 results/classifier/105/socket/796202
 create mode 100644 results/classifier/105/socket/833
 create mode 100644 results/classifier/105/socket/872
 create mode 100644 results/classifier/105/socket/939995

(limited to 'results/classifier/105/socket')

diff --git a/results/classifier/105/socket/1020484 b/results/classifier/105/socket/1020484
new file mode 100644
index 00000000..63b78429
--- /dev/null
+++ b/results/classifier/105/socket/1020484
@@ -0,0 +1,35 @@
+socket: 0.852
+network: 0.731
+other: 0.662
+semantic: 0.613
+device: 0.613
+graphic: 0.485
+instruction: 0.429
+mistranslation: 0.394
+boot: 0.372
+vnc: 0.284
+KVM: 0.095
+assembly: 0.055
+
+RFE: Support spice via unix domain socket
+
+According to the man page, spice can be only used via TCP/IP in opposite to VNC, which can also be configured to listen on a unix domain socket. To make it easy to use spice without exposing the interface, please support unix domain sockets as well. I can try  to provide a patch, if you can point me to the source code where TCP/IP socket is opened.
+
+There is already support for that in spice-server afaik, though I don't remember the api or what commit, or if it's in a released version (well, it's surely in 0.11.0, but that's unstable). Sorry about the lack of details, I suggest you search spice-devel mailing list archive though. I think libvirt can already use it, but perhaps you want a commandline option, that may be missing.
+
+Alon
+
+you could pass sockets via QMP a while ago, but listening to unix socket has been added there:
+
+commit fe4831b1e7e7007ae15ae0470a06898660ab3877
+Author: Marc-André Lureau <email address hidden>
+Date:   Tue Jan 13 17:57:51 2015 +0100
+
+    spice: add unix address support
+    
+    Teach qemu to set up a Spice server with a UNIX socket using the
+    following arguments -spice unix,addr=path.
+    
+    Signed-off-by: Gerd Hoffmann <email address hidden>
+
+
diff --git a/results/classifier/105/socket/1030666 b/results/classifier/105/socket/1030666
new file mode 100644
index 00000000..0cba8947
--- /dev/null
+++ b/results/classifier/105/socket/1030666
@@ -0,0 +1,114 @@
+socket: 0.945
+semantic: 0.945
+network: 0.942
+other: 0.939
+instruction: 0.930
+assembly: 0.927
+boot: 0.914
+device: 0.904
+graphic: 0.901
+mistranslation: 0.873
+vnc: 0.853
+KVM: 0.824
+
+gdb can't proceed after a breakpoint
+
+Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/
+Host: Windows 7 Ultimate 64-bit
+Guest: i386 system running MS-DOS 6.22
+Launch command line:
+  qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234
+Debbugers tried:
+  gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16
+  gdb 7.4 on MinGW
+
+Short description:
+I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work.
+
+Steps to reproduce:
+DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk.
+Data.vfd is a floppy image containing a single program (hello.com).
+The aim is to debug the execution of hello.com with gdb.
+Launch Qemu.
+Launch gdb, an attach to qemu:
+  "target remote localhost:1234"
+I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution:
+  "break *0xf730"
+  "continue"
+In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control.
+Examining the program gives expected results (such as "info reg" or "disassemble").
+At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint.
+The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work.
+
+Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C.
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+Hi,
+
+Thank you for your email, I remember this issue. Unfortunately I don’t have the time to try this right now, but I may be able to get to it in the next couple of weeks.
+
+Regards,
+Legorol
+
+From: Thomas Huth
+Sent: 07 April 2017 14:59
+To: <email address hidden>
+Subject: [Bug 1030666] Re: gdb can't proceed after a breakpoint
+
+Triaging old bug tickets ... can you still reproduce this issue with the
+latest version of QEMU (version 2.9)?
+
+** Changed in: qemu
+       Status: New => Incomplete
+
+-- 
+You received this bug notification because you are subscribed to the bug
+report.
+https://bugs.launchpad.net/bugs/1030666
+
+Title:
+  gdb can't proceed after a breakpoint
+
+Status in QEMU:
+  Incomplete
+
+Bug description:
+  Using qemu-1.1.0-windows.zip package from http://lassauge.free.fr/qemu/
+  Host: Windows 7 Ultimate 64-bit
+  Guest: i386 system running MS-DOS 6.22
+  Launch command line:
+    qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234
+  Debbugers tried:
+    gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16
+    gdb 7.4 on MinGW
+
+  Short description:
+  I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work.
+
+  Steps to reproduce:
+  DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk.
+  Data.vfd is a floppy image containing a single program (hello.com).
+  The aim is to debug the execution of hello.com with gdb.
+  Launch Qemu.
+  Launch gdb, an attach to qemu:
+    "target remote localhost:1234"
+  I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution:
+    "break *0xf730"
+    "continue"
+  In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control.
+  Examining the program gives expected results (such as "info reg" or "disassemble").
+  At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint.
+  The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work.
+
+  Note that single-stepping and continue works as expected if it is done
+  after interrupting execution with Ctrl-C.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/qemu/+bug/1030666/+subscriptions
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1031 b/results/classifier/105/socket/1031
new file mode 100644
index 00000000..66aa9d60
--- /dev/null
+++ b/results/classifier/105/socket/1031
@@ -0,0 +1,55 @@
+socket: 0.864
+boot: 0.819
+device: 0.790
+graphic: 0.666
+instruction: 0.646
+semantic: 0.601
+other: 0.463
+vnc: 0.394
+network: 0.274
+mistranslation: 0.203
+assembly: 0.152
+KVM: 0.026
+
+Intel 12th Gen CPU not working with QEMU Hyper-V nested virtualization
+Description of problem:
+When booting with Hyper-V + host-passthrough it gets stuck at tianocore, does not change until I reboot which then loops into windows diagnostics which leads nowhere. Done using Windows 10, tried using newest windows version and 1909.
+
+Specs: Manjaro Gnome 5.15 LTS, i5-12600k, z690 gigabyte aorus elite ddr4, rtx 3070ti.
+
+I’ve spent days trying to figure out what was messing with it and it turned out I could boot when messing with my CPU topology, for some reason my 12th gen + Hyper-V + host-passthrough only works with sockets. Cores and threads above 1 causes boot problems, apart from disabling vme which boots, but the hypervisor does not load.
+
+This fails (normal host-passthrough):
+```
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="1" dies="1" cores="6" threads="2"/>
+  </cpu>
+```
+
+This boots (-can only change sockets):
+```
+  <cpu mode="host-passthrough" check="none" migratable="on">
+    <topology sockets="12" dies="1" cores="1" threads="1"/>
+  </cpu>
+```
+
+This boots (-no hypervisor):
+```
+<cpu mode="host-passthrough" check="partial" migratable="off">
+    <topology sockets="1" dies="1" cores="6" threads="2"/>
+    <feature policy="disable" name="vme"/>
+  </cpu>
+```
+
+No matter what adjustment I do I cannot change the cores or threads or it will result in a boot failure, host-model just does not work once I boot the machine the host model changes to cooperlake.
+
+My current way of bypassing this is I’ve downloaded the QEMU source code, gone through cpu.c and modified the default skylake-client CPU model to match my CPU, then I added in most of my i5-12600k flags manually, this seems to work with a 35-45% performance drop in CPU and in ram. Without Hyper-V enabled and using the normal host-passthrough I get near bare metal performance.
+
+Tried with multiple versions of QEMU, EDK2, and loads of kernel versions (to add to this my i5-12600k gen does not work on kernel version 5.13 and below) even went ahead to try Ubuntu and had the same problem, my other (i7-9700k) PC works fine with Hyper-V. Also disabled my E-cores through bios resulting in the same issue. CPU pinning the P-cores to the guest does not seem to help.
+Steps to reproduce:
+1. Enable hyper-v in windows features
+2. Restart guest
+3. Boot failure
+Additional information:
+Hyper-V host-passthrough XML:
+https://pst.klgrth.io/paste/yc5wk
diff --git a/results/classifier/105/socket/1055 b/results/classifier/105/socket/1055
new file mode 100644
index 00000000..c3945e63
--- /dev/null
+++ b/results/classifier/105/socket/1055
@@ -0,0 +1,29 @@
+socket: 0.982
+device: 0.838
+network: 0.764
+instruction: 0.747
+graphic: 0.745
+semantic: 0.438
+vnc: 0.421
+assembly: 0.405
+boot: 0.400
+KVM: 0.348
+mistranslation: 0.250
+other: 0.143
+
+QEMU does not close listening socket for incoming migration when post-copy migration breaks
+Description of problem:
+QEMU keeps listening on the incoming port even after breaking a post-copy
+migration using "migrate-pause" QMP command. And even once migration is
+finished after recovering it "migrate-recover" using a different port number.
+If "migrate-recover" is called with a URI specifying the original port (which
+is still in LISTEN state), QEMU reports "Failed to find an available port:
+Address already in use".
+Steps to reproduce:
+1. start migration
+2. wait for the first iteration to finish
+3. switch to post-copy using "migrate-start-postcopy"
+3. break migration with "migrate-pause"
+4. check lsof -p $QEMU_PID
+Additional information:
+
diff --git a/results/classifier/105/socket/1064631 b/results/classifier/105/socket/1064631
new file mode 100644
index 00000000..e6133131
--- /dev/null
+++ b/results/classifier/105/socket/1064631
@@ -0,0 +1,31 @@
+socket: 0.956
+network: 0.947
+device: 0.795
+graphic: 0.635
+instruction: 0.502
+semantic: 0.458
+other: 0.404
+vnc: 0.389
+mistranslation: 0.315
+boot: 0.301
+KVM: 0.268
+assembly: 0.130
+
+Feature request: tls for chardev socket (telnet,tcp,udp)
+
+Hello,
+
+it would be nice if chardev socket (telnet,tcp,udp) could have tls support as vnc does.
+
+This way we could have encrypted access to virtual character devices over network,
+for example in setup: conserver -> socat+tls <-> qemu+chardev+tls.
+
+The best would be both direction - server even client, so even the client should
+trust remote server (trustfile, fingeprint...?).
+
+Thank you.
+
+This support was introduced in QEMU 2.6 last year. Some info here:
+
+https://www.berrange.com/posts/2016/08/16/improving-qemu-security-part-6-tls-support-for-character-devices/
+
diff --git a/results/classifier/105/socket/1067119 b/results/classifier/105/socket/1067119
new file mode 100644
index 00000000..7c0344dc
--- /dev/null
+++ b/results/classifier/105/socket/1067119
@@ -0,0 +1,26 @@
+socket: 0.797
+graphic: 0.795
+device: 0.726
+network: 0.677
+semantic: 0.441
+vnc: 0.409
+boot: 0.250
+other: 0.157
+instruction: 0.146
+mistranslation: 0.085
+assembly: 0.033
+KVM: 0.018
+
+e1000 missing statistics
+
+The E1000 emulation is missing several counters that are used by other software.
+
+The following would be useful:
+  Good bytes receive counter GORCH/GORCL
+  Good bytes transmit counter GOTCH/GOTCL
+Broadcast packets sent/received
+Multicast packets sent/received.
+
+Looks like these counters have been implemented here:
+http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=3b27430177498a1728b6
+
diff --git a/results/classifier/105/socket/1067517 b/results/classifier/105/socket/1067517
new file mode 100644
index 00000000..43010355
--- /dev/null
+++ b/results/classifier/105/socket/1067517
@@ -0,0 +1,94 @@
+socket: 0.754
+graphic: 0.751
+instruction: 0.717
+assembly: 0.703
+other: 0.702
+device: 0.691
+KVM: 0.681
+semantic: 0.680
+network: 0.680
+vnc: 0.649
+boot: 0.582
+mistranslation: 0.573
+
+qemu dosn't save snapshots with the 'commit' command
+
+Usually there is the 'commit' command in qemu which is described as followed: "commit changes to the disk images (if -snapshot is used) or backing files"
+From the context i though if i start a guest with the "-snapshot" option, the commit command would save all the changes back to the file. I've tried it out but i didn't get it to work. I tried a few things like first use savevm or stop and than commit all, but actually nothing works.
+Interestingly, when using qcow2 files qemu doesn't show's any error at all. The changes in the guest just won't get saved. But if i'm using lvm2 partitions i would get I/O errors after execute 'commit all'. That's probably because lvm2 doesn't support this feature.?!? However i made a attachment which shows the error's in the guest (dmesg).
+
+Right now i started the guest with following command:
+/usr/bin/qemu-system-x86_64 -name g64 -runas kvm -m 4096 -smp 2 \
+-monitor unix:/var/run/kvm/g64.sock,server,nowait -pidfile /var/run/kvm/g64.pid -daemonize -snapshot \
+-device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent \
+-device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
+-drive file=/media/btrfs/g64.qcow2,if=virtio,cache=none,aio=threads \
+-netdev type=tap,id=g64_3,vhost=on,ifname=qtap3,script=no,downscript=no \
+-device virtio-net-pci,netdev=g64_3,mac=DE:AD:BE:EF:CB:22 \
+-spice port=5803,addr=192.168.2.60,password=secret -k de -cpu host \
+-usb -usbdevice tablet -vga qxl
+
+The system is stable gentoo:
+Portage 2.1.11.9 (default/linux/amd64/10.0/no-multilib, gcc-4.5.4, glibc-2.15-r2, 3.4.9-gentoo x86_64)
+=================================================================
+                        System Settings
+=================================================================
+System uname: Linux-3.4.9-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5405_@_2.00GHz-with-gentoo-2.1
+Timestamp of tree: Tue, 16 Oct 2012 03:45:01 +0000
+app-shells/bash:          4.2_p37
+dev-lang/python:          2.7.3-r2, 3.2.3
+dev-util/cmake:           2.8.8-r3
+dev-util/pkgconfig:       0.27.1
+sys-apps/baselayout:      2.1-r1
+sys-apps/openrc:          0.9.8.4
+sys-apps/sandbox:         2.5
+sys-devel/autoconf:       2.68
+sys-devel/automake:       1.11.6
+sys-devel/binutils:       2.22-r1
+sys-devel/gcc:            4.5.4
+sys-devel/gcc-config:     1.7.3
+sys-devel/libtool:        2.4-r1
+sys-devel/make:           3.82-r3
+sys-kernel/linux-headers: 3.4-r2 (virtual/os-headers)
+sys-libs/glibc:           2.15-r2
+Repositories: gentoo x-local x11 sunrise virtualization
+ACCEPT_KEYWORDS="amd64"
+ACCEPT_LICENSE="* -@EULA"
+CBUILD="x86_64-pc-linux-gnu"
+CFLAGS="-O2 -pipe -march=native -fopenmp"
+CHOST="x86_64-pc-linux-gnu"
+CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa"
+CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
+CXXFLAGS="-O2 -pipe -march=native -fopenmp"
+DISTDIR="/usr/portage/distfiles"
+FCFLAGS="-O2 -pipe"
+FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
+FFLAGS="-O2 -pipe"
+GENTOO_MIRRORS="        http://gentoo.supp.name/                                http://ftp.fi.muni.cz/pub/linux/gentoo/                         http://gentoo.mirror.web4u.cz/                          http://gentoo.mirror.dkm.cz/pub/gentoo/                         http://gentoo.ynet.sk/pub"
+LANG="de_DE.utf8"
+LDFLAGS="-Wl,-O1 -Wl,--as-needed -fopenmp"
+LINGUAS="en"
+MAKEOPTS="-j12"
+PKGDIR="/usr/portage/packages"
+PORTAGE_CONFIGROOT="/"
+PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
+PORTAGE_TMPDIR="/var/tmp"
+PORTDIR="/usr/portage"
+PORTDIR_OVERLAY="/home/clown/public/overlays/local /home/clown/public/overlays/layman/x11 /home/clown/public/overlays/layman/sunrise /home/clown/public/overlays/layman/virtualization"
+SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage/"
+USE="acl acpi amd64 berkdb bzip2 cli cracklib crypt cups cxx dbus dri fortran gdbm gif gpm iconv ipv6 mmx modules mudflap ncurses nls nptl openmp pam pbm pcre png pppd readline session sqlite sse sse2 ssl ssse3 tcpd threads unicode zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ruby19" SANE_BACKENDS="niash" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
+Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
+
+=================================================================
+                        Package Settings
+=================================================================
+
+app-emulation/qemu-1.1.1-r1 was built with the following:
+USE="aio caps curl ncurses sasl spice vde vhost-net -alsa -bluetooth -brltty -debug -doc -fdt -opengl -pulseaudio -python -rbd -sdl -smartcard -static -tci -tls -usbredir -virtfs -xattr -xen -xfs" QEMU_SOFTMMU_TARGETS="i386 x86_64 (-alpha) (-arm) -cris (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -xtensa -xtensaeb" QEMU_USER_TARGETS="i386 x86_64 (-alpha) (-arm) -armeb -cris (-m68k) -microblaze -microblazeel (-mips) -mipsel (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32"
+
+
+
+Triaging old bug tickets ... 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/105/socket/1075272 b/results/classifier/105/socket/1075272
new file mode 100644
index 00000000..15d761ff
--- /dev/null
+++ b/results/classifier/105/socket/1075272
@@ -0,0 +1,30 @@
+socket: 0.921
+instruction: 0.826
+network: 0.791
+device: 0.791
+other: 0.571
+graphic: 0.546
+mistranslation: 0.496
+vnc: 0.435
+boot: 0.360
+KVM: 0.290
+assembly: 0.110
+semantic: 0.011
+
+socket type mapping wrong for mips app-level emulation
+
+linux-user/syscall.c's do_socket function contains socket type remapping to work around the nonsensically-permuted MIPS socket types. However, it fails to account for the SOCK_NONBLOCK and SOCK_CLOEXEC flags that may be or'd onto the type. Thus, a call from the application such as:
+
+socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
+
+will fail to have the type permutation performed, and will be passed to the system as:
+
+socket(AF_INET, SOCK_DGRAM, IPPROTO_TCP)
+
+resulting in EPROTONOSUPPORT.
+
+To fix this, the flag bits should be masked off of the type before the permutation. They also need remapping themselves (since MIPS uses different values for these flags bits).
+
+This should be fixed in QEMU 1.6.
+
+
diff --git a/results/classifier/105/socket/1075339 b/results/classifier/105/socket/1075339
new file mode 100644
index 00000000..e4b977fe
--- /dev/null
+++ b/results/classifier/105/socket/1075339
@@ -0,0 +1,27 @@
+socket: 0.815
+mistranslation: 0.768
+semantic: 0.637
+device: 0.551
+other: 0.477
+network: 0.424
+instruction: 0.374
+boot: 0.362
+graphic: 0.355
+vnc: 0.192
+KVM: 0.149
+assembly: 0.049
+
+linux-user emulation of setsockopt ignores optlen
+
+setsockopt always treats the argument as a 4-byte int. This breaks timeout options (for which it's an 8- or 16-byte timeval structure, depending on word size) and possibly other socket options. int is probably a safe default, but options whose values are other types need special-case conversion code.
+
+Agreed; we would ideally be more careful to return ENOTSUP for options we don't know we handle correctly. It would be useful if you said which particular options you were interested in and provided a test case...
+
+
+I mentioned the timeout options (send/receive timeout) which are the
+ones I was interested in.
+
+
+We fixed our setsockopt emulation to correctly convert timeval parameters for SO_RCVTIMEO and SO_SNDTIMEO back in 2013.
+
+
diff --git a/results/classifier/105/socket/1080086 b/results/classifier/105/socket/1080086
new file mode 100644
index 00000000..c525ff49
--- /dev/null
+++ b/results/classifier/105/socket/1080086
@@ -0,0 +1,224 @@
+semantic: 0.969
+socket: 0.963
+other: 0.963
+instruction: 0.959
+device: 0.959
+boot: 0.956
+vnc: 0.949
+assembly: 0.926
+network: 0.923
+graphic: 0.923
+mistranslation: 0.918
+KVM: 0.908
+
+MC146818 RTC breaks when SET bit in Register B is on.
+
+This bug occurs when the SET flag of Register B is enabled. When an RTC
+data register (i.e. any of the 10 bytes of time/calender data in CMOS) is set,
+the data is (as expected) correctly stored in the cmos_data array. However,
+since the SET flag is enabled, the function rtc_set_time is not invoked.
+As a result, the field base_rtc in RTCState remains uninitialized. This appears to
+cause a problem on subsequent writes which can end up overwriting data.
+
+To see this, consider writing data to Register A after having written
+data to any of the RTC data registers; the following figure illustrates
+the call stack for the Register A write operation:
+
+ +- cmos_io_port_write
+ +-- check_update_timer
+ +---- get_next_alarm
+ +------ rtc_update_time
+
+In rtc_update_time, get_guest_rtc calculates the wrong time and
+overwrites the previously written RTC data register values.
+
+I have created a standalone test case which exposes this bug:
+
+   https://github.com/ahorn/benchmarks/commit/fff1ca40694bbef6f7f9de323bb0bed63419ef99
+
+I have attached a patch for the most recent version of the file hw/mc146818rtc.c [1]. The patch also features a functional test which executes through the QTest framework.
+
+I would appreciate your thoughts on this.
+
+[1] http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563
+
+Cross reference:
+
+  https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg01759.html
+
+> [...] the patch is almost good for inclusion. I'd ask for two changes:
+> 1) please test == 0, not != REG_B_SET;
+> 2) please leave the fuzzicsng test last
+
+I have attached a new patch with the requested changes.
+
+This patch also improves the quality of the functional test by
+checking that RTC_SECONDS is equal (==) to the previously written data
+provided the SET flag in Register B is still enabled. This is
+justified by the data sheet which states that an enabled SET bit
+"stops an existing update" and prevents "a new one from occurring" [1,
+p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS
+check uses an inequality (>=) as in the original test case.
+
+Out of curiosity, does anyone know how long this particular bug has
+been undetected or how/when it was introduced? This could help me
+explain to others my research interest in symbolic execution of
+hardware models and its application in form of automated test
+generation.
+
+Finally, if there is interest to improve the robustness of the RTC
+model, I could send a patch with several verification conditions (i.e.
+assertions) which can help to expose these kind of bugs in the RTC
+hardware model. Recall that most compiler can usually optimize these
+assertions away unless a developer explicitly enables them. They also
+serve as unambiguous code documentation.
+
+With best regards,
+Alex
+
+[1] http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf
+
+On 18 November 2012 08:52, Paolo Bonzini <email address hidden> wrote:
+> Il 17/11/2012 19:47, Alex Horn ha scritto:
+>> I have attached a patch for the most recent version of the file
+>> hw/mc146818rtc.c [1]. The patch also features a functional test which
+>> executes through the QTest framework.
+>>
+>> I would appreciate your thoughts on this.
+>>
+>> [1]
+>> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563
+>>
+>> ** Patch added: "register_b_set_flag.patch"
+>>    https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch
+>>
+>
+> Hi Alex, the patch is almost good for inclusion.  I'd ask for two
+> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the
+> fuzzing test last, because it may leave some registers in an undefined
+> state.
+>
+> Paolo
+
+
+>> Out of curiosity, does anyone know how long this particular bug has
+>> been undetected or how/when it was introduced?
+>
+> Probably it was introduced last September when the model was rewritten.
+>  But it's really unlikely that the bug would have been detected.
+
+Thanks for that quick assessment.
+
+> On the other hand, the bug in commit b6db4ac (which also includes a
+> qtest) was detected by autotest.  Could your tool find it, too?
+
+That's a very respectable achievement. I understand that Autotest runs
+predefined (i.e. hand-written) tests on a large scale. In contrast, we
+seek a higher degree of automation but on a smaller scale. These
+differences could make a comparison difficult. However, your example
+is much appreciated because it helps us to set our work in
+perspective.
+
+>> This could help me explain to others my research interest in symbolic
+>> execution of hardware models and its application in form of automated
+>> test generation.
+>
+> Very interesting (at least to me :)).
+
+Perhaps you find the following background helpful. To kick start our
+work, we extracted from QEMU a standalone RTC hardware model [2]
+because QOM, QMP, TCG or QTest would render the semi-automatic
+analysis infeasible. As a next step, we would like to combine this
+standalone hardware model with a Linux x86 driver [3]. The reported
+bug is a good exemplar of the type of firmware/hardware interface
+properties we are interested in. Note that this is only the initial
+phase of our research and there is much work yet to be done.
+
+Of course, any comments or collaboration are always welcome.
+
+With kind regards,
+Alex
+
+[2] https://github.com/ahorn/benchmarks/tree/master/qemu-hw
+[3] https://github.com/ahorn/benchmarks/tree/master/sw-hw/linux/rtc_x86
+
+On 19 November 2012 11:42, Paolo Bonzini <email address hidden> wrote:
+> Il 19/11/2012 12:34, Alex Horn ha scritto:
+>>> [...] the patch is almost good for inclusion. I'd ask for two changes:
+>>> 1) please test == 0, not != REG_B_SET;
+>>> 2) please leave the fuzzicsng test last
+>>
+>> I have attached a new patch with the requested changes.
+>>
+>> This patch also improves the quality of the functional test by
+>> checking that RTC_SECONDS is equal (==) to the previously written data
+>> provided the SET flag in Register B is still enabled. This is
+>> justified by the data sheet which states that an enabled SET bit
+>> "stops an existing update" and prevents "a new one from occurring" [1,
+>> p. 15]. In contrast, once the SET flag is disabled, the RTC_SECONDS
+>> check uses an inequality (>=) as in the original test case.
+>
+> Right.
+>
+>> Out of curiosity, does anyone know how long this particular bug has
+>> been undetected or how/when it was introduced?
+>
+> Probably it was introduced last September when the model was rewritten.
+>  But it's really unlikely that the bug would have been detected.
+>
+> On the other hand, the bug in commit b6db4ac (which also includes a
+> qtest) was detected by autotest.  Could your tool find it, too?
+>
+>> This could help me explain to others my research interest in symbolic
+>> execution of hardware models and its application in form of automated
+>> test generation.
+>
+> Very interesting (at least to me :)).
+>
+>> Finally, if there is interest to improve the robustness of the RTC
+>> model, I could send a patch with several verification conditions (i.e.
+>> assertions) which can help to expose these kind of bugs in the RTC
+>> hardware model.
+>
+> Sure, that's welcome.
+>
+> In particular, I assume you verified the "next alarm" code to be correct? :)
+>
+> Paolo
+>
+>> Recall that most compiler can usually optimize these
+>> assertions away unless a developer explicitly enables them. They also
+>> serve as unambiguous code documentation.
+>>
+>> With best regards,
+>> Alex
+>>
+>> [1] http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC146818.pdf
+>>
+>> On 18 November 2012 08:52, Paolo Bonzini <email address hidden> wrote:
+>>> Il 17/11/2012 19:47, Alex Horn ha scritto:
+>>>> I have attached a patch for the most recent version of the file
+>>>> hw/mc146818rtc.c [1]. The patch also features a functional test which
+>>>> executes through the QTest framework.
+>>>>
+>>>> I would appreciate your thoughts on this.
+>>>>
+>>>> [1]
+>>>> http://git.qemu.org/?p=qemu.git;a=blob;f=hw/mc146818rtc.c;h=98839f278d93452d071054e2a017b3d909b45ab2;hb=9cb535fe4ef08b01e583ec955767a0899ff79afe#l563
+>>>>
+>>>> ** Patch added: "register_b_set_flag.patch"
+>>>>    https://bugs.launchpad.net/qemu/+bug/1080086/+attachment/3436808/+files/register_b_set_flag.patch
+>>>>
+>>>
+>>> Hi Alex, the patch is almost good for inclusion.  I'd ask for two
+>>> changes: 1) please test == 0, not != REG_B_SET; 2) please leave the
+>>> fuzzing test last, because it may leave some registers in an undefined
+>>> state.
+>>>
+>>> Paolo
+>
+
+
+We fixed this bug long ago in 2012, in commit 02c6ccc6dde90d (thanks for your patch!) but forgot to close the bug...so I'm doing it now.
+
+
diff --git a/results/classifier/105/socket/1090 b/results/classifier/105/socket/1090
new file mode 100644
index 00000000..4b0d4cdc
--- /dev/null
+++ b/results/classifier/105/socket/1090
@@ -0,0 +1,28 @@
+socket: 0.913
+device: 0.830
+graphic: 0.742
+instruction: 0.698
+network: 0.565
+semantic: 0.298
+mistranslation: 0.173
+boot: 0.144
+KVM: 0.101
+vnc: 0.065
+other: 0.058
+assembly: 0.014
+
+can't create rocker device because setting device array properties on the command line is broken
+Description of problem:
+it does not accept the prop_array parameter:
+
+```
+qemu-system-x86_64 -enable-kvm -m 1g -cpu host -netdev socket,id=dev0,udp=10.10.10.227:30042,localaddr=:30042 -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0
+qemu-system-x86_64: -device rocker,len-ports=4,name=sw,len-ports=2,ports[0]=dev0: Property 'rocker.ports[0]' not found
+```
+Steps to reproduce:
+1. just run the command
+Additional information:
+the latest qemu i find working is 6.1.1... if you start a fedora vm and `dnf install kernel-modules-internal` then the rocker ports appear and work properly...
+
+thanks,
+cs
diff --git a/results/classifier/105/socket/1185395 b/results/classifier/105/socket/1185395
new file mode 100644
index 00000000..dce14bc5
--- /dev/null
+++ b/results/classifier/105/socket/1185395
@@ -0,0 +1,113 @@
+socket: 0.974
+graphic: 0.973
+instruction: 0.973
+assembly: 0.969
+semantic: 0.968
+vnc: 0.962
+network: 0.960
+boot: 0.947
+device: 0.945
+KVM: 0.936
+other: 0.926
+mistranslation: 0.923
+
+qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-backend
+
+With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error.
+Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6?
+
+( -95 might be a general "Operation not supported" error? )
+
+Up to 1.4.2 everything is OK with savevm, though.
+
+Any help welcome, 
+
+Oliver.
+
+Sorry for not providing enough informations, here we go:
+
+typical longish start for qemu is:
+
+/usr/local/bin/qemu-system-x86_64 -usbdevice tablet -enable-kvm -daemonize -pidfile /var/run/qemu-server/760.pid -monitor unix:/var/run/qemu-server/760.mon,server,nowait -vnc unix:/var/run/qemu-server/760.vnc,password -qmp unix:/var/run/qemu-server/760.qmp,server,nowait -nodefaults -serial none -parallel none -device rtl8139,mac=00:F1:70:00:2F:80,netdev=vlan0d0 -netdev type=tap,id=vlan0d0,ifname=tap760i0d0,script=/etc/fcms/add_if.sh,downscript=/etc/fcms/downscript.sh -name 1155823384-4 -m 512 -vga cirrus -k de -smp sockets=1,cores=1 -device virtio-blk-pci,drive=virtio0 -drive format=raw,file=rbd:1155823384/vm-760-disk-1.rbd:rbd_cache=false,cache=writeback,if=none,id=virtio0,media=disk,index=0 -drive format=raw,file=rbd:1155823384/vm-760-swap-1.rbd:rbd_cache=false,cache=writeback,if=virtio,media=disk,index=1 -drive if=ide,media=cdrom,id=ide1-cd0,readonly=on -drive if=ide,media=cdrom,id=ide1-cd1,readonly=on -boot order=dc
+
+after fired up I go to the monitor socket and try a:
+
+QEMU 1.5.0 monitor - type 'help' for more information
+(qemu) savevm test123
+Error -95 while writing VM
+(qemu) 
+
+If I only let the error -95 happen and ignore, everything seems to be OK, though. Might be easy to fix, but not for me...
+qemu up to 1.4.2 is not affected.
+
+Please let me know, if you need more informations.
+
+Oliver.
+
+
+
+Triaging old bug tickets ... can you still reproduce this problem with the latest version of QEMU (currently v2.9.0)?
+
+Hi Thomas,
+
+thnx for coming back on this. Currently on vacation, but just gave it a shot on fresh compiled qemu-2.9.0:
+
+—
+
+savevm
+Error while writing VM state: Operation not supported
+
+—
+
+I think there once existed a patch from the Proxmox guys dealing with the VM state informations. But
+apparently did not make it into main-stream.
+
+Kind regards,
+
+Oliver.
+
+> Am 20.07.2017 um 13:52 schrieb Thomas Huth <email address hidden>:
+> 
+> Triaging old bug tickets ... can you still reproduce this problem with
+> the latest version of QEMU (currently v2.9.0)?
+> 
+> ** Changed in: qemu
+>       Status: New => Incomplete
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1185395
+> 
+> Title:
+>  qemu-1.5.0 savevm error -95 while writing vm with ceph-rbd as storage-
+>  backend
+> 
+> Status in QEMU:
+>  Incomplete
+> 
+> Bug description:
+>  With a running VM I encounter this strange behaviour, former qemu-versions don't show up such an error.
+>  Perhaps this comes from the rbd-backend in qemu-1.5.0 in combination with ceph-0.56.6?
+> 
+>  ( -95 might be a general "Operation not supported" error? )
+> 
+>  Up to 1.4.2 everything is OK with savevm, though.
+> 
+>  Any help welcome,
+> 
+>  Oliver.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1185395/+subscriptions
+
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/96
+
+
diff --git a/results/classifier/105/socket/1213196 b/results/classifier/105/socket/1213196
new file mode 100644
index 00000000..d39f1c24
--- /dev/null
+++ b/results/classifier/105/socket/1213196
@@ -0,0 +1,37 @@
+socket: 0.799
+semantic: 0.557
+device: 0.523
+network: 0.502
+graphic: 0.422
+other: 0.410
+mistranslation: 0.363
+vnc: 0.323
+instruction: 0.255
+boot: 0.251
+KVM: 0.146
+assembly: 0.066
+
+-serial tcp should hang up when DTR goes low
+
+In keeping with the spirit of serial modem control signals, de-asserting DTR should cause the TCP connection to break; asserting DTR should cause QEMU to initiate a new connection or for it to accept another (in server mode; this may involve waiting for one to arrive, too).
+
+In addition to allowing low DTR to drop the socket connection, and allowing low DTR to reject a socket connection, the DCD modem bit also be implemented - DCD should follow the state of the TCP socket: a connected socket should pull DCD high, and a disconnected socket should pull DCD low. From what Ive seen in the source, it looks like a serial IOCTL functioned needs to be added to chardev/char-socket.c to allow the MSR bits to be tracked against the state of the socket.  DCD should be very easy to implement this way, but I hadn't thought about DTR.
+
+Sent in a patch for this.
+
+https://lists.gnu.org/archive/html/qemu-devel/2020-12/msg04658.html
+
+DTR controls the socket.
+
+DCD reflects the state of the socket.
+
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/97
+
+
diff --git a/results/classifier/105/socket/1228285 b/results/classifier/105/socket/1228285
new file mode 100644
index 00000000..11070ed5
--- /dev/null
+++ b/results/classifier/105/socket/1228285
@@ -0,0 +1,79 @@
+socket: 0.946
+network: 0.904
+device: 0.814
+vnc: 0.797
+semantic: 0.786
+other: 0.675
+instruction: 0.642
+mistranslation: 0.632
+assembly: 0.608
+graphic: 0.597
+boot: 0.432
+KVM: 0.394
+
+e1000 nic TCP performances
+
+Hi,
+
+Here is the context :
+
+$ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000
+$ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000
+
+The bandwidth is really tiny :
+
+    . Iperf3 reports about 30 Mb/sec
+    . NetPerf reports about 50 Mb/sec
+
+
+With UDP sockets, there is no problem at all :
+
+    . Iperf3 reports about 1 Gb/sec
+    . NetPerf reports about 950 Mb/sec
+
+
+I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.)
+I've used the main GIT version of QEMU.
+
+
+Thanks in advance.
+
+See you,
+VInce
+
+On Fri, Sep 20, 2013 at 05:21:23PM -0000, Vincent Autefage wrote:
+> Here is the context :
+> 
+> $ qemu -name A -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,listen=127.0.0.1:7000
+> $ qemu -name B -m 1024 -net nic vlan=0,model=e1000 -net socket,vlan=0,connect=127.0.0.1:7000
+> 
+> The bandwidth is really tiny :
+> 
+>     . Iperf3 reports about 30 Mb/sec
+>     . NetPerf reports about 50 Mb/sec
+> 
+> 
+> With UDP sockets, there is no problem at all :
+> 
+>     . Iperf3 reports about 1 Gb/sec
+>     . NetPerf reports about 950 Mb/sec
+> 
+> 
+> I've noticed this fact only with the e1000 NIC, not with others (rtl8139,virtio, etc.)
+> I've used the main GIT version of QEMU.
+
+It's interesting that you see good performance over -netdev socket TCP
+with the other NIC models.
+
+I don't know what the issue would be, you'll probably need to dig
+further to discover the problem.  Using wireshark might be a good start.
+Try to figure out where the delay is incurred and then instrument that
+code to find out the cause.
+
+Stefan
+
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1253563 b/results/classifier/105/socket/1253563
new file mode 100644
index 00000000..206fe07d
--- /dev/null
+++ b/results/classifier/105/socket/1253563
@@ -0,0 +1,55 @@
+socket: 0.666
+device: 0.645
+graphic: 0.634
+semantic: 0.564
+instruction: 0.552
+network: 0.504
+other: 0.446
+mistranslation: 0.439
+assembly: 0.425
+vnc: 0.246
+KVM: 0.197
+boot: 0.190
+
+bad performance with rng-egd backend
+
+
+1. create listen socket
+# cat /dev/random | nc -l localhost 1024
+
+2. start vm with rng-egd backend
+
+./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -mon chardev=qmp,mode=control,pretty=on -chardev socket,id=qmp,host=localhost,port=1234,server,nowait -m 2000 -device virtio-net-pci,netdev=h1,id=vnet0 -netdev tap,id=h1 -vnc :0 -drive file=/images/RHEL-64-virtio.qcow2 \
+-chardev socket,host=localhost,port=1024,id=chr0 \
+-object rng-egd,chardev=chr0,id=rng0 \
+-device virtio-rng-pci,rng=rng0,max-bytes=1024000,period=1000
+
+(guest) # dd if=/dev/hwrng of=/dev/null
+
+note: cancelling dd process by Ctrl+c, it will return the read speed.
+
+Problem:   the speed is around 1k/s
+
+===================
+
+If I use rng-random backend (filename=/dev/random), the speed is about 350k/s).
+
+It seems that when the request entry is added to the list, we don't read the data from queue list immediately.
+The chr_read() is delayed, the virtio_notify() is delayed.  the next request will also be delayed. It effects the speed.
+
+I tried to change rng_egd_chr_can_read() always returns 1,  the speed is improved to (about 400k/s)
+
+Problem: we can't poll the content in time currently
+
+
+Any thoughts?
+
+Thanks, Amos
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+Let's close this bug, it's passed 6 years.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1264 b/results/classifier/105/socket/1264
new file mode 100644
index 00000000..1e7ff709
--- /dev/null
+++ b/results/classifier/105/socket/1264
@@ -0,0 +1,14 @@
+socket: 0.953
+device: 0.816
+network: 0.713
+graphic: 0.276
+other: 0.248
+semantic: 0.241
+instruction: 0.241
+mistranslation: 0.183
+boot: 0.155
+assembly: 0.080
+KVM: 0.078
+vnc: 0.053
+
+socket chardev loses data when remote end closes the connection
diff --git a/results/classifier/105/socket/1299566 b/results/classifier/105/socket/1299566
new file mode 100644
index 00000000..1a475daa
--- /dev/null
+++ b/results/classifier/105/socket/1299566
@@ -0,0 +1,31 @@
+socket: 0.755
+network: 0.710
+device: 0.662
+graphic: 0.654
+instruction: 0.616
+vnc: 0.602
+semantic: 0.579
+mistranslation: 0.490
+other: 0.486
+boot: 0.352
+assembly: 0.268
+KVM: 0.245
+
+virtio serial doesn't work with virtio nic
+
+If virtio NIC is not used virtserialport works and delivers data written to /dev/vport0p1 to localhost:4444:
+
+qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic
+
+If using virtio nic, write to /dev/vport0p1 succeeds, but no data is delivered to localhost:4444:
+
+qemu-system-x86_64 -enable-kvm -kernel mykernel -initrd myramdisk -device virtio-serial -chardev socket,host=localhost,port=4444,id=agent -device virtserialport,chardev=agent,name=hera.agent -net user -net nic,model=virtio
+
+This bug exists in 2.0 release, Debian's QEMU 1.7 package and b3706faf from git.
+
+Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+I can't reproduce it now, I don't even remember this issue.
+
+Ok, thanks for your answer. Then let's assume that it has been fixed by one of the past releases.
+
diff --git a/results/classifier/105/socket/1381639 b/results/classifier/105/socket/1381639
new file mode 100644
index 00000000..67ced412
--- /dev/null
+++ b/results/classifier/105/socket/1381639
@@ -0,0 +1,32 @@
+socket: 0.597
+device: 0.549
+graphic: 0.357
+instruction: 0.336
+vnc: 0.332
+boot: 0.304
+network: 0.277
+semantic: 0.186
+mistranslation: 0.183
+other: 0.146
+assembly: 0.053
+KVM: 0.027
+
+sys_eeprom.c:353: buffer too small
+
+[qemu-2.1.2/roms/u-boot/board/matrix_vision/mvblx/sys_eeprom.c:353]: (error) Buffer is accessed out of bounds.
+
+        char ethaddr[9];
+
+        sprintf(ethaddr, "%02X:%02X:%02X:%02X:%02X:%02X",
+            e.mac[0],
+            e.mac[1],
+            e.mac[2],
+            e.mac[3],
+            e.mac[4],
+            e.mac[5]);
+
+18 into 9 won't go. Suggest increase size of ethaddr.
+
+roms/u-boot is not under control of the QEMU project - you should report such bugs to the u-boot project instead. Anyway, looks like the problem has been fixed there:
+http://git.denx.de/?p=u-boot.git;a=commitdiff;h=cc87d18a6ec74180784a6b
+
diff --git a/results/classifier/105/socket/1410288 b/results/classifier/105/socket/1410288
new file mode 100644
index 00000000..740a99ee
--- /dev/null
+++ b/results/classifier/105/socket/1410288
@@ -0,0 +1,79 @@
+socket: 0.886
+other: 0.872
+instruction: 0.871
+device: 0.849
+graphic: 0.830
+assembly: 0.810
+boot: 0.798
+semantic: 0.777
+network: 0.759
+mistranslation: 0.660
+vnc: 0.623
+KVM: 0.534
+
+qemu-img conversion to qcow2 hangs with blank image less than 100kiB
+
+If you try to convert a blank image to qcow2 that is less than 100kiB in size then qemu-img hangs trying to seek to the end of the file. 
+
+$ truncate --size 102399 /tmp/temp
+$ qemu-img convert -p -O qcow2 /tmp/temp /tmp/temp2.qcow2
+
+I'm finding this on all versions of qemu-img v2.
+
+strace shows a seek loop.
+
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+ioctl(6, FS_IOC_FIEMAP, 0xb5e68dc4)     = 0
+_llseek(6, 0, [100000], SEEK_END)       = 0
+
+ProblemType: Bug
+DistroRelease: Ubuntu 14.04
+Package: qemu-utils 2.0.0+dfsg-2ubuntu1.10
+ProcVersionSignature: User Name 3.13.0-43.72-generic 3.13.11.11
+Uname: Linux 3.13.0-43-generic i686
+ApportVersion: 2.14.1-0ubuntu3.6
+Architecture: i386
+Date: Tue Jan 13 14:30:39 2015
+SourcePackage: qemu
+UpgradeStatus: No upgrade log present (probably fresh install)
+
+
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+Workaround is to 'fallocate'. Problem seems to be linked to files with sparse holes in them. 
+
+
+
+verified this fails as described on vivid:
+$ dpkg-query --show qemu-utils
+qemu-utils	1:2.1+dfsg-11ubuntu1
+
+and also on trusty.
+
+$ dpkg-query --show qemu-utils
+qemu-utils	2.0.0+dfsg-2ubuntu1.10
+
+
+Does it also fail with the qemu from
+https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream ?
+(This isn't quite git head, but it is qemu v2.2)
+
+
+Went ahead and tested - it is in fact fixed in the v2.2 version.
+
+qemu is 2.5 in 16.04 and 2.6.1 in Zesty, so this is presumably Fix Released now. If incorrect, please explain and reopen.
+
diff --git a/results/classifier/105/socket/1450881 b/results/classifier/105/socket/1450881
new file mode 100644
index 00000000..6d498fba
--- /dev/null
+++ b/results/classifier/105/socket/1450881
@@ -0,0 +1,125 @@
+assembly: 0.971
+socket: 0.965
+boot: 0.957
+device: 0.955
+instruction: 0.950
+network: 0.940
+other: 0.938
+graphic: 0.930
+semantic: 0.925
+vnc: 0.908
+KVM: 0.893
+mistranslation: 0.880
+
+qemu-system-sparc MUTEX_HELD assert and libC lock errors
+
+Here I am cross-posting a comment I made on Artyom's blog.  Atar responded that he "fixed these issues for some customers".  I hoped that opening a bug to the opensource project might help develop the solution for the public domain.
+
+I now have a mostly-working Solaris 6 emulation, with great thanks to the valuable information in Artyom's blog, brezular.com, and the QEMU/Solaris 4.14 wikibook.
+
+setup detail;
+QEMU (present git snapshot, reports --version 2.2.92)
+-M SS-20, openboot/proprietary prom
+
+# uname -a
+SunOS emu0 5.6 Generic_105181-33 sun4m sparc SUNW,SPARCstation-20
+
+I continue to have a problem, which I have found others posted in blog comments, but have not seen a resolution yet.
+
+# /etc/init.d/init.dmi start
+Run-time error, libC:
+Trying to release a lock that was not acquired in this thread
+(repeat above 1x)
+Abort - core dumped
+
+as well as:
+Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766
+
+which prints to the console periodically when "dmispd" is running.
+
+Yes, this is a known issue which I can reproduce using a Solaris installation. I still have a few outstanding bugs on my list to do before I can start looking into this one, but I will keep this bug up to date as/when I can start work on it - apologies for not being able to be more specific than this at the moment.
+
+
+Hi all,
+I also have this issue with my sparcstation installation :
+
+Emulated OS				: 	SunOS 5.5.1
+Emulated Processor			: 	sparc
+Host machine OS			:	Linux RED HAT
+
+Do you manage to fix it ?
+
+Not yet - things have been made much harder now as my original test image tends to hang for long periods of time instead of giving the MUTEX_HELD error. If you have an image that you would be willing to share for debugging, please get in touch via email and I'll try and take a look.
+
+Proposed patch posted to mailing list: https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg01645.html - please test and report back.
+
+
+re:
+diff --git a/target-sparc/translate.c b/target-sparc/translate.c
+index 58572c3..7998ff5 100644
+...
+-                        tcg_gen_qemu_ld8s(cpu_val, cpu_addr, dc->mem_idx);
++                        tcg_gen_qemu_ld8u(cpu_val, cpu_addr, dc->mem_idx);
+
+I confirmed this patch resolves MUTEX_HELD errors on a minimal testcase
+solaris 6 image.
+Thank you!
+
+On Mon, Apr 11, 2016 at 7:03 AM, Mark Cave-Ayland <
+<email address hidden>> wrote:
+
+> Proposed patch posted to mailing list:
+> https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg01645.html -
+> please test and report back.
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1450881
+>
+> Title:
+>   qemu-system-sparc MUTEX_HELD assert and libC lock errors
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Here I am cross-posting a comment I made on Artyom's blog.  Atar
+>   responded that he "fixed these issues for some customers".  I hoped
+>   that opening a bug to the opensource project might help develop the
+>   solution for the public domain.
+>
+>   I now have a mostly-working Solaris 6 emulation, with great thanks to
+>   the valuable information in Artyom's blog, brezular.com, and the
+>   QEMU/Solaris 4.14 wikibook.
+>
+>   setup detail;
+>   QEMU (present git snapshot, reports --version 2.2.92)
+>   -M SS-20, openboot/proprietary prom
+>
+>   # uname -a
+>   SunOS emu0 5.6 Generic_105181-33 sun4m sparc SUNW,SPARCstation-20
+>
+>   I continue to have a problem, which I have found others posted in blog
+>   comments, but have not seen a resolution yet.
+>
+>   # /etc/init.d/init.dmi start
+>   Run-time error, libC:
+>   Trying to release a lock that was not acquired in this thread
+>   (repeat above 1x)
+>   Abort - core dumped
+>
+>   as well as:
+>   Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766
+>
+>   which prints to the console periodically when "dmispd" is running.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1450881/+subscriptions
+>
+
+
+Excellent - thanks once again for all your help!
+
+Fix is included in the 2.6.0-rc2 release.
+
diff --git a/results/classifier/105/socket/1463812 b/results/classifier/105/socket/1463812
new file mode 100644
index 00000000..a9ed0db4
--- /dev/null
+++ b/results/classifier/105/socket/1463812
@@ -0,0 +1,190 @@
+socket: 0.867
+graphic: 0.861
+instruction: 0.854
+device: 0.848
+assembly: 0.840
+semantic: 0.837
+vnc: 0.831
+KVM: 0.828
+boot: 0.807
+other: 0.789
+network: 0.786
+mistranslation: 0.724
+
+qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+
+copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again.
+Run the image on qemu 1.5.3, no problem.
+
+Hi,
+  Can you add some details about your host and guest please:
+    1) What's your host system? (ppc64 or x86? which os?)
+    2) What's the guest disk image format - raw or qcow2?
+    3) could you try some of the versions in between 2.3.0 and 1.5.3 ?
+    4) Is it just the 5.9 image that has problems or is it more general?
+
+Dave
+
+Oh and:
+   5) What's your disk image stored on - local disk or network?
+   6) WHat's the command line you're using for your guest
+
+2.3.0 running RHEL7,1 little-endian version no problem.
+
+I'm using: qemu-system-ppc64 -hda ppcrhel5.img -cpu POWER7 -machine type=pseries,usb=off -m 768 -nographic -net nic -net tap,ifname=tap0,script=no
+It's on local disk.
+same as on qemu 1.5.3.
+> Date: Wed, 10 Jun 2015 12:29:56 +0000
+> From: <email address hidden>
+> To: <email address hidden>
+> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Oh and:
+>    5) What's your disk image stored on - local disk or network?
+>    6) WHat's the command line you're using for your guest
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1463812
+> 
+> Title:
+>   qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again.
+>   Run the image on qemu 1.5.3, no problem.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions
+ 		 	   		  
+
+I'm running qemu 2.3.0 on a RHEL5.3/x86 box, 1.5.3 on a CentOS6.6/x86 box.
+
+> Date: Wed, 10 Jun 2015 12:25:22 +0000
+> From: <email address hidden>
+> To: <email address hidden>
+> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Hi,
+>   Can you add some details about your host and guest please:
+>     1) What's your host system? (ppc64 or x86? which os?)
+>     2) What's the guest disk image format - raw or qcow2?
+>     3) could you try some of the versions in between 2.3.0 and 1.5.3 ?
+>     4) Is it just the 5.9 image that has problems or is it more general?
+> 
+> Dave
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1463812
+> 
+> Title:
+>   qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again.
+>   Run the image on qemu 1.5.3, no problem.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions
+ 		 	   		  
+
+if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't know if the problem
+is with the qemu 2.3.0 or with running it on the older host?  Please run the two qemus on the same host
+and see if the problem follows the host or the qemu version.
+
+Also, just checking;  is that 64bit x86 host or 32 ?
+
+
+and I've just seen your older bug report - https://bugs.launchpad.net/qemu/+bug/1289898 - isn't this exactly the same problem? Why open a new bug?
+
+Both X86_64.
+
+> Date: Wed, 10 Jun 2015 16:56:35 +0000
+> From: <email address hidden>
+> To: <email address hidden>
+> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> if you're running the 2.3.0 on the RHEL5.3 and the 1.53 on CentOS6.6 we can't know if the problem
+> is with the qemu 2.3.0 or with running it on the older host?  Please run the two qemus on the same host
+> and see if the problem follows the host or the qemu version.
+> 
+> Also, just checking;  is that 64bit x86 host or 32 ?
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1463812
+> 
+> Title:
+>   qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again.
+>   Run the image on qemu 1.5.3, no problem.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions
+ 		 	   		  
+
+I already forgot the old one: I got a 2.3.0 qemu installed on the RHEL 5.3 machine, and since this machine has more disk spaces than the CentOS6.4 (now 6.6), so I copied again all emulated machine images from CentOS to RHEL machine, and started to build a new one for RHEL7.1 LE for Power on the 2.3.0, and found it's working quite well, and also other emulated machines are all working fine (mips32, mips32el, mips64el, armv7) on the 2.3.0.Then I just tried to use the RHEL5.9 Power qemu machine, but found root filesystem corrupted, copied from OS image from CentOS, start the qemu machine, again, root filesystem damaged. So, I created the bug report,  didn't think about old bug report I made. So, now it's clear, it's on the RHEL5.3 machine, multiple qemu versions have issue with RHEL5.9 for power.
+
+> Date: Wed, 10 Jun 2015 16:58:40 +0000
+> From: <email address hidden>
+> To: <email address hidden>
+> Subject: [Bug 1463812] Re: qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> and I've just seen your older bug report -
+> https://bugs.launchpad.net/qemu/+bug/1289898 - isn't this exactly the
+> same problem? Why open a new bug?
+> 
+> -- 
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1463812
+> 
+> Title:
+>   qemu-system-ppc64 V2.30 cause RHEL5.9 disk corruption
+> 
+> Status in QEMU:
+>   New
+> 
+> Bug description:
+>   copied the RHEL5.9 power disk image from qemu 1.5.3, run it under qemu 2.3.0, corrupted; copied again, run, corrupted again.
+>   Run the image on qemu 1.5.3, no problem.
+> 
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1463812/+subscriptions
+ 		 	   		  
+
+I built 2.3.0 on CentOS 6.6 machine, and run the RHEL5.9 using the new qemu-system-64 ,and gets the same issue as 2.3.0 on RHEL5.3:
+
+Checking filesystems
+Checking all file systems.
+[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda5
+/: Resize inode not valid.
+
+/: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
+        (i.e., without -a or -p options)
+[FAILED]
+
+As I stated before on the CentOS6.6, the qemu 1.5.3 running the RHEL5.9 for power is ok. That proves it's not because of RHEL5.3 machine that fs is corrupted, it's the newer qemu for power emulation has issue to run big-endian version of RHEL.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+It seems to me that no one has really looked into the matter, I can't find any comments,that this issue has been worked on.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1542965 b/results/classifier/105/socket/1542965
new file mode 100644
index 00000000..334250bd
--- /dev/null
+++ b/results/classifier/105/socket/1542965
@@ -0,0 +1,23 @@
+socket: 0.954
+device: 0.830
+network: 0.805
+mistranslation: 0.708
+instruction: 0.621
+other: 0.485
+graphic: 0.481
+vnc: 0.462
+boot: 0.365
+semantic: 0.345
+assembly: 0.085
+KVM: 0.032
+
+Failed to set NBD socket ubuntu 15.10 & nbd client 3.10
+
+Running command to mount using nbd fails
+with error
+/build/qemu-YZq7uh/qemu-2.3+dfsg/nbd.c:nbd_init():L670: Failed to set NBD socket
+
+Can you still reproduce this with the latest version of upstream QEMU? Please also provide the exact steps (e.g. command line options) that you were using here.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1567 b/results/classifier/105/socket/1567
new file mode 100644
index 00000000..d96fcb4c
--- /dev/null
+++ b/results/classifier/105/socket/1567
@@ -0,0 +1,47 @@
+socket: 0.870
+instruction: 0.779
+device: 0.685
+vnc: 0.639
+graphic: 0.573
+network: 0.498
+semantic: 0.398
+mistranslation: 0.350
+assembly: 0.303
+boot: 0.188
+other: 0.171
+KVM: 0.142
+
+On windows, storage daemon does not support daemonize
+Description of problem:
+Presently, in order to run qemu-storage-daemon on windows, one has to login and run it in a terminal window that is kept open.
+
+#
+Steps to reproduce:
+just run the command
+Additional information:
+https://gitlab.com/qemu-project/qemu/-/blob/master/storage-daemon/qemu-storage-daemon.c#L299
+```
+        case OPTION_DAEMONIZE:
+            if (os_set_daemonize(true) < 0) {
+                /*
+                 * --daemonize is parsed before monitor_init_globals(), so
+                 * error_report() does not work yet
+                 */
+                fprintf(stderr, "--daemonize not supported in this build\n");
+                exit(EXIT_FAILURE);
+            }
+```
+https://gitlab.com/qemu-project/qemu/-/blob/master/include/sysemu/os-win32.h#L114
+```
+static inline int os_set_daemonize(bool d)
+{
+    if (d) {
+        return -ENOTSUP;
+    }
+    return 0;
+}
+```
+
+- Recently Marc has added windows socket support   
+  20230313 marcandre.lureau [PULL 00/25] Win socket patches  
+  https://lore.kernel.org/qemu-devel/20230313114335.424093-1-marcandre.lureau@redhat.com/
diff --git a/results/classifier/105/socket/1572329 b/results/classifier/105/socket/1572329
new file mode 100644
index 00000000..26dbe1dd
--- /dev/null
+++ b/results/classifier/105/socket/1572329
@@ -0,0 +1,104 @@
+socket: 0.961
+semantic: 0.956
+other: 0.955
+assembly: 0.947
+network: 0.945
+boot: 0.945
+instruction: 0.942
+graphic: 0.939
+mistranslation: 0.925
+device: 0.921
+vnc: 0.893
+KVM: 0.883
+
+ARM bootloader does not set r0 to 0
+
+# arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb
+
+My code shows r0 = 0x31 while it should be 0.
+
+
+
+On 19 April 2016 at 23:34, Sylvain <email address hidden> wrote:
+> # arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel
+> kernel.bin -serial stdio -dtb rpi2.dtb
+>
+> My code shows r0 = 0x31 while it should be 0.
+
+Hi. Thanks for this bug report and the patch. In order
+for us to be able to use your patch, we'll need you to
+provide a signed-off-by line, which tells us you have
+the legal right to submit it and are happy for us to
+include it in QEMU under QEMU's licensing terms.
+(You can look at
+http://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
+if you want more details.)
+
+You can provide a signoff just by replying to this email
+with a line which reads
+"Signed-off-by: Your Name <your.email@here>".
+
+A couple of notes: this bug only affects boards which
+have a write_board_setup function, which means only
+highbank/midway, raspi2, and xilinx_zynq; that's probably
+why we didn't spot it earlier.
+
+thanks
+-- PMM
+
+
+Signed-off-by: Sylvain Garrigues <email address hidden>
+
+Fix link register patch follows:
+
+diff --git a/hw/arm/boot.c b/hw/arm/boot.c
+index 5975fbf..5876945 100644
+--- a/hw/arm/boot.c
++++ b/hw/arm/boot.c
+@@ -68,7 +68,7 @@ static const ARMInsnFixup bootloader_aarch64[] = {
+  */
+ 
+ static const ARMInsnFixup bootloader[] = {
+-    { 0xe28fe008 }, /* add     lr, pc, #8 */
++    { 0xe28fe004 }, /* add     lr, pc, #4 */
+     { 0xe51ff004 }, /* ldr     pc, [pc, #-4] */
+     { 0, FIXUP_BOARD_SETUP },
+ #define BOOTLOADER_NO_BOARD_SETUP_OFFSET 3
+
+
+> Le 20 avr. 2016 à 16:21, Peter Maydell <email address hidden> a écrit :
+> 
+> On 19 April 2016 at 23:34, Sylvain <email address hidden> wrote:
+>> # arm-softmmu/qemu-system-arm -M raspi2 -m 1024 -smp 4 -kernel
+>> kernel.bin -serial stdio -dtb rpi2.dtb
+>> 
+>> My code shows r0 = 0x31 while it should be 0.
+> 
+> Hi. Thanks for this bug report and the patch. In order
+> for us to be able to use your patch, we'll need you to
+> provide a signed-off-by line, which tells us you have
+> the legal right to submit it and are happy for us to
+> include it in QEMU under QEMU's licensing terms.
+> (You can look at
+> http://wiki.qemu.org/Contribute/SubmitAPatch#Patch_emails_must_include_a_Signed-off-by:_line
+> if you want more details.)
+> 
+> You can provide a signoff just by replying to this email
+> with a line which reads
+> "Signed-off-by: Your Name <your.email@here>".
+> 
+> A couple of notes: this bug only affects boards which
+> have a write_board_setup function, which means only
+> highbank/midway, raspi2, and xilinx_zynq; that's probably
+> why we didn't spot it earlier.
+> 
+> thanks
+> -- PMM
+
+
+
+Fix committed: b4850e5ae9607f9f31932
+
+
+Should be part of QEMU 2.6 ==> Fix released
+
diff --git a/results/classifier/105/socket/1585432 b/results/classifier/105/socket/1585432
new file mode 100644
index 00000000..f50e0dba
--- /dev/null
+++ b/results/classifier/105/socket/1585432
@@ -0,0 +1,45 @@
+socket: 0.883
+graphic: 0.663
+mistranslation: 0.567
+device: 0.550
+network: 0.545
+instruction: 0.459
+semantic: 0.430
+vnc: 0.410
+other: 0.280
+boot: 0.234
+assembly: 0.136
+KVM: 0.117
+
+magnum coe-service-list  returns error
+
+magnum running on centos7,
+
+I didn't create any services on k8s cluster,
+
+but I got the result as follows:
+
+[root@localhost ~(keystone_admin)]# magnum coe-service-list --bay k8sbay3
+ERROR: Field `ports[0][node_port]' cannot be None (HTTP 500) (Request-ID: req-c66b68dd-5437-47fa-a389-7cb56a262fa5)
+
+I assume you want this to be in the Magnum project, not qemu...?
+
+The coe-service-list command will be removed: https://review.openstack.org/#/c/258454/ , so I am going to close this bug.
+
+Following is my local fix, hope it helps
+
+diff --git a/magnum/objects/service.py b/magnum/objects/service.py
+index 12088a7..04040ff 100644
+--- a/magnum/objects/service.py
++++ b/magnum/objects/service.py
+@@ -39,7 +39,7 @@ class Service(base.MagnumPersistentObject, base.MagnumObject,
+         'labels': fields.DictOfStringsField(nullable=True),
+         'selector': fields.DictOfStringsField(nullable=True),
+         'ip': fields.StringField(nullable=True),
+-        'ports': magnum_fields.ListOfDictsField(nullable=True),
++        'ports': fields.ListOfDictOfNullableStringsField(nullable=True),
+         'manifest_url': fields.StringField(nullable=True),
+         'manifest': fields.StringField(nullable=True),
+     }
+
+
diff --git a/results/classifier/105/socket/1586756 b/results/classifier/105/socket/1586756
new file mode 100644
index 00000000..b5e7d3c9
--- /dev/null
+++ b/results/classifier/105/socket/1586756
@@ -0,0 +1,141 @@
+socket: 0.788
+mistranslation: 0.784
+vnc: 0.782
+instruction: 0.766
+device: 0.761
+network: 0.759
+KVM: 0.714
+graphic: 0.697
+semantic: 0.671
+assembly: 0.651
+boot: 0.623
+other: 0.619
+
+"-serial unix:" option of qemu-system-arm is broken in qemu 2.6.0
+
+I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 works fine).
+Occasionally, a part of the output of qemu disappears in the bug.
+
+It looks like following commit is the cause:
+
+char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange <email address hidden>)
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9
+
+In this commit, UNIX socket is set to non-blocking mode, but qemu_chr_fe_write function doesn't handle EAGAIN.
+You should fix code like that:
+
+---
+diff --git a/qemu-char.c b/qemu-char.c
+index b597ee1..0361d78 100644
+--- a/qemu-char.c
++++ b/qemu-char.c
+@@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, const uint8_t *buf, int
+ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
+ {
+     int ret;
++    int offset = 0;
+ 
+     if (s->replay && replay_mode == REPLAY_MODE_PLAY) {
+         int offset;
+@@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
+     }
+ 
+     qemu_mutex_lock(&s->chr_write_lock);
+-    ret = s->chr_write(s, buf, len);
++
++    while (offset < len) {
++    retry:
++        ret = s->chr_write(s, buf, len);
++        if (ret < 0 && errno == EAGAIN) {
++            g_usleep(100);
++            goto retry;
++        }
++
++        if (ret <= 0) {
++            break;
++        }
++
++        offset += ret;
++    }
+ 
+     if (ret > 0) {
+         qemu_chr_fe_write_log(s, buf, ret);
+---
+
+Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9".
+
+I'm unable to reproduce the problem mentioned myself, and code inspection shows no problem for x86_64 at least.
+
+Specifically hw/char/serial.c has a   serial_xmit() method which calls qemu_chr_fe_write(), and if it sees EAGAIN, it sets up a event notification to re-try the write later.
+
+Can you provide the full QEMU command line you are using, include the emulator binary.
+
+Looking at the code in 2.5.0, the qemu_chr_fe_write method would see EAGAIN too, because the tcp_chr_accept() method would always set the newly connected client to non-blocking mode. So thre's no obvious change in behaviour between 2.5 and 2.6 wrt to blocking sockets.
+
+Sorry, this issue only occur in qemu-system-arm (vexpress-a9).
+In hw/char/pl011.c, qemu_chr_fe_write function is called directly and EAGAIN isn't handled.
+
+http://git.qemu.org/?p=qemu.git;a=blob;f=hw/char/pl011.c;h=210c87b4c2bd000d80c359ca5c05d43c64210677;hb=bfc766d38e1fae5767d43845c15c79ac8fa6d6af#l148
+
+So I use following a patch.
+
+----
+diff --git a/hw/char/pl011.c b/hw/char/pl011.c
+index c0fbf8a..6e29db8 100644
+--- a/hw/char/pl011.c
++++ b/hw/char/pl011.c
+@@ -146,7 +146,7 @@ static void pl011_write(void *opaque, hwaddr offset,
+         /* ??? Check if transmitter is enabled.  */
+         ch = value;
+         if (s->chr)
+-            qemu_chr_fe_write(s->chr, &ch, 1);
++            qemu_chr_fe_write_all(s->chr, &ch, 1);
+         s->int_level |= PL011_INT_TX;
+         pl011_update(s);
+         break;
+----
+
+qemu_chr_fe_write_all function handles EAGAIN.
+
+I wrote small code which reproduces this issue.
+
+https://bitbucket.org/redcap97/puts-hello-x80000-armv7-kernel/downloads/puts-HELLO-x80000
+
+Above binary outputs "HELLO!" 80000 times to UART.
+
+# Please execute in terminal
+socat unix-listen:a.sock stdout | tee actual
+
+# Please execute in another terminal
+qemu-system-arm -M vexpress-a9 -nographic -kernel puts-HELLO-x80000 -serial unix:a.sock
+
+# Check results
+yes 'HELLO!' | head -n 80000 > expected
+diff -u expected actual
+
+Occasionally, a part of the output of qemu disappears.
+
+
+Source code of the binary
+https://bitbucket.org/redcap97/puts-hello-x80000-armv7-kernel/src
+
+
+> Looking at the code in 2.5.0, the qemu_chr_fe_write method would see EAGAIN too, because the tcp_chr_accept() method would always set the newly connected client to non-blocking mode. So thre's no obvious change in behaviour between 2.5 and 2.6 wrt to blocking sockets.
+
+It looks like tcp_chr_accept function isn't called in above command.
+tcp_chr_wait_connected function is called instead.
+
+So the socket is blocking mode and doesn't return EAGAIN in Qemu 2.5.0.
+
+Ok, now it makes more sense. You are using the socket chardev in TCP outgoing client mode, which used to be blocking by default. In 2.6 this switched to match TCP server mode,  in wich the incoming client was always in non-blocking mode. 
+
+IOW, this arm code was already broken in 2.5 just depending on which chardev config was used.
+
+So, we'll need to put a fix in pl011_write.  I'm unsure whether use writeall() is the correct behaviour - I'll come to other serial backends.
+
+Fix posted https://lists.gnu.org/archive/html/qemu-devel/2016-08/msg00684.html
+
+Fix has been committed here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=6ab3fc32ea640026726b
+... and been released with QEMU version 2.8
+
diff --git a/results/classifier/105/socket/1612908 b/results/classifier/105/socket/1612908
new file mode 100644
index 00000000..48c520d4
--- /dev/null
+++ b/results/classifier/105/socket/1612908
@@ -0,0 +1,25 @@
+socket: 0.854
+network: 0.686
+mistranslation: 0.622
+device: 0.614
+graphic: 0.547
+instruction: 0.530
+semantic: 0.481
+other: 0.239
+vnc: 0.187
+boot: 0.149
+assembly: 0.098
+KVM: 0.054
+
+qom-[list,tree,get,set] don't accept tcp endpoint arg
+
+Hi, 
+
+I'm using origin/master [6bbbb0ac13...]. When I run any of the commands in 'qemu/scripts/qmp/qom-[list,tree,get,set]', the help text says that it can connect to a QEMU instance by passing either a path to a unix socket or a tcp endpoint in the format "host:port". The unix socket variant works but the tcp endpoint variant does not. QEMUMonitorProtocol accepts either a string (unix socket) or a tuple (host,port). None of the qom-* scripts actually massage the '-s' argument into a tuple. 
+
+I have a patch to fix this issue that I can submit to the developer list.
+
+Hi! Triaging old bug tickets ... is this still an issue with the latest version of QEMU? If you've got a patch for this ready, please send it to the qemu-devel mailing list!
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1663079 b/results/classifier/105/socket/1663079
new file mode 100644
index 00000000..a8434885
--- /dev/null
+++ b/results/classifier/105/socket/1663079
@@ -0,0 +1,40 @@
+socket: 0.980
+network: 0.964
+device: 0.847
+instruction: 0.808
+graphic: 0.760
+other: 0.671
+mistranslation: 0.595
+semantic: 0.547
+vnc: 0.430
+boot: 0.384
+assembly: 0.224
+KVM: 0.052
+
+socket network not working
+
+The socket network type is no longer working in 2.8.0.
+
+When trying to establish a network between 2 qemu instances:
+
+The listening host:
+qemu-system-x86_64 -netdev socket,id=in0,listen=127.0.0.1:9999 -device virtio-net-pci,netdev=in0
+
+works fine, but for the second one:
+
+qemu-system-x86_64 -netdev socket,id=in0,connect=127.0.0.1:9999 -device virtio-net-pci,netdev=in0
+
+It fails with:
+
+qemu-system-x86_64: -device virtio-net-pci,netdev=in0: Property 'virtio-net-device.netdev' can't find value 'in0'
+
+netstat shows a new connection to port 9999 in time_wait state every time.
+
+host: kernel 4.4.38, 64bits.
+
+It was working fine with previous version.
+
+Works for me with the current QEMU master branch... can you still reproduce the issue with the latest version of QEMU (either v4.2 or the master branch)?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1673373 b/results/classifier/105/socket/1673373
new file mode 100644
index 00000000..88ee1a5f
--- /dev/null
+++ b/results/classifier/105/socket/1673373
@@ -0,0 +1,123 @@
+socket: 0.959
+other: 0.957
+semantic: 0.948
+mistranslation: 0.938
+assembly: 0.937
+device: 0.932
+instruction: 0.930
+vnc: 0.925
+graphic: 0.920
+boot: 0.916
+network: 0.916
+KVM: 0.898
+
+qemu -version output is incorrect with configure --with-pkgversion
+
+Since qemu v2.7.0, up to the current master
+(1883ff34b540daacae948f493b0ba525edf5f642)
+the pkgversion feature appears to have a bug:
+
+$ ./configure --target-list=x86_64-softmmu --with-pkgversion=foo
+
+Results in this output:
+
+$ x86_64-softmmu/qemu-system-x86_64 -version
+QEMU emulator version 2.8.90(foo)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+This appears to have been introduced in:
+
+67a1de0d19 Makefile: Derive "PKGVERSION" from "git describe" by default
+
+The previous commit (077de81a4c) produces this output:
+
+$ x86_64-softmmu/qemu-system-x86_64 -version
+QEMU emulator version 2.6.50 (foo), Copyright (c) 2003-2008 Fabrice Bellard
+
+On 16 March 2017 at 09:00, Jordan Justen <email address hidden> wrote:
+> This appears to have regressed in 67a1de0d19.
+>
+> When the configure --with-pkgversion=foo option is used, the output
+> from -version will look like:
+>
+> QEMU emulator version 2.8.90(foo)
+> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+>
+> After this patch, it will be:
+>
+> QEMU emulator version 2.8.90 (foo)
+> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+>
+> Cc: Paolo Bonzini <email address hidden>
+> Cc: Fam Zheng <email address hidden>
+> Fixes: https://bugs.launchpad.net/bugs/1673373
+> Cc: <email address hidden>
+> Signed-off-by: Jordan Justen <email address hidden>
+> ---
+>  Makefile  | 2 +-
+>  configure | 2 +-
+>  vl.c      | 2 +-
+>  3 files changed, 3 insertions(+), 3 deletions(-)
+>
+> diff --git a/Makefile b/Makefile
+> index 1c4c04f6f2..c9df119798 100644
+> --- a/Makefile
+> +++ b/Makefile
+> @@ -289,7 +289,7 @@ qemu-version.h: FORCE
+>                         printf '"$(PKGVERSION)"\n'; \
+>                 else \
+>                         if test -d .git; then \
+> -                               printf '" ('; \
+> +                               printf '"('; \
+>                                 git describe --match 'v*' 2>/dev/null | tr -d '\n'; \
+>                                 if ! git diff-index --quiet HEAD &>/dev/null; then \
+>                                         printf -- '-dirty'; \
+> diff --git a/configure b/configure
+> index 99d8bece70..e94b06b5fc 100755
+> --- a/configure
+> +++ b/configure
+> @@ -1004,7 +1004,7 @@ for opt do
+>    ;;
+>    --disable-blobs) blobs="no"
+>    ;;
+> -  --with-pkgversion=*) pkgversion=" ($optarg)"
+> +  --with-pkgversion=*) pkgversion="($optarg)"
+>    ;;
+>    --with-coroutine=*) coroutine="$optarg"
+>    ;;
+> diff --git a/vl.c b/vl.c
+> index 0b4ed5241c..3e60e61905 100644
+> --- a/vl.c
+> +++ b/vl.c
+> @@ -1904,7 +1904,7 @@ static void main_loop(void)
+>
+>  static void version(void)
+>  {
+> -    printf("QEMU emulator version " QEMU_VERSION QEMU_PKGVERSION "\n"
+> +    printf("QEMU emulator version " QEMU_VERSION " " QEMU_PKGVERSION "\n"
+>             QEMU_COPYRIGHT "\n");
+>  }
+
+This is not the only place where we assemble a string from
+QEMU_VERSION QEMU_PKGVERSION, so if you want to change from the
+original approach where QEMU_PKGVERSION had a space in it then
+you need to change the other places too.
+
+Also it looks like we return QEMU_PKGVERSION as part of the
+QMP qmp_query_version() code, so we should check to see what
+the expected behaviour there is regarding having the space
+or not.
+
+I think when I wrote those printfs I was expecting that
+QEMU_PKGVERSION might be a "-something" kind of string,
+and so did whoever wrote the commit log for 67a1de0d19.
+However looking at git history it seems to have always been
+a " (something)" format, so obviously some confusion here...
+
+thanks
+-- PMM
+
+
+This should be fixed now in QEMU 2.12:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7e563bfb8a5104ff0e
+
diff --git a/results/classifier/105/socket/1700380 b/results/classifier/105/socket/1700380
new file mode 100644
index 00000000..33b4dd6f
--- /dev/null
+++ b/results/classifier/105/socket/1700380
@@ -0,0 +1,34 @@
+instruction: 0.971
+socket: 0.942
+network: 0.935
+semantic: 0.884
+device: 0.878
+graphic: 0.869
+mistranslation: 0.842
+other: 0.827
+vnc: 0.822
+boot: 0.606
+assembly: 0.533
+KVM: 0.359
+
+commit snapshot image got Permission denied error
+
+qemu 2.9.0, adm64, start image with -snapshot param, make some changes in the image, then:
+
+$telnet localhost 7000
+
+(qemu) commit virtio0
+'commit' error for 'virtio0': Permission denied
+
+Nerver met this problem before, commit is ok. I recently compiled v2.9.0, so is there some new param in qemu-qemu-system-x86_64 to avoid commit Permission denied?
+
+Regards.
+
+only the winxp guest image get this error, linux guest do not.
+
+v2.9.0 must start the image with full path can commit the snapshot changes, <v2.3 no need to.
+
+close this report.
+
+Closing, according to comment #2
+
diff --git a/results/classifier/105/socket/1708462 b/results/classifier/105/socket/1708462
new file mode 100644
index 00000000..24332191
--- /dev/null
+++ b/results/classifier/105/socket/1708462
@@ -0,0 +1,39 @@
+socket: 0.699
+device: 0.692
+network: 0.634
+instruction: 0.578
+mistranslation: 0.570
+semantic: 0.570
+graphic: 0.566
+other: 0.561
+boot: 0.496
+vnc: 0.487
+KVM: 0.461
+assembly: 0.378
+
+Support Python 3 to build
+
+Currently qemu's configure requires Python 2 to build.  As Python 2 is rapidly approaching its EOL, it should be possible to build qemu with Python 3.
+
+Python 2 EOL is in 2020 so there is a fair amount of time.
+
+QEMU is transitioning to support both Python 2.6+ and 3 but most Python code has not been converted yet.
+
+You are welcome to contribute patches:
+https://wiki.qemu.org/index.php/Contribute/SubmitAPatch
+
+> Python 2 EOL is in 2020 so there is a fair amount of time.
+
+Not as much time as you might think. Even well before that time, any new releases of long life and/or enterprise distros are likely to choose to skip py2 by default, as it will be EOL long before the distro itself EOLs. 
+
+Two patches series posted in Aug last year:
+
+https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg03642.html
+https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg06528.html
+
+An updated series covering both of those, and also turning on tests
+
+https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg02978.html
+
+The series mentioned in comment #3 was merged in v2.12.0, see commit c21965a0c8b979c306e927f158257e5b0fa3a1f9.
+
diff --git a/results/classifier/105/socket/1721220 b/results/classifier/105/socket/1721220
new file mode 100644
index 00000000..d2d2b0ed
--- /dev/null
+++ b/results/classifier/105/socket/1721220
@@ -0,0 +1,49 @@
+socket: 0.988
+device: 0.961
+instruction: 0.953
+vnc: 0.839
+network: 0.777
+boot: 0.758
+graphic: 0.636
+KVM: 0.623
+semantic: 0.539
+mistranslation: 0.495
+other: 0.423
+assembly: 0.308
+
+qemu crashes with assertion error `!mr->container' failed
+
+Re-production steps:
+git clone today's qemu git tree (4th Oct 2017)
+./configure --target-list=ppc64-softmmu && make -j 8
+
+Run the device-crash-test from scripts folder, seeing the following error
+
+INFO: running test case: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm
+WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine bamboo,accel=kvm -device pcie-pci-bridge
+CRITICAL: failed: machine=bamboo binary=ppc64-softmmu/qemu-system-ppc64 device=pcie-pci-bridge accel=kvm
+CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine bamboo,accel=kvm -device pcie-pci-bridge
+CRITICAL: log: qemu-system-ppc64: /home/nasastry/qemu/memory.c:1699: memory_region_finalize: Assertion `!mr->container' failed.
+CRITICAL: log: warning: KVM does not support watchdog
+CRITICAL: exit code: -6
+
+I think this should be fixed by this patch here:
+https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg06696.html
+("hw/pci-bridge/pcie_pci_bridge: properly handle MSI unavailability case")
+
+With the mentioned patch not seeing the Abort.
+
+# ppc64-softmmu/qemu-system-ppc64 -S -machine bamboo,accel=kvm -device pcie-pci-bridge
+gtk initialization failed
+warning: KVM does not support watchdog
+
+Thanks!!
+
+As per previous comments, this bug was fixed by commit https://git.qemu.org/?p=qemu.git;a=commitdiff;h=d659d94013390238961fac741572306c95496bf5 (released in QEMU v2.11.0):
+
+commit d659d94013390238961fac741572306c95496bf5
+Author: Aleksandr Bezzubikov <email address hidden>
+Date:   Mon Sep 25 02:21:58 2017 +0300
+
+    hw/pci-bridge/pcie_pci_bridge: properly handle MSI unavailability case
+
diff --git a/results/classifier/105/socket/1721222 b/results/classifier/105/socket/1721222
new file mode 100644
index 00000000..c9bf172f
--- /dev/null
+++ b/results/classifier/105/socket/1721222
@@ -0,0 +1,32 @@
+socket: 0.971
+device: 0.969
+graphic: 0.938
+network: 0.884
+instruction: 0.868
+vnc: 0.859
+boot: 0.761
+semantic: 0.756
+mistranslation: 0.724
+other: 0.587
+KVM: 0.375
+assembly: 0.315
+
+qemu crashes with Assertion `fdctrl->dma' failed
+
+Re-production steps:
+git clone today's qemu git tree (4th Oct 2017)
+./configure --target-list=ppc64-softmmu && make -j 8
+
+Run the device-crash-test from scripts folder, seeing the following error
+
+
+INFO: running test case: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg
+WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine powernv,accel=tcg -device isa-fdc
+CRITICAL: failed: machine=powernv binary=ppc64-softmmu/qemu-system-ppc64 device=isa-fdc accel=tcg
+CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine powernv,accel=tcg -device isa-fdc
+CRITICAL: log: qemu-system-ppc64: hw/block/fdc.c:2703: isabus_fdc_realize: Assertion `fdctrl->dma' failed.
+CRITICAL: exit code: -6
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b3da551389c86ce214
+
diff --git a/results/classifier/105/socket/1721224 b/results/classifier/105/socket/1721224
new file mode 100644
index 00000000..f9274d71
--- /dev/null
+++ b/results/classifier/105/socket/1721224
@@ -0,0 +1,39 @@
+socket: 0.942
+device: 0.868
+instruction: 0.765
+mistranslation: 0.735
+semantic: 0.709
+graphic: 0.682
+vnc: 0.656
+network: 0.655
+boot: 0.505
+KVM: 0.324
+assembly: 0.292
+other: 0.278
+
+qemu crashes with Assertion `!bus->dma[0] && !bus->dma[1]' failed
+
+Re-production steps:
+git clone today's qemu git tree (4th Oct 2017)
+./configure --target-list=ppc64-softmmu && make -j 8
+
+Run the device-crash-test from scripts folder, seeing the following error
+
+INFO: running test case: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg
+WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine prep,accel=tcg -device i82374
+CRITICAL: failed: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg
+CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine prep,accel=tcg -device i82374
+CRITICAL: log: qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed.
+CRITICAL: exit code: -6
+
+v2 patch posted on list and waiting for review:
+
+https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04604.html
+[PATCHv3] dma/i82374: avoid double creation of i82374 device
+
+v4 patch posted:
+http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg06565.html
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4968a2c6edb7b46b127c
+
diff --git a/results/classifier/105/socket/1725267 b/results/classifier/105/socket/1725267
new file mode 100644
index 00000000..29a1ed91
--- /dev/null
+++ b/results/classifier/105/socket/1725267
@@ -0,0 +1,122 @@
+mistranslation: 0.939
+socket: 0.936
+device: 0.936
+instruction: 0.935
+assembly: 0.932
+other: 0.929
+semantic: 0.928
+graphic: 0.911
+boot: 0.909
+vnc: 0.895
+network: 0.886
+KVM: 0.855
+
+armeb regression since qemu version 2.8
+
+Hi,
+
+I have noticed a regression when I upgraded from qemu-armeb 2.7 to 2.8, and the problem is still present with version 2.10.1.
+
+I am using qemu for GCC validation, noticed problems with testcases involving atomics, I'm attaching here atomic-exchange-4.exe.
+
+# with 2.7:
+$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
+$ echo $?
+0
+# with 2.8, 2.10.1:
+$ qemu-armeb -cpu any -R 0 -L $PWD -E LD_LIBRARY_PATH=$PWD/lib $PWD/atomic-exchange-4.exe
+qemu: uncaught target signal 6 (Aborted) - core dumped
+Aborted (core dumped)
+$ echo $?
+134
+
+The source code is gcc/testsuite/gcc.dg/atomic-exchange-4.c
+
+Running with -d in_asm shows a difference early in the startup code:
+IN: _dl_sysdep_start
+[...]
+0x40a17790:  908ff103      addls	pc, pc, r3, lsl #2
+
+and then the next address is not the same with qemu 2.7 and 2.10.1
+
+I hope you have enough data/information to reproduce and confirm/fix the problem.
+
+Thanks
+
+
+
+
+
+
+
+Hi Christophe -- RTH posted a patchset yesterday which should fix this:
+https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg04809.html
+
+
+Oh, wait, different bug. Sorry for the noise...
+
+
+I rather suspect something is going wrong when the dynamic loader attempts to paw through the ELF auxiliary vector...
+
+
+Ah, that's a false positive. We flipped the order we put entries in the AUXV in commit 7c4ee5bcc82e64, so the code divergence is just because now _dl_sysdep_start is processing the entries in the opposite order to what it used to. (The "addls pc, pc, r3, lsl #2" is jumping into the jump table for the switch on different AUXV entry tags.) The traces converge again at 0x40817830.
+
+
+I think what's actually happening is that we're failing on one of the tests in main(). This would be much easier to diagnose if the test case code printed information about what it was doing and what the failed test case was...
+
+
+Indeed I wish GCC tests printed information rather than just calling abort()...
+
+I'll add some printfs and see what this says.
+
+
+I added printfs after each 'count++' statement, and here is what I got:
+
+qemu-2.7:
+ATOMIC_RELAXED OK
+ATOMIC_ACQUIRE OK
+ATOMIC_RELEASE OK
+ATOMIC_ACQ_REL OK
+ATOMIC_SEQ_CST OK
+ATOMIC_RELAXED OK
+ATOMIC_ACQUIRE OK
+ATOMIC_RELEASE OK
+ATOMIC_ACQ_REL OK
+ATOMIC_SEQ_CST OK
+ALL TESTS PASSED
+
+qemu-2.10.1:
+ATOMIC_RELAXED OK
+ATOMIC_ACQUIRE OK
+ATOMIC_RELEASE OK
+ATOMIC_ACQ_REL OK
+ATOMIC_SEQ_CST OK
+qemu: uncaught target signal 6 (Aborted) - core dumped
+
+
+
+
+
+
+On 20 October 2017 at 16:12, Christophe Lyon
+<email address hidden> wrote:
+> I'll add some printfs and see what this says.
+
+I had a dig further in the logs and I suspect that we're either
+doing the two halves of strexd or the two halves of ldrexd wrong
+for linux-user bigendian.
+
+thanks
+-- PMM
+
+
+https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg00155.html should fix this bug.
+
+
+Fix committed and will be in 2.11.0 rc0.
+
+
+Great, thanks!
+
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3448d47b3172015006b7
+
diff --git a/results/classifier/105/socket/1744009 b/results/classifier/105/socket/1744009
new file mode 100644
index 00000000..9e306555
--- /dev/null
+++ b/results/classifier/105/socket/1744009
@@ -0,0 +1,41 @@
+socket: 0.942
+device: 0.941
+network: 0.827
+graphic: 0.823
+semantic: 0.754
+instruction: 0.697
+mistranslation: 0.685
+vnc: 0.661
+other: 0.629
+boot: 0.338
+assembly: 0.293
+KVM: 0.217
+
+qemu for windows fails to use multicast socket as netdev
+
+My host OS is Windows 7 x64 SP1. I installed qemu for windows from https://qemu.weilnetz.de/w64/.The version is 2.10.1, qemu-w64-setup-20171006.exe. I run qemu with the following command:
+
+qemu-system-x86_64.exe -net nic -net socket,mcast=234.5.5.5:6000 disk1.qcow2
+
+It stopped with error:
+bind: Unknown error
+qemu-system-x86_64.exe: -net socket,mcast=234.5.5.5:6000: Device 'socket' could not be initialized
+
+Using the -netdev option has the same problem:
+qemu-system-x86_64.exe -netdev socket,id=hostnet0,mcast=234.5.5.5:6000 -device e1000,netdev=hostnet0 disk1.qcow2
+
+I tried many versions from https://qemu.weilnetz.de/w64/, but none of them could work.
+
+When I checked the source code, I think the problem is that on Microsoft Windows bind() can not use a multicast address.
+
+MSDN bind() reference
+https://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx
+seems to have indicated the point.
+
+I changed the net_socket_mcast_create() in net/socket.c, make it bind to htonl(INADDR_ANY). After compiling, it seems to work correctly.
+
+Have you ever tried to suggest your change as a patch to the qemu-devel mailing list? See:
+https://wiki.qemu.org/Contribute/SubmitAPatch
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1754605 b/results/classifier/105/socket/1754605
new file mode 100644
index 00000000..79439026
--- /dev/null
+++ b/results/classifier/105/socket/1754605
@@ -0,0 +1,35 @@
+socket: 0.980
+graphic: 0.787
+device: 0.701
+instruction: 0.586
+semantic: 0.436
+mistranslation: 0.408
+vnc: 0.396
+network: 0.375
+boot: 0.336
+other: 0.235
+KVM: 0.200
+assembly: 0.129
+
+ppc64 migration bad_dest test is failed with failed to connect to socket
+
+On ppc64le machine the following test failed.
+
+# QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 tests/migration-test V=1
+/ppc64/migration/deprecated: OK
+/ppc64/migration/bad_dest: qemu-system-ppc64: Failed to connect socket: Connection refused
+OK
+/ppc64/migration/postcopy/unix: OK
+
+Head is at f6d81cdec807bb85325afedb536b17c5331483c7
+configured with options: configure --target-list=ppc64-softmmu
+
+This test case is added through 2c9bb29703caa8fd31078cc38b3b53762557c27c
+
+This is fixed by 'tests: Silence migration-test 'bad' test' which I posted a few days ago; hopefully I'll send a pull with it today
+
+Thank you very much for your quick reply.
+
+David's patch fixing this went in as commit f96d6651e4b7cb8a8e91, which will have been in the 3.0 release.
+
+
diff --git a/results/classifier/105/socket/1756 b/results/classifier/105/socket/1756
new file mode 100644
index 00000000..28bdf9b0
--- /dev/null
+++ b/results/classifier/105/socket/1756
@@ -0,0 +1,56 @@
+socket: 0.802
+instruction: 0.791
+graphic: 0.771
+device: 0.754
+network: 0.646
+vnc: 0.558
+semantic: 0.474
+other: 0.437
+assembly: 0.430
+mistranslation: 0.423
+boot: 0.381
+KVM: 0.258
+
+qemu8-user on Linux: SIGSEGV because brk(NULL) does not exist
+Description of problem:
+On Linux, the return value of the system call brk(NULL) need not point to a page that exists.
+If so, then qemu8-user will generate SIGSEGV at the next call to brk() with a higher value,
+because qemu8 believes that it should maintain contiguous .bss with bytes of value 0.
+Thus qemu8-user so calls `memset(g2h_untagged(target_brk), 0, brk_page - target_brk);
+in do_brk() at ../linux-user/syscall.c:867, and this generates SIGSEGV at
+the non-existent page that covers brk(NULL).
+
+Instead, the safest thing to do is nothing at all.
+Linux deliberately returns a random value for brk(NULL), subject to the conditions
+that the value be at least as large as the maximum over all PT_LOAD of (.p_vaddr + .p_memsz),
+and "somewhat near" that maximum.  The purpose of randomness is to use variability
+to interfere with effectiveness of malware, and to expose application coding errors
+regarding brk() and sbrk().  If qemu-user wants to preserve contiguous .bss,
+then qemu-user should call memset() only if the first page of the range exists.
+(As explained in the next paragraph, "contiguous .bss" is a murky concept.)
+
+Linux itself is partly to blame, because it computes the maximum (.p_vaddr + .p_memsz)
+over all the PT_LOAD of the most recent execve().  The most recent execve() seen by
+Linux might have no relationship to the state of the address space at the time of
+_either_ call to brk().  The app can do arbitrary mmap, munmap, mprotect at any time.
+In particular, the run-time de-compressor of UPX does exactly that for a compressed
+main program.  The maximum computed by Linux is for the compressed program,
+which has a different layout than the de-compressed program.
+
+There is a Linux system call prctl(PR_SET_MM_BRK, new_value) which sets a value
+for "the brk", but that syscall tries to validate the new_value based on
+the most recent execve().  Once again, that has no relationship to the current
+layout of the address space produced by the UPX de-compressor.
+Steps to reproduce:
+1. build qemu8-x86_64 from
+```
+commit fcb237e64f9d026c03d635579c7b288d0008a6e5 (HEAD -> master, origin/master, origin/HEAD)
+Merge: 2ff49e96ac c00aac6f14
+Date:   Mon Jul 10 09:17:06 2023 +0100
+```
+2. run `build/qemu-x86_64 -strace upx-4.0.2-amd64_linux/upx --version` where the upx
+is from https://github.com/upx/upx/releases/download/v4.0.2/upx-4.0.2-amd64_linux.tar.xz
+3. output ends with
+```
+372621 close(3) = 0
+372621 munmap(0x0000004000803000,3055) = 0
diff --git a/results/classifier/105/socket/1759338 b/results/classifier/105/socket/1759338
new file mode 100644
index 00000000..f336bbec
--- /dev/null
+++ b/results/classifier/105/socket/1759338
@@ -0,0 +1,140 @@
+socket: 0.930
+network: 0.920
+boot: 0.915
+vnc: 0.911
+device: 0.901
+graphic: 0.901
+other: 0.900
+assembly: 0.885
+semantic: 0.844
+instruction: 0.842
+KVM: 0.734
+mistranslation: 0.720
+
+qemu-system-sparc w/ SS-20 ROM does not add processors
+
+When booting a SPARCstation-20 with the original ROM, qemu does not set the number of processors in a way that this ROM can understand it, and the ROM always reports only 1 processor installed:
+
+
+ ~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic
+
+Power-ON Reset
+
+
+
+
+           SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)
+
+
+CPU_#0       TI, TMS390Z50(3.x)       0Mb External cache
+
+CPU_#1       ******* NOT installed *******
+CPU_#2       ******* NOT installed *******
+CPU_#3       ******* NOT installed *******
+
+    <<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID = 00000008) 
+
+
+...
+
+Cpu #0 TI,TMS390Z50 
+Cpu #1 Nothing there 
+Cpu #2 Nothing there 
+Cpu #3 Nothing there 
+
+...
+
+SPARCstation 20 (1 X 390Z50), No Keyboard
+ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
+Ethernet address 52:54:0:12:34:56, Host ID: 72123456.
+
+
+
+
+(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.) 
+
+When booting with OpenBIOS I can't seem to boot any version of Solaris though I had heard this did work.  Solaris 8 and 9 do work nicely with this ROM, but I am opening this to see if it is possible to fix this to allow the original OBP ROM to see multiple processors.
+
+As of QEMU 4 OpenBIOS can boot Solaris again, and it does properly allocate multiple CPUs. Of course, it's a whole lot slower on multiple CPUs which I wasn't really anticipating, but it does work.  (And single CPU is so fast anyway compared to the actual hardware it's emulating!)  So this bug while still applicable can be closed. 
+
+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.
+
+Reporter said in comment #1 that the bug can be closed, so let's close it :-)
+
+
+Yes this can be closed, no problems now using open bios to boot Solaris and it does support multiple processors though this is actually slower than one.
+
+Sent from my mobile device
+
+On Nov 13, 2020, at 11:41 AM, Peter Maydell <email address hidden> wrote:
+
+ Reporter said in comment #1 that the bug can be closed, so let's close
+it :-)
+
+
+** Changed in: qemu
+Status: Incomplete => Fix Released
+
+--
+You received this bug notification because you are subscribed to the bug
+report.
+https://bugs.launchpad.net/bugs/1759338<https://bugs.launchpad.net/bugs/1759338>
+
+Title:
+qemu-system-sparc w/ SS-20 ROM does not add processors
+
+Status in QEMU:
+Fix Released
+
+Bug description:
+When booting a SPARCstation-20 with the original ROM, qemu does not
+set the number of processors in a way that this ROM can understand it,
+and the ROM always reports only 1 processor installed:
+
+
+~/qemu  /usr/local/bin/qemu-system-sparc -bios ./ss20_v2.25_rom -M SS-20 -cpu "TI SuperSparc 60" -smp 2 -nographic
+
+Power-ON Reset
+
+
+
+SMCC SPARCstation 10/20 UP/MP POST version VRV3.45 (09/11/95)
+
+
+CPU_#0 TI, TMS390Z50(3.x) 0Mb External cache
+
+CPU_#1 ******* NOT installed *******
+CPU_#2 ******* NOT installed *******
+CPU_#3 ******* NOT installed *******
+
+<<< CPU_00000000 on MBus Slot_00000000 >>> IS RUNNING (MID =
+00000008)
+
+
+...
+
+Cpu #0 TI,TMS390Z50
+Cpu #1 Nothing there
+Cpu #2 Nothing there
+Cpu #3 Nothing there
+
+...
+
+SPARCstation 20 (1 X 390Z50), No Keyboard
+ROM Rev. 2.25, 128 MB memory installed, Serial #1193046.
+Ethernet address 52:54:0:12:34:56, Host ID: 72123456.
+
+
+
+(It is necessary use SS-20 since it is the only sun4m model that supports 512MB RAM, and I can't get Solaris to install on the SS-20 using OpenBIOS.)
+
+When booting with OpenBIOS I can't seem to boot any version of Solaris
+though I had heard this did work. Solaris 8 and 9 do work nicely with
+this ROM, but I am opening this to see if it is possible to fix this
+to allow the original OBP ROM to see multiple processors.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/qemu/+bug/1759338/+subscriptions<https://bugs.launchpad.net/qemu/+bug/1759338/+subscriptions>
+
+
diff --git a/results/classifier/105/socket/1777 b/results/classifier/105/socket/1777
new file mode 100644
index 00000000..8d50878a
--- /dev/null
+++ b/results/classifier/105/socket/1777
@@ -0,0 +1,14 @@
+socket: 0.837
+network: 0.824
+device: 0.773
+vnc: 0.654
+instruction: 0.566
+graphic: 0.331
+other: 0.279
+boot: 0.268
+semantic: 0.257
+mistranslation: 0.156
+assembly: 0.092
+KVM: 0.025
+
+Allow logging of IP addresses of connections made to QEMU socket backends for e.g. VNC or SPICE console
diff --git a/results/classifier/105/socket/1781280 b/results/classifier/105/socket/1781280
new file mode 100644
index 00000000..66357f71
--- /dev/null
+++ b/results/classifier/105/socket/1781280
@@ -0,0 +1,27 @@
+socket: 0.962
+network: 0.851
+device: 0.794
+instruction: 0.776
+graphic: 0.697
+vnc: 0.627
+boot: 0.498
+mistranslation: 0.460
+semantic: 0.444
+other: 0.393
+KVM: 0.340
+assembly: 0.055
+
+QEMU ignores all but the first control message sent over a Unix socket
+
+I've written a test program that sends both an SCM_CREDENTIALS and an SCM_RIGHTS cmsg in the same sendmsg call. On native x86-64, armv6 and armv7 Linux, this works as expected (the recvmsg receives both control messages). On QEMU (both qemu-x86_64 and qemu-arm), only the first message is received.
+
+I've traced the problem back to a glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13500
+
+This means that writing control messages into an uninitialized buffer makes CMSG_NXTHDR erroneously return NULL even though there's still space inside the allocated buffer. QEMU's logic inside `target_to_host_cmsg` is a bit questionable here, since it stops encoding cmsgs as soon as *either* the host or the target buffer reaches its end, so we lose the target's cmsgs when the host's buffer runs out. However, the host buffer should *never* reach its end before the target buffer does, so an assertion might be more useful there. Anyway, the actual fix for this bug is simply zeroing out the buffer created for the host. I've attached a patch doing that and verified that it fixes the issue.
+
+The test program I used can be found here: https://gist.github.com/jonas-schievink/cb6e6584a055539d2113f22d91068e2d
+
+
+
+Fix has been committed as 1d3d1b23e1c8f52ec431ddaa8deea1322bc25cbf
+
diff --git a/results/classifier/105/socket/1796754 b/results/classifier/105/socket/1796754
new file mode 100644
index 00000000..4bd25492
--- /dev/null
+++ b/results/classifier/105/socket/1796754
@@ -0,0 +1,51 @@
+socket: 0.896
+instruction: 0.859
+graphic: 0.787
+network: 0.713
+device: 0.688
+semantic: 0.674
+other: 0.634
+vnc: 0.545
+mistranslation: 0.520
+boot: 0.428
+assembly: 0.388
+KVM: 0.285
+
+ioctl SIOCGIFCONF causes qemu-aarch64-static to crash with "received signal outside vCPU context"
+
+To reproduce it, compile the attached crash.c under aarch64 to a.out and execute on x86_64
+qemu-aarch64-static ./a.out
+
+It will print the following and crash:
+
+socket=3
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60038cd6
+qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x6000157a
+
+The version of qemu-aarch64-static is
+
+qemu-aarch64 version 3.0.0 (qemu-3.0.0-1.fc29)
+Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
+
+But it did also happen in previous versions so it is not a regression but a bug existed ever since.
+
+
+
+I was hit by this issue when I tried to run some Java program. And it turns out jdk sets the buf to NULL: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/887e525597f8/src/solaris/native/java/net/NetworkInterface.c#l1042
+
+Setting to NULL is valid according to http://man7.org/linux/man-pages/man7/netdevice.7.html
+
+But qemu doesn’t handle the case: https://github.com/qemu/qemu/blob/aa8e26de9617756febcbf794dda965df307fdaaa/linux-user/syscall.c#L4105
+
+I guess qemu developers didn’t handle the case because the Linux kernel changed and they were based on behavior of old version: https://linux.die.net/man/7/netdevice
+
+Please add the support for it otherwise a wide range of network related Java programs won’t run.
+
+I sent out a patch: http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg01657.html
+(Please ignore the other 2 identical patches. It was my first time sending out patches and I didn't know it was moderated so I sent it out multiple times).
+
+I have patch at http://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05401.html, please let me know when it can be merged, thanks.
+
+Kan Li's patch was applied to master as commit 22e4a267a6627e5b5b, so this will be fixed in the upcoming QEMU 4.0 release.
+
+
diff --git a/results/classifier/105/socket/1801933 b/results/classifier/105/socket/1801933
new file mode 100644
index 00000000..2e010a0b
--- /dev/null
+++ b/results/classifier/105/socket/1801933
@@ -0,0 +1,146 @@
+socket: 0.950
+instruction: 0.947
+vnc: 0.945
+semantic: 0.941
+device: 0.938
+network: 0.935
+assembly: 0.932
+mistranslation: 0.927
+boot: 0.911
+other: 0.898
+graphic: 0.882
+KVM: 0.863
+
+default memory parameter too small on x86_64 today
+
+Launching a centos7 VM today does not work anymore on x86_64 without increasing the size of the memory parameter. For example with this command :
+
+$ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses   -enable-kvm -drive file=file.dd,index=0,media=disk -drive file=centos-x86_64.iso,index=1,media=cdrom
+
+[    3.047614] Failed to execute /init
+[    3.048315] Kernel panic - not syncing: No init found.  Try passing init= option to kernel. See Linux Documentation/init.txt for guidance.
+[    3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-693.21.1.el7.x86
+
+
+
+Increasing the size from the default 128MiB to 512MiB let the VM works without problem.
+So, ok, it's not a qemu problem, it's more a "User problem" and interface problem for me.
+But it push me in the end to launch VirtualBox instead of qemu, because the default parameter does not work anymore... And I had no time to investigate why it does not work because the message is not visible.
+Debian iso with the same command line for example show a message to tell me that there is not enough memory, so it help me to track the real issue behind.
+
+But... In the end, I think today, the default memory parameter on x86_64 is too small and it can lead some people like me to switch to VirtualBox.
+VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell you... Ok I need to put more. But, you know that 4MiB is not enough in the end.
+
+
+Regards,
+
+Johann
+
+IMHO, if achieving ease of use comparable to VirtualBox is your benchmark target, then launching QEMU directly is really the wrong way to approach things. QEMU is a very low level piece of infrastructure not a complete end user desktop solution. For that it is better to look at using an application such as virt-manager, or GNOME Boxes. These provide higher level solution over QEMU and do smart things during installation, using libosinfo to automatically determine the best memory, disk, network, etc settings for each particular guest OS rather than relying on some hardcoded defaults.
+
+That said all said, I don't rule out that we could change our memory defaults, but picking an optimal value is hard. Even 500 MB is considered to be unsupported from a RHEL-7 pov - the documented minimum for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with 500 MB depending on what options you select durin intsall.
+
+
+Hi Daniel,
+
+I use qemu for a long time now so for me it's easier to use than any other
+solution.
+I think I began to use as my preffered VM tool in 2003.
+But, I still think that keeping this value at 128MB is low today.
+Maybe in this case reducing this value to make it crash is another option,
+for example 4MB.
+Or just print a message if it is an iso file that ramsize is set to 128MB,
+maybe you need more ram.
+It is just quick thought, some OS will handle this correctly, some os won't.
+For example in my example I say that debian say it explicitely in the 80x25
+screen in red.
+
+Today I see all people around me are moving to VirtualBox because it just
+work out of the box.
+And Qemu is near to work out of the box with 2 or 3 parameter in the end.
+Definitely I have a prefference for Qemu, because it's more "shell
+friendly".
+
+It was just my quick thought about it.
+
+Johann
+
+
+
+Le mer. 5 déc. 2018 à 12:31, Daniel Berrange <email address hidden> a
+écrit :
+
+> IMHO, if achieving ease of use comparable to VirtualBox is your
+> benchmark target, then launching QEMU directly is really the wrong way
+> to approach things. QEMU is a very low level piece of infrastructure not
+> a complete end user desktop solution. For that it is better to look at
+> using an application such as virt-manager, or GNOME Boxes. These provide
+> higher level solution over QEMU and do smart things during installation,
+> using libosinfo to automatically determine the best memory, disk,
+> network, etc settings for each particular guest OS rather than relying
+> on some hardcoded defaults.
+>
+> That said all said, I don't rule out that we could change our memory
+> defaults, but picking an optimal value is hard. Even 500 MB is
+> considered to be unsupported from a RHEL-7 pov - the documented minimum
+> for RHEL-7 is 1 GB per vCPU. The installer is quite likely to crash with
+> 500 MB depending on what options you select durin intsall.
+>
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/1801933
+>
+> Title:
+>   default memory parameter too small on x86_64 today
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Launching a centos74 iso VM today does not work anymore on x86_64
+>   without increasing the size of the memory parameter. For example with
+>   this command :
+>
+>   $ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses   -enable-kvm -drive
+>   file=file.dd,index=0,media=disk -drive file=centos-
+>   x86_64.iso,index=1,media=cdrom
+>
+>   [    3.047614] Failed to execute /init
+>   [    3.048315] Kernel panic - not syncing: No init found.  Try passing
+> init= option to kernel. See Linux Documentation/init.txt for guidance.
+>   [    3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
+> 3.10.0-693.21.1.el7.x86
+>
+>   Increasing the size from the default 128MiB to 512MiB let the VM works
+> without problem.
+>   So, ok, it's not a qemu problem, it's more a "User problem" and
+> interface problem for me.
+>   But it push me in the end to launch VirtualBox instead of qemu, because
+> the default parameter does not work anymore... And I had no time to
+> investigate why it does not work because the message is not visible.
+>   Debian iso with the same command line for example show a message to tell
+> me that there is not enough memory, so it help me to track the real issue
+> behind.
+>
+>   But... In the end, I think today, the default memory parameter on x86_64
+> is too small and it can lead some people like me to switch to VirtualBox.
+>   VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell
+> you... Ok I need to put more. And, you know that 4MiB is not enough in the
+> end.
+>
+>   Regards,
+>
+>   Johann
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1801933/+subscriptions
+>
+
+
+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/105/socket/1823790 b/results/classifier/105/socket/1823790
new file mode 100644
index 00000000..2a098c20
--- /dev/null
+++ b/results/classifier/105/socket/1823790
@@ -0,0 +1,215 @@
+assembly: 0.986
+socket: 0.986
+semantic: 0.985
+device: 0.985
+graphic: 0.985
+instruction: 0.984
+other: 0.978
+vnc: 0.973
+KVM: 0.969
+network: 0.968
+mistranslation: 0.950
+boot: 0.933
+
+QEMU mishandling of SO_PEERSEC forces systemd into tight loop
+
+While building Debian images for embedded ARM target systems I detected that QEMU seems to force newer systemd daemons into a tight loop.
+
+My setup is the following:
+
+Host machine: Ubuntu 18.04, amd64
+LXD container: Debian Buster, arm64, systemd 241
+QEMU: qemu-aarch64-static, 4.0.0-rc2 (custom build) and 3.1.0 (Debian 1:3.1+dfsg-7)
+
+To easily reproduce the issue I have created the following repository:
+https://github.com/lueschem/edi-qemu
+
+The call where systemd gets looping is the following:
+2837 getsockopt(3,1,31,274891889456,274887218756,274888927920) = -1 errno=34 (Numerical result out of range)
+
+Furthermore I also verified that the issue is not related to LXD.
+The same behavior can be reproduced using systemd-nspawn.
+
+This issue reported against systemd seems to be related:
+https://github.com/systemd/systemd/issues/11557
+
+As described on the systemd issue, the syscall we're getting wrong here is getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...). Our linux-user/syscall.c:do_getsockopt() doesn't have any special case code for the payload on this function, so we treat it as if it were just an integer payload, which is not correct here.
+
+Unfortunately I can't find any documentation on exactly what SO_PEERSEC does or what the payload format is, which makes it pretty hard to fix this bug :-( It's not listed in the socket(7) manpage -- https://linux.die.net/man/7/socket -- which is where I'd expect to find it, and the kernel source code is pretty confusing in this area.
+
+
+This is probably the tight loop that gets triggered:
+https://github.com/systemd/systemd/commit/217d89678269334f461e9abeeffed57077b21454
+
+It looks like the previous implementation was just a bit more "tolerant".
+
+I have just studied a bit the systemd code and this brought me to the following idea/temporary workaround: What about returning -1 (error) and setting errno when getsockopt(fd, SOL_SOCKET, SO_PEERSEC, ...) gets called? This would then let systemd know that SO_PEERSEC is not (yet) implemented.
+
+I filed the duplicate #1840252 of this bug.
+
+I think that the options SO_PEERCRED and SO_PEERSEC belong into the context of SELINUX. So maybe the format of the paylod can be found in the sources of libselinux?
+
+I'd like to compile qemu with a local hack to work around my current problem. Something like Matthias Lüscher suggested. 
+
+@Peter Maydell: could you point me to the location in the qemu source where I could apply such a hack?
+
+I patched linux-user/syscall.c (see below, branch stable-2.11) which works around my problem.
+So far so good, but the qemu-arm that i compiled is terribly slow compared to the one that came with Ubuntu 18.04. Any hints?
+I configured as this:
+./configure --static --enable-kvm --target-list=arm-linux-user
+
+diff --git a/linux-user/syscall.c b/linux-user/syscall.c
+index 74d56e2ee6..4fa9a09b12 100644
+--- a/linux-user/syscall.c
++++ b/linux-user/syscall.c
+@@ -3185,6 +3185,8 @@ static abi_long do_getsockopt(int sockfd, int level, int optname,
+         case TARGET_SO_SNDTIMEO:
+         case TARGET_SO_PEERNAME:
+             goto unimplemented;
++        case TARGET_SO_PEERSEC: /* added to escape infinite loop */
++            goto unimplemented;
+         case TARGET_SO_PEERCRED: {
+             struct ucred cr;
+             socklen_t crlen;
+
+
+
+I'm a bit surprised that this bug doesn't get more attention, as it makes it very hard to run qemu-emulated containers of Bionic hosted on Bionic. Running such containers is a common way to cross-compile packages for foreign architectures in the absence of sufficiently powerful target HW.
+
+The documentation on SO_PEERSEC is indeed sparse, but I do want to second Fritz in his approach. I don't see a reason, why treating the payload as incorrect and throwing it back at the application is better than handling it and saying it is not implemented (which is the case).
+
+Arguably, applications should be fixed to handle the error correctly, but I'm afraid that is a can of worms. I have encountered the same problem with systemd, apt and getent. Would the maintainers be open to an SRU request on QEMU for this?
+
+Could you test the attached patch?
+
+Thanks, Laurent! I'll get back to you, asap.
+
+> Could you test the attached patch?
+>
+
+Works great!
+
+This is my test setup:
+
+Host machine: Ubuntu 18.04, amd64
+LXD container: Debian Buster, arm64, systemd 241
+QEMU: qemu-aarch64(-static), compiled from source (4.2.0), patched with
+your patch.
+
+Many thanks!
+Matthias
+
+
+I carried out the following test:
+
+* fetched the QEMU coming with 18.04,
+* added this patch,
+* built an LXD container with arch arm64 and the patched qemu-aarch64-static inside,
+* launched it on amd64
+
+Previously various systemd services would not come up properly, now they are running like a charm. The only grief I have is that network configuration does not work, but that is due to
+
+    # ip addr
+    Unsupported setsockopt level=270 optname=11
+
+which is a different story.
+
+Well, it's kind of irrelevant but I am trying that on archlinux and this does not work for me.
+
+Using systemd-244.2-1 and qemu-user-static-4.2 that I built with Laurent's patch. May be I have done something wrong ?
+
+I still get that error that leads me here:
+
+Failed to enqueue loopback interface start request: Operation not supported
+Caught <SEGV>, dumped core as pid 3.
+Exiting PID 1...
+
+I am trying to boot with systemd-nspawn an archlinux-arm built for a rpi0. That's fine if I don't boot it.
+
+Laurent's patch worked for me as well.
+
+I grabbed the source for the Debian 10 qemu-user-static package, qemu_3.1+dfsg-8+deb10u3, applied the patch and re-built the qemu-arm-static binary. Copying the new binary into a Docker image based on arm32v7/debian:10-slim allowed /sbin/init to bring up the container with a responsive systemctl command.
+
+Prior to the patch, systemd did not start any services inside the container and systemctl would hang when executed directly.
+
+Thanks!
+-Charlie
+
+This seems to be the error reported in https://bugs.launchpad.net/qemu/+bug/1857811
+
+Fixed here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=6d485a55d0cd
+
+
+Bisect worked and once you find it it seems obvious that this is exactly our case:
+
+commit 65b261a63a48fbb3b11193361d4ea0c38a3c3dfd
+Author: Laurent Vivier <email address hidden>
+Date:   Thu Jul 9 09:23:32 2020 +0200
+
+    linux-user: add netlink RTM_SETLINK command
+    
+    This command is needed to be able to boot systemd in a container.
+    
+      $ sudo systemd-nspawn -D /chroot/armhf/sid/ -b
+      Spawning container sid on /chroot/armhf/sid.
+      Press ^] three times within 1s to kill container.
+      systemd 245.6-2 running in system mode.
+      Detected virtualization systemd-nspawn.
+      Detected architecture arm.
+    
+      Welcome to Debian GNU/Linux bullseye/sid!
+    
+      Set hostname to <virt-arm>.
+      Failed to enqueue loopback interface start request: Operation not supported
+      Caught <SEGV>, dumped core as pid 3.
+      Exiting PID 1...
+      Container sid failed with error code 255.
+    
+    Signed-off-by: Laurent Vivier <email address hidden>
+    Message-Id: <email address hidden>
+
+ linux-user/fd-trans.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+Sorry, posted this on the wrong bug :-/
+I beg your pardon for the noise.
+
+Hmm, I'm using qemu-5.1.0 and I'm still seeing this (host is bionic, container image is focal)
+
+[..]
+getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range)
+getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range)
+getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE (Numerical result out of range)
+[..]
+
+Regression?
+
+I can confirm that I see the same issue when trying to run Ubuntu 20.04 aarch64 in a container, strace shows a tight loop on:
+
+getsockopt(31, SOL_SOCKET, SO_PEERGROUPS, 0x7ffdbd58941c, [4]) = -1 ERANGE
+
+Re-building qemu-user-static with the patch has fixed Debian 10 armhf for me, but the same re-build does not seem to help with this Ubuntu issue.
+
+SO_PEERGROUPS is not implemented and processed as an "int" (this explains the ERANGE)
+
+Could you try the attached patch?
+
+In my case the issue with using Ubuntu 20.04 as a container host appears to have come down to the use of the F, or "fix binary", flag by binfmnt_misc:
+
+# cat /proc/sys/fs/binfmt_misc/qemu-aarch64
+enabled
+interpreter /usr/bin/qemu-aarch64-static
+flags: OCF
+offset 0
+magic 7f454c460201010000000000000000000200b700
+mask ffffffffffffff00fffffffffffffffffeffffff
+
+This appears to be new in Ubuntu 20.04 relative to 18.04 and results in the qemu-user-static binaries being loaded and locked into memory _when the package is installed_.
+
+Therefore, what I observed as a regression of the issue was actually just the packaged binaries now taking precedence over patched versions that I had built and copied into place.
+
+Ubuntu 20.04 ships QEMU 4.2. Using the QEMU 5.1 packages from Debian Bullseye allows SystemD to run in a foreign architecture container without spinning in a loop:
+
+  https://packages.debian.org/bullseye/qemu-user-static
+
diff --git a/results/classifier/105/socket/1826401 b/results/classifier/105/socket/1826401
new file mode 100644
index 00000000..7c13a0be
--- /dev/null
+++ b/results/classifier/105/socket/1826401
@@ -0,0 +1,57 @@
+socket: 0.808
+instruction: 0.742
+device: 0.646
+graphic: 0.604
+network: 0.558
+mistranslation: 0.492
+other: 0.329
+semantic: 0.292
+vnc: 0.167
+boot: 0.110
+assembly: 0.075
+KVM: 0.011
+
+qemu-system-aarch64 has a high cpu usage on windows
+
+Running qemu-system-aarch64 leads to a high CPU consumption on windows 10.
+
+Tested with qemu: 4.0.0-rc4 & 3.1.0 & 2.11.0
+
+Command: qemu_start_command = [
+        qemu-system-aarch64,
+        "-pidfile",
+        target_path + "/qemu" + str(instance) + ".pid",
+        "-machine",
+        "virt",
+        "-cpu",
+        "cortex-a57",
+        "-nographic",
+        "-smp",
+        "2",
+        "-m",
+        "2048",
+        "-kernel",
+        kernel_path,
+        "--append",
+        "console=ttyAMA0 root=/dev/vda2 rw ipx=" + qemu_instance_ip + "/64 net.ifnames=0 biosdevname=0",
+        "-drive",
+        "file=" + qemu_instance_img_path + ",if=none,id=blk",
+        "-device",
+        "virtio-blk-device,drive=blk",
+        "-netdev",
+        "socket,id=mynet0,udp=127.0.0.1:2000,localaddr=127.0.0.1:" + qemu_instance_port,
+        "-device",
+        "virtio-net-device,netdev=mynet0",
+        "-serial",
+        "file:" + target_path + "/qemu" + str(instance) + ".log"
+    ]
+
+*The cpu consumption is ~70%.
+*No acceleration used.
+*This CPU consumption is obtained only by running the above command. No workload on the guest OS.
+
+Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?
+Also, what guest operating systems were you running ?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1828207 b/results/classifier/105/socket/1828207
new file mode 100644
index 00000000..d30dcee1
--- /dev/null
+++ b/results/classifier/105/socket/1828207
@@ -0,0 +1,52 @@
+socket: 0.670
+vnc: 0.624
+network: 0.593
+device: 0.527
+other: 0.419
+semantic: 0.300
+mistranslation: 0.280
+instruction: 0.212
+assembly: 0.166
+KVM: 0.165
+boot: 0.153
+graphic: 0.113
+
+Request to add something like "Auth failed from IP" log report for built-in VNC server
+
+In environment with needs of public accessible VNC ports there is no logs or other registered events about authentication failures to analyze and/or integrate it to automated services like fail2ban ans so on.
+Thus the built-in VNC service is vulnerable to brutforce attacks and in combination with weak built-in VNC-auth scheme can be a security vulnerability.
+
+Adding a simple log record like "QEMU VNC Authentication failed 192.168.0.5:5902 - 123.45.67.89:7898" will permit to quickly integrate it to fail2ban system.
+
+Note that any use of the built-in VNC-auth scheme is always considered a security flaw. It should essentially never be used, especially not on any public internet facing service, even if fail2ban were able to be used.
+
+A secure VNC server should use the VeNCrypt extension which enables TLS, with optional client certificate validation as an auth mechanism.  Once you have TLS enabled, you can also then enable the SASL auth mechanism to further authenticate clients using Kerberos or PAM, or other SASL plugins.
+
+That's not to say we shouldn't emit a log message, suitable for consuming from fail2ban, as remote clients can still trigger a CPU denial of service by repeatedly connecting even if they ultimately always fail authentication.
+
+
+On Wed, 8 May 2019 at 14:23, Daniel Berrange <email address hidden> wrote:
+>
+> Note that any use of the built-in VNC-auth scheme is always considered a
+> security flaw. It should essentially never be used, especially not on
+> any public internet facing service, even if fail2ban were able to be
+> used.
+
+Should we deprecate-and-remove the feature, then ?
+
+thanks
+-- PMM
+
+
+The challenge is that this is the only auth scheme defined by the VNC protocol, aside from no-auth.
+If we removed it, we'd no longer be compatible with the standard VNC protocol. We'd be making use of the TLS/SASL extensions mandatory if users want auth. This could ultimately push people to turn off auth altogether which is even worse.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/170
+
+
diff --git a/results/classifier/105/socket/1828608 b/results/classifier/105/socket/1828608
new file mode 100644
index 00000000..9980d7f1
--- /dev/null
+++ b/results/classifier/105/socket/1828608
@@ -0,0 +1,56 @@
+socket: 0.574
+semantic: 0.536
+device: 0.531
+other: 0.446
+mistranslation: 0.389
+network: 0.377
+vnc: 0.289
+graphic: 0.228
+boot: 0.196
+instruction: 0.155
+KVM: 0.153
+assembly: 0.078
+
+Chardev websocket might not support pasting more than a few chars
+
+When sending more than 4-5 characters on the websocket serial console (with pasting for example), the guest might not receive all of them, or worse interpret the input as Magic SysRq keys.
+
+This might be due to the io loop not checking the backend readiness before calling the read function.
+
+Attached patched fixes the problem on my system. I'm not sure it's the proper approach, this is just to start discussion.
+
+
+
+If the problem only happens with a websockets channel enabled, it possibly a bug in the QIOChannelWebsock impl rather than the chardev
+
+I wrote a websocket client to help reproduce the bug without a browser:
+https://github.com/anisse/websocktty
+
+You can install it to your $GOPATH/bin (defaults to ~/go/bin) with "go get github.com/anisse/websocktty"
+
+I can reproduce the bug with it by simply pasting a long-enough (5 to 20 characters) string.
+
+I could not reproduce the bug with qemu's  "-serial tcp" and netcat, so this problem might indeed be limited to the websock channel implementation.
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+The bug is still present.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/133
+
+
diff --git a/results/classifier/105/socket/1829779 b/results/classifier/105/socket/1829779
new file mode 100644
index 00000000..9a176344
--- /dev/null
+++ b/results/classifier/105/socket/1829779
@@ -0,0 +1,93 @@
+socket: 0.849
+semantic: 0.821
+other: 0.818
+instruction: 0.806
+graphic: 0.788
+device: 0.767
+boot: 0.726
+vnc: 0.717
+assembly: 0.669
+KVM: 0.662
+network: 0.575
+mistranslation: 0.570
+
+qemu-system-arm and qemu-system-aarch64 QMP hangs after kernel boots
+
+After booting a Linux kernel on both arm and aarch64, the QMP sockets gets unresponsive. Initially, this was thought to be limited to "quit" commands, but it reproduced with others (such as in this
+reproducer).  This is a partial log output:
+    
+   >>> {'execute': 'qmp_capabilities'}
+   <<< {'return': {}}
+   Booting Linux on physical CPU 0x0000000000 [0x410fd034]
+   Linux version 4.18.16-300.fc29.aarch64 (<email address hidden>) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:12:22 UTC 2018
+   ...
+   Policy zone: DMA32
+   Kernel command line: printk.time=0 console=ttyAMA0
+   >>> {'execute': 'stop'}
+   <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470173}, 'event': 'STOP'}
+   <<< {'return': {}}
+   >>> {'execute': 'cont'}
+   <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470849}, 'event': 'RESUME'}
+   <<< {'return': {}}
+   >>> {'execute': 'stop'}
+    
+Sometimes it takes just the first "stop" command.  Overall, I was able to reproduce 100% of times when applied on top of 6d8e75d41c58892ccc5d4ad61c4da476684c1c83.
+
+The reproducer test can be seen/fetched at:
+ - https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df
+
+And test results from Travis CI can be seen at:
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669
+
+For convenience purposes, here's qemu-system-aarch64 launching and hanging on the first "stop":
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3615
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3645
+
+And here's qemu-system-arm hanging the very same way:
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3780
+ - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3800
+
+I have an update on this.  Eric and myself attempted to zero in the
+exact cause.  A few things we discovered:
+
+ 1) It has nothing to do with having a kernel running
+ 2) It has to do with having a chardev that is a server socket.  This
+    test produces command line arguments such as:
+
+   -chardev socket,id=console,path=<path>.sock,server,nowait \
+   -serial chardev:console
+
+ 3) It doesn't seem to have a connection to the test infrastructure code
+    (python/qemu/qmp/*), as a I made a number of experiments which
+    yielded no differences in behavior.
+
+So, the reproducer given at:
+
+ https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df
+
+Continues to be be valid (and continues to be limited to arm and aarch64).
+Now, after a number of experiments, the following was found to be a 100%
+reproducible *workaround*:
+
+ https://github.com/clebergnu/qemu/commit/e1713f3b91972ad57c089f276c54db3f3fa63423
+
+That basically shutdowns the *console* socket before proceeding with further QMP
+interaction.  The effectiveness of the workaround can be seen here:
+
+ aarch64 command line:
+  - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3633
+ aarch64 QMP interaction:
+  - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3663
+
+ arm command line:
+  - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3747
+ arm QMP interaction:
+  - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3767
+
+I hope this provides a few more hints into the real issue.
+
+
+A patch for this bug has been merged here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=085809670201c6d3a33e3
+... can we close this ticket now?
+
diff --git a/results/classifier/105/socket/1829945 b/results/classifier/105/socket/1829945
new file mode 100644
index 00000000..7c190e2c
--- /dev/null
+++ b/results/classifier/105/socket/1829945
@@ -0,0 +1,62 @@
+socket: 0.843
+graphic: 0.790
+device: 0.762
+instruction: 0.744
+KVM: 0.697
+other: 0.686
+network: 0.645
+boot: 0.619
+vnc: 0.594
+assembly: 0.451
+semantic: 0.445
+mistranslation: 0.329
+
+SDL support missing from qemu-1:3.1+dfsg-2ubuntu3.1
+
+qemu support is missing from qemu-1:3.1+dfsg-2ubuntu3.1 on Disco. This is dispite qemu --help saying its available. SDL support is needed to use Packer(https://www.packer.io/) in graphical mode.
+
+# qemu-system-x86_64 -cpu host -smp 2,sockets=2,cores=1,threads=1 -machine type=pc,accel=kvm -display sdl -cdrom ubuntu.iso
+qemu-system-x86_64: Display 'sdl' is not available.
+
+# qemu-system-x86_64 --help | grep sdl
+-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]
+-sdl            shorthand for -display sdl
+
+Hi Lee,
+TL;DR: there will be no sdl support anymore for newer qemu's. (make it) Use "-display gtk" instead.
+
+Details:
+#1 SDL 1.2 vs SDL 2.0 vs working fine
+1.2 was in main all the time and worked, but got unsupportable over time.
+SDL2 was tried, but failed badly in quite some experiments for Debain and 
+Ubuntu. That led to the choice of both distributions to go with the more
+modern GTK backend instead.
+Ubuntu (at Bionic staying at SDL1.2):
+- sdl2 is yet too unstable for the LTS Ubuntu release given the reports
+  we still see upstream and in Debian - furthermore sdl2 isn't in main yet,
+  so we revert related changes to stick with the proven for now:
+Debian then followed for #839695, #886671, #879536, #879534, #879532, #879193, #894852
+That also matches upstream where GTK backend for graphics is the #1 thing.
+
+#2 Supportability
+The reason everyone wanted to get off SDL was maintainability as I mentioned. And as of today you'll find that none of the SDL libs is in main anymore (since Cosmic).
+*sdl* is universe nowadays.
+And we can't make a good case for it (to MIR it) as GTK solves it - at least from the qemu POV.
+
+#3 About the man page, this isn't patched for features enabled/disabled by the upstream build system. For example it also contains "pvrdma" which is disabled for security reasons (and many other things).
+
+I must conclude that as-is I won't enable sdl, but then why does it insist on `-display sdl` in the first place. `-display gtk` is just as good or better. Is that our package of packer.io that we'd want to adapt or a PR for upstream maybe?
+
+Also misfiled against upstream's Qemu - this clearly was meant for Ubuntu's Qemu as technically upstream is still fine enabling sdl (if the package builder wants to).
+
+Changing the bug tasks ...
+
+Ha, Thomas beat me to re-target the bug while I was checking my inbox - thanks :-)
+
+Thanks for the explanation. MAAS is starting to use Packer to create custom images so we may be packaging this soon. I will filed an upstream bug[1] and created a patch[2] to fix the issue.
+
+[1] https://github.com/hashicorp/packer/issues/7675
+[2] https://github.com/hashicorp/packer/pull/7676
+
+Thanks, I subscribed there and already participate in the discussion
+
diff --git a/results/classifier/105/socket/1836453 b/results/classifier/105/socket/1836453
new file mode 100644
index 00000000..20eff2af
--- /dev/null
+++ b/results/classifier/105/socket/1836453
@@ -0,0 +1,50 @@
+socket: 0.947
+network: 0.929
+instruction: 0.894
+device: 0.889
+graphic: 0.856
+semantic: 0.839
+vnc: 0.838
+assembly: 0.718
+mistranslation: 0.675
+KVM: 0.650
+boot: 0.622
+other: 0.378
+
+"qemu-nsis\*.bmp" -> no files found" when building with MXE
+
+Already reported for 4.0:
+https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07005.html
+
+host: Docker qemu:debian-win32-cross
+
+$ make installer
+(cd /tmp/qemu-nsis; \
+         for i in qemu-system-*.exe; do \
+           arch=${i%.exe}; \
+           arch=${arch#qemu-system-}; \
+           echo Section \"$arch\" Section_$arch; \
+           echo SetOutPath \"\$INSTDIR\"; \
+           echo File \"\${BINDIR}\\$i\"; \
+           echo SectionEnd; \
+         done \
+        ) >/tmp/qemu-nsis/system-emulations.nsh
+makensis -V2 -NOCD \
+                -DCONFIG_DOCUMENTATION="y" \
+                 \
+                -DBINDIR="/tmp/qemu-nsis" \
+                 \
+                -DSRCDIR="/source/qemu" \
+                -DOUTFILE="qemu-setup-4.0.90.exe" \
+                -DDISPLAYVERSION="4.0.90" \
+                /source/qemu/qemu.nsi
+File: "/tmp/qemu-nsis\*.bmp" -> no files found.
+Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
+   /oname=outfile one_file_only)
+Error in script "/source/qemu/qemu.nsi" on line 122 -- aborting creation process
+Makefile:1077: recipe for target 'qemu-setup-4.0.90.exe' failed
+make: *** [qemu-setup-4.0.90.exe] Error 1
+
+Fix has been included here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b3ce38dcf93a1203
+
diff --git a/results/classifier/105/socket/1837 b/results/classifier/105/socket/1837
new file mode 100644
index 00000000..da9ee070
--- /dev/null
+++ b/results/classifier/105/socket/1837
@@ -0,0 +1,48 @@
+socket: 0.927
+instruction: 0.796
+device: 0.713
+network: 0.685
+other: 0.676
+graphic: 0.530
+semantic: 0.352
+vnc: 0.301
+boot: 0.279
+mistranslation: 0.150
+assembly: 0.130
+KVM: 0.114
+
+Support IP_MULTICAST_IF socket option in linux-user
+Additional information:
+I've run into this limitation in qemu-aarch64-static version Debian 1:6.2+dfsg-2ubuntu6.12, but from the link above, it doesn't seem to be implemented on master yet.
+
+Here's some source code that demonstrates the failure:
+```
+#include <sys/socket.h>
+#include <arpa/inet.h>
+#include <netinet/ip.h>
+#include <unistd.h>
+#include <assert.h>
+#include <stdio.h>
+
+int main()
+{
+    int fd, ret;
+    struct in_addr addr = {htonl(INADDR_LOOPBACK)};
+
+    fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
+    assert(fd >= 0);
+    ret = setsockopt(fd, IPPROTO_IP, IP_MULTICAST_IF, &addr, sizeof(addr));
+    if (ret < 0)
+    {
+        perror("setsockopt failed");
+        return 1;
+    }
+    close(fd);
+    printf("Success!\n");
+    return 0;
+}
+```
+
+When run under qemu, it gives the error `setsockopt failed: Protocol not available`.
+
+It doesn't look like it should be too hard to support (certainly no worse than IP_ADD_MEMBERSHIP). Let me know if I can help with a patch.
diff --git a/results/classifier/105/socket/1837651 b/results/classifier/105/socket/1837651
new file mode 100644
index 00000000..384e65dd
--- /dev/null
+++ b/results/classifier/105/socket/1837651
@@ -0,0 +1,34 @@
+socket: 0.931
+network: 0.766
+graphic: 0.712
+device: 0.659
+instruction: 0.627
+vnc: 0.598
+other: 0.597
+mistranslation: 0.450
+semantic: 0.408
+boot: 0.299
+assembly: 0.096
+KVM: 0.067
+
+-netdev socket uses 100% cpu on Windows host
+
+On Windows hosts, any `-netdev socket` option (tcp listen, tcp connect, udp passing a fd) causes qemu to use 100% cpu. The guest still runs, but only sluggishly.
+
+A simple testcase is:
+
+> qemu-system-i386.exe -netdev socket,listen=:8000,id=n
+
+And, in another command prompt:
+
+> echo foo | nc.exe localhost 8000
+
+Where nc.exe is netcat.
+
+Tested on qemu 3.1 (from https://qemu.weilnetz.de/w64/) and 4.0 (self compiled).
+
+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/105/socket/1843590 b/results/classifier/105/socket/1843590
new file mode 100644
index 00000000..3562008c
--- /dev/null
+++ b/results/classifier/105/socket/1843590
@@ -0,0 +1,49 @@
+socket: 0.870
+network: 0.841
+graphic: 0.836
+device: 0.755
+instruction: 0.727
+mistranslation: 0.727
+vnc: 0.609
+boot: 0.477
+semantic: 0.473
+KVM: 0.446
+assembly: 0.427
+other: 0.371
+
+NBD tests  use hardcoded port 10810
+
+QEMU v3.1.0
+
+$ ./configure --block-drv-rw-whitelist=qcow2,raw,file,host_device,nbd,iscsi,rbd,blkdebug,luks,null-co,nvme,copy-on-read,throttle,vxhs,gluster [...]
+
+$ ./check -v -nbd 001 002 003 004 005 008 009 010 011 021 032 033 045 077 094 104 119 123 132 143 145 147 151 152 162 181 184 194 205 208 218 222
+[...]
+104         - output mismatch (see 104.out.bad)
+--- tests/qemu-iotests/104.out	2018-12-11 17:44:35.000000000 +0000
++++ tests/qemu-iotests/104.out.bad	2019-09-11 11:59:11.822058653 +0000
+@@ -6,7 +6,7 @@
+ file format: IMGFMT
+ virtual size: 1.0K (1024 bytes)
+ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1234
+-image: TEST_DIR/t.IMGFMT
+-file format: IMGFMT
+-virtual size: 1.5K (1536 bytes)
++Failed to find an available port: Address already in use
++qemu-img: Could not open 'nbd:127.0.0.1:10810': Failed to connect socket: Connection refused
++./common.rc: line 203: kill: (28391) - No such process
+ ***done
+Failed 1 of 32 tests
+
+Could be due to concurrent builds on the same system:
+
+$ git grep 10810 tests
+tests/qemu-iotests/common.filter:125:        -e 's#nbd:127.0.0.1:10810#TEST_DIR/t.IMGFMT#g' \
+tests/qemu-iotests/common.filter:161:        -e 's#nbd://127.0.0.1:10810$#TEST_DIR/t.IMGFMT#g' \
+tests/qemu-iotests/common.rc:140:        TEST_IMG="$DRIVER,file.driver=nbd,file.host=127.0.0.1,file.port=10810"
+tests/qemu-iotests/common.rc:156:        TEST_IMG="nbd:127.0.0.1:10810"
+tests/qemu-iotests/common.rc:276:        eval "$QEMU_NBD -v -t -b 127.0.0.1 -p 10810 -f $IMGFMT -e 42 -x '' $TEST_IMG_FILE >/dev/null &"
+
+This should have been fixed by this commit here:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=f3923a72f199b2c63747a7
+
diff --git a/results/classifier/105/socket/1857811 b/results/classifier/105/socket/1857811
new file mode 100644
index 00000000..a419f522
--- /dev/null
+++ b/results/classifier/105/socket/1857811
@@ -0,0 +1,202 @@
+assembly: 0.946
+socket: 0.938
+device: 0.935
+other: 0.933
+instruction: 0.929
+network: 0.920
+mistranslation: 0.911
+semantic: 0.907
+graphic: 0.899
+boot: 0.897
+vnc: 0.842
+KVM: 0.816
+
+qemu user static binary seems to lack support for network namespace.
+
+Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I see the following error message.
+
+Unable to configure loopback interface: Operation not supported
+
+If I disable emerge's network-sandbox which utilizes network namespace, the error disappears.
+
+Could you run qemu unimplemented error trace, by using "export QEMU_LOG=unimp"?
+
+You can also set the QEMU_STRACE="" to see which syscall fails.
+
+I executed "emerge" with QEMU_LOG=unimp and QEMU_STRACE="".
+
+The interesting part in emerge.log is:
+
+  23473 socket(16,,IPPROTO_IP) = 5
+  23473 bind(5,274886353720,12,0,1,274889671712) = 0
+  23473 sendto(5,275542232672,38,0,274886353960,12) = -1 errno=95 (Operation not supported)
+  23473 close(5) = 0
+  Unable to configure loopback interface: Operation not supported
+
+So you're right 16 is AF_NETLINK
+
+At QEMU level only one function returns  EOPNOTSUPP, the one managing RTM_* operations (RTM_GETLINK, RTM_GETADDR, ...) and it doesn't manage a bunch of them.
+
+Could you provide a step by step example to reproduce the problem?
+
+def _configure_loopback_interface():
+	"""
+	Configure the loopback interface.
+	"""
+
+	# We add some additional addresses to work around odd behavior in glibc's
+	# getaddrinfo() implementation when the AI_ADDRCONFIG flag is set.
+	#
+	# For example:
+	#
+	#   struct addrinfo *res, hints = { .ai_family = AF_INET, .ai_flags = AI_ADDRCONFIG };
+	#   getaddrinfo("localhost", NULL, &hints, &res);
+	#
+	# This returns no results if there are no non-loopback addresses
+	# configured for a given address family.
+	#
+	# Bug: https://bugs.gentoo.org/690758
+	# Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12377#c13
+
+	# Avoid importing this module on systems that may not support netlink sockets.
+	from portage.util.netlink import RtNetlink
+
+	try:
+		with RtNetlink() as rtnl:
+			ifindex = rtnl.get_link_ifindex(b'lo')
+			rtnl.set_link_up(ifindex)
+			rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
+			if _has_ipv6():
+				rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
+	except EnvironmentError as e:
+		writemsg("Unable to configure loopback interface: %s\n" % e.strerror, noiselevel=-1)
+
+If I execute _configure_loopback_interface in a qemu-aarch64 chroot, I see the following error.
+
+Unable to configure loopback interface: Operation not supported
+
+https://bugs.gentoo.org/703276 explains the issue.
+
+You can obtain portage source code from https://gentoo.osuosl.org/distfiles/portage-2.3.84.tar.bz2
+
+I've copied the file portage-2.3.84/build/lib.linux-x86_64-3.7/portage/util/netlink.py from portage to my local directory and run the following script:
+
+cat > rtnetlink.py <<EOF
+import socket
+
+__has_ipv6 = None
+
+def _has_ipv6():
+        """
+        Test that both userland and kernel support IPv6, by attempting
+        to create a socket and listen on any unused port of the IPv6
+        ::1 loopback address.
+
+        @rtype: bool
+        @return: True if IPv6 is supported, False otherwise.
+        """
+        global __has_ipv6
+
+        if __has_ipv6 is None:
+                if socket.has_ipv6:
+                        sock = None
+                        try:
+                                # With ipv6.disable=0 and ipv6.disable_ipv6=1, socket creation
+                                # succeeds, but then the bind call fails with this error:
+                                # [Errno 99] Cannot assign requested address.
+                                sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
+                                sock.bind(('::1', 0))
+                        except EnvironmentError:
+                                __has_ipv6 = False
+                        else:
+                                __has_ipv6 = True
+                        finally:
+                                # python2.7 sockets do not support context management protocol
+                                if sock is not None:
+                                        sock.close()
+                else:
+                        __has_ipv6 = False
+
+        return __has_ipv6
+
+def _configure_loopback_interface():
+        """
+        Configure the loopback interface.
+        """
+
+        from netlink import RtNetlink
+        try:
+                with RtNetlink() as rtnl:
+                        ifindex = rtnl.get_link_ifindex(b'lo')
+                        rtnl.set_link_up(ifindex)
+                        rtnl.add_address(ifindex, socket.AF_INET, '10.0.0.1', 8)
+                        if _has_ipv6():
+                                rtnl.add_address(ifindex, socket.AF_INET6, 'fd::1', 8)
+        except EnvironmentError as e:
+                print("Unable to configure loopback interface: %s\n" % e.strerror)
+
+_configure_loopback_interface()
+EOF
+
+And I have no error in an aarch64/ubunut eoan chroot.
+
+sudo QEMU_STRACE= unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
+...
+675051 socket(PF_NETLINK,,NETLINK_ROUTE) = 3
+675051 bind(3,{nl_family=AF_NETLINK,nl_pid=0,nl_groups=0}, 12) = 0
+675051 sendto(3,274891222784,38,0,274886293096,12) = 38
+...
+
+sudo strace -yyy unshare --net chroot chroot/arm64/eoan python3 rtnetlink.py
+
+..
+socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 3<NETLINK:[26260481]>
+bind(3<NETLINK:[26260481]>, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
+sendto(3<NETLINK:[26260481]>, {{len=38, type=0x12 /* NLMSG_??? */, flags=NLM_F_REQUEST, seq=1, pid=0}, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x06\x00\x03\x00\x6c\x6f"}, 38, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 38
+...
+
+So I need to know which version you are using (qemu, kernel host).
+
+
+
+qemu-4.0.0
+
+> uname -a
+Linux gentoo 4.19.97-gentoo #3 SMP PREEMPT Mon Feb 10 15:09:44 KST 2020 x86_64 AMD FX(tm)-8300 Eight-Core Processor AuthenticAMD GNU/Linux
+
+Could you run something like "sudo strace -yyy unshare --net chroot ..." with your failing binary to see what returns the host kernel?
+
+Can you rephrase your question? I don't know what to do with your question.
+
+I need the strace result of _configure_loopback_interface in a qemu-aarch64 chroot.
+
+But as strace cannot be started in the chroot you must strace the "chroot" command and its children.
+
+So something like "sudo strace -yyy chroot <your chroot directory> <your test path>"
+
+I just called _configure_loopback_interface in a qemu-aarch64 chroot, and the error is not reproducible with qemu-4.2.0. Has it been fixed?
+
+Yes, it's fixed in v4.2.0, and with the help of your test program I've bisect to the fix:
+
+commit 1645fb5a1e537f85eda744bfa6e9d3dda047ba28
+Author: Shu-Chun Weng <email address hidden>
+Date:   Thu Oct 17 17:19:20 2019 -0700
+
+    Fix unsigned integer underflow in fd-trans.c
+    
+    In any of these `*_for_each_*` functions, the last entry in the buffer (so the
+    "remaining length in the buffer" `len` is equal to the length of the
+    entry `nlmsg_len`/`nla_len`/etc) has size that is not a multiple of the
+    alignment, the aligned lengths `*_ALIGN(*_len)` will be greater than `len`.
+    Since `len` is unsigned (`size_t`), it underflows and the loop will read
+    pass the buffer.
+    
+    This may manifest as random EINVAL or EOPNOTSUPP error on IO or network
+    system calls.
+    
+    Signed-off-by: Shu-Chun Weng <email address hidden>
+    Reviewed-by: Laurent Vivier <email address hidden>
+    Message-Id: <email address hidden>
+    Signed-off-by: Laurent Vivier <email address hidden>
+
+
diff --git a/results/classifier/105/socket/1861884 b/results/classifier/105/socket/1861884
new file mode 100644
index 00000000..e68b0e69
--- /dev/null
+++ b/results/classifier/105/socket/1861884
@@ -0,0 +1,50 @@
+socket: 0.964
+network: 0.883
+other: 0.856
+device: 0.833
+graphic: 0.801
+instruction: 0.744
+vnc: 0.713
+mistranslation: 0.710
+semantic: 0.581
+boot: 0.558
+KVM: 0.375
+assembly: 0.304
+
+qemu socket multicast not working
+
+Running two qemu vms on the same socket multicast address:
+
+  qemu-system-x86_64 -m 2048 -smp 2 -serial mon:stdio -display none -vga none
+    -nodefaults -accel hax
+    -netdev user,id=mynet0
+    -device virtio-net-pci,netdev=mynet0
+    -netdev socket,id=vlan,mcast=239.192.0.1:1235
+    -device virtio-net-pci,netdev=vlan
+    -device virtio-rng-pci
+    -drive file=worker.qcow2,if=virtio
+    -drive file=cloud-init.iso,format=raw,if=virtio
+
+The two machines have a static ip on the socket network interface, 192.168.100.11 and 192.168.100.12, but are unable to reach each other. 
+
+Is there additional configuration necessary on macos? Does this only work on Linux?
+
+guest OS: Debian 10 (Buster)
+host OS: macOS 10.15.2
+qemu: 4.2.0
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1867601 b/results/classifier/105/socket/1867601
new file mode 100644
index 00000000..dcb666c1
--- /dev/null
+++ b/results/classifier/105/socket/1867601
@@ -0,0 +1,34 @@
+socket: 0.974
+graphic: 0.871
+network: 0.848
+device: 0.786
+instruction: 0.772
+other: 0.637
+mistranslation: 0.596
+vnc: 0.592
+semantic: 0.516
+boot: 0.475
+assembly: 0.245
+KVM: 0.209
+
+test-char not concurrent with unix socket
+
+'make check-unit' might fail when running multiple tests in parallel.
+
+Apparently occurred on OSX CI:
+https://travis-ci.org/github/philmd/qemu/jobs/662357430
+
+Guess is same unix path used:
+
+static SocketAddress unixaddr = {
+    .type = SOCKET_ADDRESS_TYPE_UNIX,
+    .u.q_unix.path = (char *)"test-char.sock",
+};
+
+Note, other tests in this file use g_dir_make_tmp().
+
+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/105/socket/1868221 b/results/classifier/105/socket/1868221
new file mode 100644
index 00000000..733160c8
--- /dev/null
+++ b/results/classifier/105/socket/1868221
@@ -0,0 +1,76 @@
+socket: 0.425
+mistranslation: 0.409
+device: 0.407
+semantic: 0.379
+network: 0.294
+boot: 0.257
+graphic: 0.251
+instruction: 0.224
+other: 0.205
+vnc: 0.176
+KVM: 0.092
+assembly: 0.091
+
+/usr/share/applications/qemu.desktop should have an "Exec=" key.
+
+According to the www.freedesktop.org .desktop-file specification, all "Application" desktop files should have an "Exec=" key. The one in qemu doesn't. 
+
+This can be easily verified by running kbuildsycoca4 if KDE4 is present, but the issue is not DE-dependent.
+
+Which binary exactly should be assigned as the default one, I don't know.
+
+The specification can be seen here:
+
+https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables
+
+Adding an exec field would not be right, because QEMU can't simply be launched from the desktop without any arguments. There needs to be a long string of arguments given that are different for every QEMU that is launched. The only viable way to actually launch QEMU is interactively from the terminal, or indirectly via a 3rd party app like virt-manager. We only created the qemu.desktop file in the first place because Wayland needs this to be present in order to identify what Icon to display for a window. 
+
+Note that  QEMU sets the NoDisplay=true property to tell desktops not to display this entry. I don't think KDE should be warning about missing Exec entry in this case.
+
+
+I'll report a bug in KDE and let's see if the guys agree. Maybe it is a deficiency of the .desktop specification.
+
+
+Thank you Lockywolf for this bug report.  Have you filed one against KDE as you previously mentioned?  If so, could you provide us with a link?  Thanks in advance!
+
+I am sorry I haven't dealt with this bug for quite a while. KDE 5 is not properly working on my distro, and I wanted to test it when it stabilises. 
+
+If qemu dislikes long-standing bugs, this bug can be closed, and I'll open a new one when I have time to test it on the new KDE.
+
+
+What's the actual problem we're trying to solve here? What needs to be tested?
+
+I can confirm that this behaviour is still present on kde 5.20.4.
+
+You can run e.g. khelpcenter and observe:
+
+kf.service.services: The desktop entry file "/usr/share/applications/qemu.desktop" has Type= "Application" but no Exec line
+kf.service.sycoca: Invalid Service :  "/usr/share/applications/qemu.desktop" 
+
+
+A bug on KDE bug tracker:
+
+https://bugs.kde.org/show_bug.cgi?id=430157
+
+
+The QEMU project is currently considering to move its bug tracking to
+another system. For this we need to know which bugs are still valid
+and which could be closed already. Thus we are setting older bugs to
+"Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/440
+
+
diff --git a/results/classifier/105/socket/1870331 b/results/classifier/105/socket/1870331
new file mode 100644
index 00000000..a70f94e7
--- /dev/null
+++ b/results/classifier/105/socket/1870331
@@ -0,0 +1,91 @@
+socket: 0.830
+instruction: 0.747
+network: 0.747
+other: 0.729
+device: 0.722
+assembly: 0.700
+graphic: 0.626
+semantic: 0.562
+boot: 0.560
+vnc: 0.555
+KVM: 0.503
+mistranslation: 0.498
+
+default nic device created even though supplied by configfile
+
+QEMU emulator version 4.1.94
+
+Documentation states that qemu will create a default nic as long as not explicitly forbidden (-nic none) or defined ( e.g. -nic <options>).
+
+Observation:
+Even though qemu-system-ppc is started with "-readconfig" (which defines a nic), another nic gets created. When additionally suppling "-nic none", only the nic of the config file is created.
+As matter of fact, if all items that are defined in config file are supplied as command line arguments, no further nic is created. 
+
+Expectation:
+When a nic is defined in config file, the default guest-nic should not get created.
+That would match behavior when all items, defined in config file are supplied as command line arguments.
+
+
+Attached config file.
+
+(qemu) info pci
+ Bus 0, device 0, function 0:
+ Host bridge: PCI device 1057:0002
+ PCI subsystem 1af4:1100
+ id ""
+ Bus 0, device 1, function 0:
+ VGA controller: PCI device 1234:1111
+ PCI subsystem 1af4:1100
+ BAR0: 32 bit prefetchable memory at 0x80000000 [0x80ffffff].
+ BAR2: 32 bit memory at 0x81000000 [0x81000fff].
+ BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
+ id ""
+ Bus 0, device 2, function 0:
+ Ethernet controller: PCI device 10ec:8029
+ PCI subsystem 1af4:1100
+ IRQ 23.
+ BAR0: I/O at 0x1000 [0x10ff].
+ BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe].
+ id ""
+ Bus 0, device 3, function 0:
+ Ethernet controller: PCI device 10ec:8029
+ PCI subsystem 1af4:1100
+ IRQ 24.
+ BAR0: I/O at 0x1100 [0x11ff].
+ BAR6: 32 bit memory at 0xffffffffffffffff [0x0007fffe].
+ id ""
+
+
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1877015 b/results/classifier/105/socket/1877015
new file mode 100644
index 00000000..c6e94cd1
--- /dev/null
+++ b/results/classifier/105/socket/1877015
@@ -0,0 +1,192 @@
+semantic: 0.998
+assembly: 0.998
+socket: 0.998
+instruction: 0.998
+graphic: 0.997
+other: 0.997
+device: 0.997
+vnc: 0.997
+network: 0.996
+boot: 0.996
+mistranslation: 0.993
+KVM: 0.992
+
+virtio only support packed ring size power of 2
+
+Issue discription：
+When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+
+It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 between 256 and 1024
+
+Analysis:
+According to virtio1.1 spec, the packed queue size value does not have to be a power of 2.
+
+Maybe the virtio need to be revised?
+
+On Wed, May 6, 2020 at 10:51 AM xuan <email address hidden> wrote:
+
+> Public bug reported:
+>
+> Issue discription：
+> When QEMU starts with "-device
+> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+>
+> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
+> between 256 and 1024
+>
+> Analysis:
+> According to virtio1.1 spec, the packed queue size value does not have to
+> be a power of 2.
+>
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+>
+> --
+> You received this bug notification because you are a member of qemu-
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1877015
+>
+> Title:
+>   virtio only support packed ring size power of 2 between 256 and 1024
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Issue discription：
+>   When QEMU starts with "-device
+> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+>
+>   It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
+>   between 256 and 1024
+>
+>   Analysis:
+>   According to virtio1.1 spec, the packed queue size value does not have
+> to be a power of 2.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions
+>
+>
+
+-- 
+         此致
+礼
+罗勇刚
+Yours
+    sincerely,
+Yonggang Luo
+
+
+Thank you for your reply. I think the code should add the handling for packed ring size to follow the spec.
+
+Thank you for your reply.  I think the code should add the handling for packed ring size to follow the spec.
+
+-----Original Message-----
+From: <email address hidden> <email address hidden> On Behalf Of Yonggang Luo
+Sent: Wednesday, May 6, 2020 12:32 PM
+To: Ding, Xuan <email address hidden>
+Subject: Re: [Bug 1877015] [NEW] virtio only support packed ring size power of 2 between 256 and 1024
+
+Maybe the virtio need to be revised?
+
+On Wed, May 6, 2020 at 10:51 AM xuan <email address hidden> wrote:
+
+> Public bug reported:
+>
+> Issue discription：
+> When QEMU starts with "-device
+> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+>
+> It raises error: Invalid rx_queue_size (= 1025), must be a power of 2 
+> between 256 and 1024
+>
+> Analysis:
+> According to virtio1.1 spec, the packed queue size value does not have 
+> to be a power of 2.
+>
+> ** Affects: qemu
+>      Importance: Undecided
+>          Status: New
+>
+> --
+> You received this bug notification because you are a member of qemu- 
+> devel-ml, which is subscribed to QEMU.
+> https://bugs.launchpad.net/bugs/1877015
+>
+> Title:
+>   virtio only support packed ring size power of 2 between 256 and 1024
+>
+> Status in QEMU:
+>   New
+>
+> Bug description:
+>   Issue discription：
+>   When QEMU starts with "-device
+> virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+>
+>   It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
+>   between 256 and 1024
+>
+>   Analysis:
+>   According to virtio1.1 spec, the packed queue size value does not 
+> have to be a power of 2.
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions
+>
+>
+
+-- 
+         此致
+礼
+罗勇刚
+Yours
+    sincerely,
+Yonggang Luo
+
+--
+You received this bug notification because you are subscribed to the bug report.
+https://bugs.launchpad.net/bugs/1877015
+
+Title:
+  virtio only support packed ring size power of 2
+
+Status in QEMU:
+  New
+
+Bug description:
+  Issue discription：
+  When QEMU starts with "-device virtio-net-pci,netdev=netdev0,mac=52:54:00:00:00:01,disable-modern=false,mrg_rxbuf=on,rx_queue_size=1025,tx_queue_size=1025,mq=on,vectors=15,packed=on"
+
+  It raises error: Invalid rx_queue_size (= 1025), must be a power of 2
+  between 256 and 1024
+
+  Analysis:
+  According to virtio1.1 spec, the packed queue size value does not have to be a power of 2.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/qemu/+bug/1877015/+subscriptions
+
+
+The QEMU project is currently moving its bug tracking to another system.
+For this we need to know which bugs are still valid and which could be
+closed already. Thus we are setting older bugs to "Incomplete" now.
+
+If you still think this bug report here is valid, then please switch
+the state back to "New" within the next 60 days, otherwise this report
+will be marked as "Expired". Or please mark it as "Fix Released" if
+the problem has been solved with a newer version of QEMU already.
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/270
+
+
diff --git a/results/classifier/105/socket/1882784 b/results/classifier/105/socket/1882784
new file mode 100644
index 00000000..a8e80a58
--- /dev/null
+++ b/results/classifier/105/socket/1882784
@@ -0,0 +1,78 @@
+socket: 0.820
+network: 0.799
+device: 0.762
+graphic: 0.751
+instruction: 0.748
+vnc: 0.741
+boot: 0.735
+assembly: 0.703
+other: 0.703
+KVM: 0.671
+mistranslation: 0.668
+semantic: 0.630
+
+Legacy IGD passthrough in QEMU 5 disabled
+
+Bug with tag v5.0.0, or commit fdd76fecdde1ad444ff4deb7f1c4f7e4a1ef97d6
+
+As of QEMU 5 Legacy IGD PT is no longer working.
+
+Host is a Xeon E3-1226 v3 and my method to test is to run the following:
+
+./qemu-system-x86_64 \
+  -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1f' \
+  -device 'vfio-pci,host=00:02.0,addr=02.0' \
+  -L '/usr/share/kvm' \
+  -nographic \
+  -vga none \
+  -nodefaults
+
+in the hope of seeing a "IGD device 0000:00:02.0 cannot support legacy mode due to existing devices at address 1f.0" error.
+
+The culprit appears to be this commit:
+
+https://github.com/qemu/qemu/commit/29d62771c81d8fd244a67c14a1d968c268d3fb19
+
+Specifically the following block in pci-quirks.c:
+
+#ifdef CONFIG_VFIO_IGD
+    vfio_probe_igd_bar4_quirk(vdev, nr);
+#endif
+
+as the kconfig variable CONFIG_VFIO_IGD doesn't appear to be available outside of makefiles as described here: https://qemu.weilnetz.de/doc/devel/kconfig.html. I can confirm that the igd code is being pulled in as removing this check, as would defining the variable I presume, makes Legacy IGD PT work again (ie I see the expected "existing devices" error).
+
+I first spotted this in Proxmox, but have confirmed the bug by building QEMU sources.
+
+Hi! That info in kconfig.html is not up to date anymore, we are generating now #defines for the Kconfig switches. And in my build tree, I can see:
+
+$ grep CONFIG_VFIO_IGD *-softmmu/*.h
+x86_64-softmmu/config-devices.h:#define CONFIG_VFIO_IGD 1
+
+... what's missing in that file is simply a "#include "config-devices.h" ... sorry, that fell somehow through the cracks. I'll prepare a patch for that.
+
+Looks similar to https://bugs.launchpad.net/qemu/+bug/1879175
+
+Looks the same, although the title was misleading so I missed it.
+
+@Thomas, I used the same patch and verified that it works (I know you don't pick up patches here but I presume you have your own):
+
+diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
+index 2d348f8237..a633df965e 100644
+--- a/hw/vfio/pci-quirks.c
++++ b/hw/vfio/pci-quirks.c
+@@ -25,6 +25,7 @@
+ #include "hw/qdev-properties.h"
+ #include "pci.h"
+ #include "trace.h"
++#include "config-devices.h"
+
+ /*
+  * List of device ids/vendor ids for which to disable
+
+
+Patch is on the list now:
+https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg02567.html
+
+Patch has been included:
+https://git.qemu.org/?p=qemu.git;a=commitdiff;h=643a4eacef87a318c
+
diff --git a/results/classifier/105/socket/1885718 b/results/classifier/105/socket/1885718
new file mode 100644
index 00000000..231a4703
--- /dev/null
+++ b/results/classifier/105/socket/1885718
@@ -0,0 +1,80 @@
+socket: 0.848
+other: 0.825
+graphic: 0.816
+semantic: 0.802
+device: 0.776
+instruction: 0.771
+network: 0.681
+mistranslation: 0.661
+vnc: 0.642
+boot: 0.581
+KVM: 0.560
+assembly: 0.495
+
+qemu/target/mips/op_helper.c:943:5: style:inconclusive: Found duplicate branches for 'if' and 'else'
+
+Source code is
+
+    if (other_tc == other->current_tc) {
+        tccause = other->CP0_Cause;
+    } else {
+        tccause = other->CP0_Cause;
+    }
+
+Thank you for reporting this!
+
+Believe it or not, this has been a know issue to us for a while. We contacted the original contributor, and he says he can't recall what he actually meant when he wrote the segment. We left it as is until he remembers. However, this seems not likely to happen, and probably we will issue a fix soon. In any case, it is good that you reported it, many thanks!
+
+You already reported that 6 months ago:
+https://bugs.launchpad.net/qemu/+bug/1856706
+
+From: Aleksandar Markovic <email address hidden>
+
+Remove the segment:
+
+      if (other_tc == other->current_tc) {
+          tccause = other->CP0_Cause;
+      } else {
+          tccause = other->CP0_Cause;
+      }
+
+Original contributor can't remember what was his intention.
+
+Fixes: 5a25ce9487 ("mips: Hook in more reg accesses via mttr/mftr")
+Buglink: https://bugs.launchpad.net/qemu/+bug/1885718
+Signed-off-by: Aleksandar Markovic <email address hidden>
+Message-Id: <email address hidden>
+Signed-off-by: Philippe Mathieu-Daudé <email address hidden>
+---
+Cc: Bug 1885718 <email address hidden>
+
+ target/mips/cp0_helper.c | 9 +--------
+ 1 file changed, 1 insertion(+), 8 deletions(-)
+
+diff --git a/target/mips/cp0_helper.c b/target/mips/cp0_helper.c
+index bbf12e4a97..de64add038 100644
+--- a/target/mips/cp0_helper.c
++++ b/target/mips/cp0_helper.c
+@@ -375,16 +375,9 @@ target_ulong helper_mftc0_entryhi(CPUMIPSState *env)
+ target_ulong helper_mftc0_cause(CPUMIPSState *env)
+ {
+     int other_tc = env->CP0_VPEControl & (0xff << CP0VPECo_TargTC);
+-    int32_t tccause;
+     CPUMIPSState *other = mips_cpu_map_tc(env, &other_tc);
+ 
+-    if (other_tc == other->current_tc) {
+-        tccause = other->CP0_Cause;
+-    } else {
+-        tccause = other->CP0_Cause;
+-    }
+-
+-    return tccause;
++    return other->CP0_Cause;
+ }
+ 
+ target_ulong helper_mftc0_status(CPUMIPSState *env)
+-- 
+2.21.3
+
+
+
diff --git a/results/classifier/105/socket/1886 b/results/classifier/105/socket/1886
new file mode 100644
index 00000000..b333db2c
--- /dev/null
+++ b/results/classifier/105/socket/1886
@@ -0,0 +1,30 @@
+socket: 0.931
+device: 0.818
+graphic: 0.746
+semantic: 0.729
+instruction: 0.646
+network: 0.532
+vnc: 0.509
+mistranslation: 0.331
+other: 0.322
+boot: 0.267
+KVM: 0.070
+assembly: 0.049
+
+migration-test is unreliable
+Description of problem:
+The following intermittent failure occurred in the CI:
+
+```
+>>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=116 QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh QTEST_QEMU_BINARY=./qemu-system-x86_64 /builds/qemu-project/qemu/build/tests/qtest/migration-test --tap -k
+――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
+stderr:
+qemu-system-x86_64: Unable to read from socket: Connection reset by peer
+Memory content inconsistency at 5b43000 first_byte = bd last_byte = bc current = 4f hit_edge = 1
+**
+ERROR:../tests/qtest/migration-test.c:300:check_guests_ram: assertion failed: (bad == 0)
+(test program exited with status code -6)
+```
+  
+You can find the full output here:
+https://gitlab.com/qemu-project/qemu/-/jobs/5080200417
diff --git a/results/classifier/105/socket/1887604 b/results/classifier/105/socket/1887604
new file mode 100644
index 00000000..8ffd2350
--- /dev/null
+++ b/results/classifier/105/socket/1887604
@@ -0,0 +1,79 @@
+socket: 0.489
+mistranslation: 0.311
+graphic: 0.301
+semantic: 0.282
+other: 0.253
+vnc: 0.252
+network: 0.220
+device: 0.208
+KVM: 0.189
+instruction: 0.142
+assembly: 0.135
+boot: 0.080
+
+Forward host UNIX socket to guest TCP port
+
+Hello. I've been racking my brain trying to work out if this is possible.
+
+I would like to be able to forward to a guest TCP port, via a host UNIX socket to avoid opening a TCP port on the host. For example:
+
+qemu-system-i386 [...] -nic user,hostfwd=unix:/path/to/socket-:22
+
+and then connect to the VM like:
+
+ssh -o "ProxyCommand socat - unix-connect:/path/to/socket" user@0.0.0.0
+
+QEMU, as versatile as it is, doesn't appreciate my intuited syntax "hostfwd=unix:...". It is also unhappy with:
+
+qemu-system-i386 [...] \
+    -chardev socket,id=foo,path=/path/to/socket,server,nowait \
+    -nic user,hostfwd=chardev:foo-:22
+
+And:
+
+qemu-system-i386 [...] \
+    -nic user \
+    -chardev socket,id=foo,path=/path/to/socket,server,nowait \
+    -chardev socket,id=foo,host=10.0.2.15,port=22
+
+I already found out how to connect in the opposite direction, **from** guest TCP to host UNIX, via guestfwd -> cmd -> socat. So I feel like there ought to be a way.
+
+If this is not yet a feature I would like to request it, and if it is, please tell me how!
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/347
+
+
diff --git a/results/classifier/105/socket/1888303 b/results/classifier/105/socket/1888303
new file mode 100644
index 00000000..e0867bcc
--- /dev/null
+++ b/results/classifier/105/socket/1888303
@@ -0,0 +1,67 @@
+socket: 0.629
+instruction: 0.629
+device: 0.625
+network: 0.610
+graphic: 0.599
+other: 0.574
+semantic: 0.546
+mistranslation: 0.517
+boot: 0.491
+vnc: 0.477
+assembly: 0.473
+KVM: 0.418
+
+Intermittent buggines with user mode emulation of x86-64 on aarch64
+
+QEMU Version: 5.0.0
+./configure --target-list=x86_64-linux-user --enable-user --prefix=/opt/qemu --static
+
+Testing using node_exporter from pmm-client-1.17.4-1.el8.x86_64.rpm
+
+aarch64 system is running CentOS 8 with a mainline 5.4.52 kernel built for 4KB memory pages.
+
+On aarch64 machine, invoke:
+
+./qemu-x86_64-static /usr/local/percona/pmm-client/node_exporter.x86_64 -web.listen-address=192.168.0.10:42000 -web.auth-file=/usr/local/percona/pmm-client/pmm.yml -web.ssl-key-file=/usr/local/percona/pmm-client/server.key -web.ssl-cert-file=/usr/local/percona/pmm-client/server.crt -collectors.enabled=diskstats,filefd,filesystem,loadavg,meminfo,netdev,netstat,stat,time,uname,vmstat,meminfo_numa,textfile
+
+Most of the time it will outright segfault within a few seconds, seemingly when the prometheus server polls for data.
+
+But, about once every 10 times, it will not sefault and will continue working just fine forever.
+
+The dynamically linked version of qemu (built without --static) always works without segfaulting, but it just doesn't work, the prometheus server gets no data from it. Again, once in a while it will work, but even when it doesn't work it won't segfault.
+
+This vaguely feels like a memory alignment issue somewhere, but my debug-fu is not quite strong enough to attack the problem.
+
+As another interesting data point - with dynamically linked qemu-x86_64, when it doesn't work, the process is consuming about 140% of CPU. On a successful run, the process is consuming about 30% of CPU.
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" within the next 60 days (otherwise it will get
+closed as "Expired"). We will then eventually migrate the ticket auto-
+matically to the new system (but you won't be the reporter of the bug
+in the new system and thus won't get notified on changes anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1898084 b/results/classifier/105/socket/1898084
new file mode 100644
index 00000000..8dab1fd8
--- /dev/null
+++ b/results/classifier/105/socket/1898084
@@ -0,0 +1,49 @@
+socket: 0.377
+network: 0.274
+boot: 0.217
+device: 0.180
+graphic: 0.149
+vnc: 0.149
+mistranslation: 0.120
+instruction: 0.097
+semantic: 0.090
+other: 0.086
+assembly: 0.058
+KVM: 0.054
+
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
+
+I have a virtual raspberry py that I am running qemu 5.1.0 for MacOS.
+
+Here is the command line I used:
+
+qemu-system-arm \
+  -M versatilepb \
+  -cpu arm1176 \
+  -m 256 \
+  -drive file=2020-08-20-raspios-buster-armhf-lite.img,if=none,index=0,media=disk,format=raw,id=disk0 \
+  -device virtio-blk-pci,drive=disk0,disable-modern=on,disable-legacy=off \
+  -net nic -net user,hostfwd=tcp::5022-:22 \
+  -dtb versatile-pb-buster-5.4.51.dtb \
+  -kernel kernel-qemu-5.4.51-buster \
+  -append "root=/dev/vda2 panic=1" \
+  -no-reboot \
+  -serial stdio
+
+When trying to ssh from another machine while docker was running inside the VM, I got the following error:
+
+Assertion failed: (buf_len != 0), function soread, file /private/tmp/qemu-20200813-13289-1g95loa/qemu-5.1.0/slirp/src/socket.c, line 183
+../boot.sh: line 12:  8592 Abort trap: 6
+
+libslirp is a separate project now, and I see that you already reported it there (https://gitlab.freedesktop.org/slirp/libslirp/-/issues/29), so I'm closing this QEMU ticket now.
+
+Hmm, thinking about it twice, maybe let's rather keep this open, to make sure that we update to the right version of libslirp in QEMU once the fix is released there.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/284
+
+
diff --git a/results/classifier/105/socket/1901440 b/results/classifier/105/socket/1901440
new file mode 100644
index 00000000..746d9669
--- /dev/null
+++ b/results/classifier/105/socket/1901440
@@ -0,0 +1,137 @@
+socket: 0.980
+instruction: 0.972
+other: 0.972
+semantic: 0.971
+graphic: 0.970
+assembly: 0.969
+network: 0.968
+device: 0.966
+mistranslation: 0.948
+vnc: 0.940
+boot: 0.938
+KVM: 0.923
+
+Instability in IVSHMEM after updating QEMU 4.2 -> 5.0
+
+Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0 results in the virtual machines freezing when the IVSHMEM interface is active.  This workstation typically runs several windows 10 virtual machines that are accessed locally:  two using the spice viewer and one that uses an passthrough assigned GPU accessed through a viewer called Looking Glass.  Looking Glass uses the IVSHMEM device interface to pass captured frames from the windows virtual machine to the linux host for display by a viewer application.
+
+This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2).  It handled a variety of heavy loads all day it never froze or crashed.  It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered by high levels of SHM activity.  I was able to reliably reproduce the problem when playing a video in the looking-glass vm while playing another video in a spice vm.  Other scenarios would also trigger this problem less reliably, but this video playback scenario would trigger it after 3-5 minutes of playback.
+
+The result of this new instability would manifest itself by all running vms on the host freezing but the host was not visibly effected.  I could find no warnings or errors in any relevant system or QEMU logs.  It wasn't just spice, when I accessed the gpu-passthru vm via directly assigned devices it was frozen, still outputting video of the last frame before the crash.  All vms would have to be force-shutdown and the host rebooted to regain vm functionality.  Just forcing shutdown and restarting a vm would result in showing 'running' status but it would be frozen and inaccessible until system reboot.
+
+I suspect this is a QEMU host / kernel error for several reasons:  Having to reboot the host, insensitivity to VM changes including virtio-win version, etc.  I suspect it's related to IVSHMEM due to the correlation of the freeze to the looking-glass related activity.
+
+This might be kernel / PCIe / power management related in some way.  While experimenting to troubleshoot this issue I was able to trigger the error more quickly by disabling PCIe power management in the BIOS.
+
+The system was 100% stable under QEMU 5.0 when not running the looking-glass vm, quite stable when the looking-glass vm was idle or lightly used, but appeared increasingly unstable as SHM activity increased.
+
+Sorry if this is a bit anecdotal, this is my work machine and unfortunately today I was forced to rollback restore to Ubuntu 20.08 (QEMU 4.2) from backup so I can work on Monday.  The system returned to 100% stability after returning to 20.08.
+
+If requested I can restore the Ubuntu 20.10 snapshot to reproduce & gather information as directed.
+
+Can you reproduce this with the latest upstream QEMU release (v5.1)? Or did you only try with the versions that ship with Ubuntu?
+
+This problem occurred with the QEMU 5.0 version that was distributed with the Ubuntu 20.10 update.
+
+
+
+Ok, so I'm moving this to the Ubuntu bug tracker.
+
+Hi Dave,
+there is no Ubuntu 20.08 I'd know of I assume you mean 20.04 (Focal Fossa) as that would have qemu 4.2. 
+We'd need to start sorting out if this is a kernel or qemu issue.
+Since you are know rolled back to 20.04 you might give [1] a try that just bumps the core virt components but keeps everything else on 20.04.
+
+Report back if that triggers the issue on Focal. If it does you can then go back to the packages of 21.04 one by one e.g. bios first, then libvirt, ... until we can pinpoint if it indeed is qemu or another package.
+If instead it works with these builds then that implies we need to look at the kernel, in that case still speak up here please.
+
+[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports/
+
+ Hi Christian,
+Thanks of your interest. Yes, meant to say Ubuntu 20.04.1 LTS.
+This weekend if I have the time I'm going to install 20.10 on a separate partition and experiment on that.
+Would you happen to know if anyone else is reporting similar problems?
+If I find anything interesting I'll report back on this email thread.
+     On Tuesday, October 27, 2020, 08:30:51 AM PDT, Christian Ehrhardt  <email address hidden> wrote:  
+ 
+ Hi Dave,
+there is no Ubuntu 20.08 I'd know of I assume you mean 20.04 (Focal Fossa) as that would have qemu 4.2. 
+We'd need to start sorting out if this is a kernel or qemu issue.
+Since you are know rolled back to 20.04 you might give [1] a try that just bumps the core virt components but keeps everything else on 20.04.
+
+Report back if that triggers the issue on Focal. If it does you can then go back to the packages of 21.04 one by one e.g. bios first, then libvirt, ... until we can pinpoint if it indeed is qemu or another package.
+If instead it works with these builds then that implies we need to look at the kernel, in that case still speak up here please.
+
+[1]: https://launchpad.net/~canonical-server/+archive/ubuntu/server-
+backports/
+
+** Changed in: qemu (Ubuntu)
+      Status: New => Incomplete
+
+-- 
+You received this bug notification because you are subscribed to the bug
+report.
+https://bugs.launchpad.net/bugs/1901440
+
+Title:
+  Instability in IVSHMEM after updating QEMU 4.2 -> 5.0
+
+Status in qemu package in Ubuntu:
+  Incomplete
+
+Bug description:
+  Updating Ubuntu from 20.08 to 20.10 which updates QEMU from 4.2 to 5.0
+  results in the virtual machines freezing when the IVSHMEM interface is
+  active.  This workstation typically runs several windows 10 virtual
+  machines that are accessed locally:  two using the spice viewer and
+  one that uses an passthrough assigned GPU accessed through a viewer
+  called Looking Glass.  Looking Glass uses the IVSHMEM device interface
+  to pass captured frames from the windows virtual machine to the linux
+  host for display by a viewer application.
+
+  This workstation was 100% stable under Ubuntu 20.08 (QEMU 4.2).  It
+  handled a variety of heavy loads all day it never froze or crashed.
+  It became unstable under Ubuntu 20.10 (QEMU 5.0), seemingly triggered
+  by high levels of SHM activity.  I was able to reliably reproduce the
+  problem when playing a video in the looking-glass vm while playing
+  another video in a spice vm.  Other scenarios would also trigger this
+  problem less reliably, but this video playback scenario would trigger
+  it after 3-5 minutes of playback.
+
+  The result of this new instability would manifest itself by all
+  running vms on the host freezing but the host was not visibly
+  effected.  I could find no warnings or errors in any relevant system
+  or QEMU logs.  It wasn't just spice, when I accessed the gpu-passthru
+  vm via directly assigned devices it was frozen, still outputting video
+  of the last frame before the crash.  All vms would have to be force-
+  shutdown and the host rebooted to regain vm functionality.  Just
+  forcing shutdown and restarting a vm would result in showing 'running'
+  status but it would be frozen and inaccessible until system reboot.
+
+  I suspect this is a QEMU host / kernel error for several reasons:
+  Having to reboot the host, insensitivity to VM changes including
+  virtio-win version, etc.  I suspect it's related to IVSHMEM due to the
+  correlation of the freeze to the looking-glass related activity.
+
+  This might be kernel / PCIe / power management related in some way.
+  While experimenting to troubleshoot this issue I was able to trigger
+  the error more quickly by disabling PCIe power management in the BIOS.
+
+  The system was 100% stable under QEMU 5.0 when not running the
+  looking-glass vm, quite stable when the looking-glass vm was idle or
+  lightly used, but appeared increasingly unstable as SHM activity
+  increased.
+
+  Sorry if this is a bit anecdotal, this is my work machine and
+  unfortunately today I was forced to rollback restore to Ubuntu 20.08
+  (QEMU 4.2) from backup so I can work on Monday.  The system returned
+  to 100% stability after returning to 20.08.
+
+  If requested I can restore the Ubuntu 20.10 snapshot to reproduce &
+  gather information as directed.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1901440/+subscriptions  
+
+[Expired for qemu (Ubuntu) because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1904 b/results/classifier/105/socket/1904
new file mode 100644
index 00000000..70500cd6a
--- /dev/null
+++ b/results/classifier/105/socket/1904
@@ -0,0 +1,29 @@
+socket: 0.915
+device: 0.852
+graphic: 0.757
+vnc: 0.673
+network: 0.672
+instruction: 0.624
+semantic: 0.535
+other: 0.307
+mistranslation: 0.213
+boot: 0.199
+assembly: 0.090
+KVM: 0.055
+
+Windows LTO build fails
+Description of problem:
+LTO likes to delete `win32_close_exception_handler` which causes an error when linking
+```
+[2736/5786] Linking target qemu-system-avr.exe
+FAILED: qemu-system-avr.exe
+"cc" "-m64" "-mcx16" @qemu-system-avr.exe.rsp
+`win32_close_exception_handler' referenced in section `.xdata' of C:\msys64\tmp\cceRwR4N.ltrans59.ltrans.o: defined in discarded section `.text' of libqemuutil.a.p/util_oslib-win32.c.obj (symbol from plugin)
+collect2.exe: error: ld returned 1 exit status
+```
+Steps to reproduce:
+1. `./configure --enable-lto`
+2. `make`
+Additional information:
+Looks like the offending commit is d89f30b4df13dfe389a4d6cf8a30b2f87c4c166e "win32: wrap socket close() with an exception handler".
+Undoing the commit or marking the exception handler as `__attribute__ ((noinline, used))` both appear to fix the issue.
diff --git a/results/classifier/105/socket/1906948 b/results/classifier/105/socket/1906948
new file mode 100644
index 00000000..1fcc17b1
--- /dev/null
+++ b/results/classifier/105/socket/1906948
@@ -0,0 +1,73 @@
+socket: 0.800
+device: 0.722
+boot: 0.712
+graphic: 0.682
+instruction: 0.584
+semantic: 0.568
+KVM: 0.452
+other: 0.439
+network: 0.393
+vnc: 0.381
+assembly: 0.356
+mistranslation: 0.314
+
+Enabling OpenGL for GUI doesn't work on old laptop
+
+QEMU start command is:
+
+qemu-system-x86_64 -enable-kvm -m 2G -cpu host -smp 2 -cdrom ./linuxmint-20-mate-64bit.iso -boot d -vga virtio -soundhw hda -display gtk,gl=on
+
+
+and QEMU crashes immediately on startup and gives these error messages:
+
+
+qemu_gl_create_compile_shader: compile vertex error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile fragment error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile vertex error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile fragment error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+
+If I remove "gl=on" it will boot. Does this just mean that this hardware is too old to run QEMU with OpenGL enabled in GUI, or is this a bug? 
+
+Host OS is Debian 10, computer is a Lenovo laptop with Core i5-520M CPU and its integrated Intel HD graphics GPU.
+
+QEMU version is 3.1.0 from Debian repositories.
+
+The QEMU project does not support version 3.1 anymore. Can you either please report this to the Debian bug tracker instead, or check whether the problem is still reproducible with the latest version of QEMU (v5.2 will be likely released tomorrow)?
+
+I installed Qemu 5.0.0 from Debian Buster backports and I still get this error.
+
+
+
+qemu_gl_create_compile_shader: compile vertex error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile fragment error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile vertex error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+qemu_gl_create_compile_shader: compile fragment error
+0:2(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, and 1.00 ES
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
+Still happens in 5.2.0 (Debian 1:5.2+dfsg-3~bpo10+1). Is this just due to hardware which is too old?
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/296
+
+
diff --git a/results/classifier/105/socket/1907926 b/results/classifier/105/socket/1907926
new file mode 100644
index 00000000..f94d53ea
--- /dev/null
+++ b/results/classifier/105/socket/1907926
@@ -0,0 +1,51 @@
+socket: 0.921
+device: 0.886
+instruction: 0.854
+other: 0.761
+graphic: 0.652
+network: 0.605
+semantic: 0.580
+mistranslation: 0.532
+vnc: 0.480
+boot: 0.378
+KVM: 0.348
+assembly: 0.300
+
+Implement TPM2 configuration for emulators that provide TCP interface
+
+swtpm provides several interfaces for its emulated device: unix socket (can be used by qemu), chardev. swtpm also provides TCP interface for the device which is very convenient for testing as it does not require root permissions.
+
+It would be very useful to have QEMU to work with TPM devices emulated via TCP.
+
+The QEMU project is currently moving 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 the bug state to "Incomplete" now.
+
+If the bug has already been fixed in the latest upstream version of QEMU,
+then please close this ticket as "Fix released".
+
+If it is not fixed yet and you think that this bug report here is still
+valid, then you have two options:
+
+1) If you already have an account on gitlab.com, please open a new ticket
+for this problem in our new tracker here:
+
+    https://gitlab.com/qemu-project/qemu/-/issues
+
+and then close this ticket here on Launchpad (or let it expire auto-
+matically after 60 days). Please mention the URL of this bug ticket on
+Launchpad in the new ticket on GitLab.
+
+2) If you don't have an account on gitlab.com and don't intend to get
+one, but still would like to keep this ticket opened, then please switch
+the state back to "New" or "Confirmed" within the next 60 days (other-
+wise it will get closed as "Expired"). We will then eventually migrate
+the ticket automatically to the new system (but you won't be the reporter
+of the bug in the new system and thus you won't get notified on changes
+anymore).
+
+Thank you and sorry for the inconvenience.
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/1923692 b/results/classifier/105/socket/1923692
new file mode 100644
index 00000000..47c11b72
--- /dev/null
+++ b/results/classifier/105/socket/1923692
@@ -0,0 +1,29 @@
+socket: 0.872
+network: 0.800
+device: 0.733
+mistranslation: 0.439
+vnc: 0.352
+graphic: 0.346
+semantic: 0.345
+boot: 0.305
+other: 0.278
+instruction: 0.208
+KVM: 0.116
+assembly: 0.058
+
+qemu 5.2.0: Add reconnect option support for netdev socket
+
+Most of qemu socket accepting options (such as chardev) accept among other things a "reconnect" option.
+
+netdev socket however returns: Invalid parameter 'reconnect'
+
+It would make sense that available options for socket links be at least partially normalized (also see issue https://bugs.launchpad.net/qemu/+bug/1903470 which was closed without resolution).
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'expired' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/323
+
+
diff --git a/results/classifier/105/socket/1925449 b/results/classifier/105/socket/1925449
new file mode 100644
index 00000000..e63d29a6
--- /dev/null
+++ b/results/classifier/105/socket/1925449
@@ -0,0 +1,59 @@
+socket: 0.955
+device: 0.889
+vnc: 0.877
+network: 0.848
+instruction: 0.747
+boot: 0.704
+graphic: 0.607
+mistranslation: 0.472
+assembly: 0.400
+semantic: 0.292
+KVM: 0.291
+other: 0.281
+
+Failure building with clang-10 and libssh 
+
+On Fedora 32, configuring with --enable-libssh and building with clang:
+
+qemu 5.2.94
+
+  Compilation
+    host CPU                     : x86_64
+    host endianness              : little
+    C compiler                   : clang-10
+    Host C compiler              : clang-10
+
+  Dependencies
+    libssh support               : YES
+
+triggers:
+
+FAILED: libblock.fa.p/block_ssh.c.o 
+block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations]
+    state = ssh_is_server_known(s->session);
+            ^
+/usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here
+SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session);
+^
+/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
+#define SSH_DEPRECATED __attribute__ ((deprecated))
+                                       ^
+block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations]
+    r = ssh_get_publickey(s->session, &pubkey);
+        ^
+/usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here
+SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key);
+^
+/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED'
+#define SSH_DEPRECATED __attribute__ ((deprecated))
+                                       ^
+2 errors generated.
+
+
+This is an automated cleanup. This bug report has been moved to QEMU's
+new bug tracker on gitlab.com and thus gets marked as 'invalid' now.
+Please continue with the discussion here:
+
+ https://gitlab.com/qemu-project/qemu/-/issues/234
+
+
diff --git a/results/classifier/105/socket/1949 b/results/classifier/105/socket/1949
new file mode 100644
index 00000000..5e93079b
--- /dev/null
+++ b/results/classifier/105/socket/1949
@@ -0,0 +1,25 @@
+socket: 0.935
+device: 0.862
+instruction: 0.801
+network: 0.668
+graphic: 0.646
+mistranslation: 0.523
+assembly: 0.495
+semantic: 0.433
+vnc: 0.401
+KVM: 0.267
+other: 0.250
+boot: 0.222
+
+chardev zombie TCP session
+Description of problem:
+When user terminates TCP session ungracefully (eg: power-cycle or network cable disconnect), the TCP session keeps in established status forever. In this state, new sessions can't access the chardev, since the zombie TCP session keeps exclusive access to chardev.
+Steps to reproduce:
+1.Establish client session to chardev TCP socket.  
+2.Power-off the client machine.  
+3.Establish a new client session  
+4.Observe that old TCP session is never killed and new session can connect but not interact with chardev.
+Additional information:
+Suggestions to resolve this and improve the chardev feature:
+- enable TCP keep-alive for chardev server.
+- allow multiple client sessions concurrently, where chardev output is broadcasted to all client sessions, and chardev input is shared by all clients.
diff --git a/results/classifier/105/socket/2191 b/results/classifier/105/socket/2191
new file mode 100644
index 00000000..e5c07add
--- /dev/null
+++ b/results/classifier/105/socket/2191
@@ -0,0 +1,14 @@
+socket: 0.561
+network: 0.559
+device: 0.556
+boot: 0.445
+KVM: 0.321
+vnc: 0.292
+instruction: 0.242
+other: 0.162
+semantic: 0.127
+graphic: 0.107
+mistranslation: 0.085
+assembly: 0.031
+
+Support exposing exports based on authentication
diff --git a/results/classifier/105/socket/2254 b/results/classifier/105/socket/2254
new file mode 100644
index 00000000..c7753df7
--- /dev/null
+++ b/results/classifier/105/socket/2254
@@ -0,0 +1,14 @@
+socket: 0.931
+network: 0.756
+device: 0.657
+vnc: 0.572
+graphic: 0.443
+instruction: 0.432
+mistranslation: 0.385
+semantic: 0.376
+other: 0.336
+boot: 0.195
+KVM: 0.143
+assembly: 0.103
+
+UNCHECKED_FUNC_RES.LIB.STRICT in /io/channel-socket.c
diff --git a/results/classifier/105/socket/2292 b/results/classifier/105/socket/2292
new file mode 100644
index 00000000..83006be3
--- /dev/null
+++ b/results/classifier/105/socket/2292
@@ -0,0 +1,32 @@
+socket: 0.956
+device: 0.866
+instruction: 0.854
+network: 0.799
+vnc: 0.779
+graphic: 0.760
+other: 0.632
+semantic: 0.562
+mistranslation: 0.453
+boot: 0.413
+assembly: 0.351
+KVM: 0.278
+
+UNIX socket path is too long
+Description of problem:
+At [Unikraft](https://unikraft.org) we facilitate the construction and also runtime lifecycle management of ultra-lightweight virtual machine unikernels.  We have developed [`kraft`](https://github.com/unikraft/kraftkit), an open-source tool which facilitates this across a number of different virtual machine monitors, [including QEMU](https://github.com/unikraft/kraftkit/tree/staging/machine/qemu).
+
+We are receiving increased reports of the following error from our users:
+
+```
+could not start and wait for QEMU process: qemu-system-x86_64: -qmp unix:/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock,server,nowait: UNIX socket path '/Users/__USERNAME__/.local/share/kraftkit/runtime/37a7691a-d402-4760-b493-692bb8d0460a/qemu_control.sock' is too long
+```
+
+We systematically build the relevant QEMU process command line and arguments with flags [via our Go SDK](https://github.com/unikraft/kraftkit/blob/staging/machine/qemu/v1alpha1.go#L180-L229) and include what has become an erroneously long UNIX path for the QAPI control socket which we use to manage instantiated VM instances.
+
+This issue tracks the increasing of maximum path length for the `-qmp` (and maybe other) flags which accept paths.
+Steps to reproduce:
+1. Install [`kraft`](https://github.com/unikraft/kraftkit), [Unikraft](https://unikraft.org)'s companion command-line client;
+2. Update KraftKit's config file to include an arbitrarily long path for `runtime_dir` by editing `~/.config/kraftkit/config.yaml`;
+3. Start a QEMU unikernel instance with `kraft run --arch x86_64 --plat qemu unikraft.org/helloworld:latest`
+Additional information:
+
diff --git a/results/classifier/105/socket/2341 b/results/classifier/105/socket/2341
new file mode 100644
index 00000000..8194d440
--- /dev/null
+++ b/results/classifier/105/socket/2341
@@ -0,0 +1,45 @@
+socket: 0.928
+graphic: 0.924
+device: 0.907
+other: 0.895
+instruction: 0.894
+mistranslation: 0.887
+semantic: 0.809
+network: 0.692
+assembly: 0.555
+boot: 0.537
+vnc: 0.489
+KVM: 0.444
+
+IVSHMEM device doesn't work for sharing memory with virtiofsd
+Description of problem:
+Trying to share a folder on the host to the guest with `virtiofsd` using the `ivshmem-plain` device doesn't work (for memory sharing), while using a NUMA node (with `-numa node,memdev=mem`) works just fine.
+Steps to reproduce:
+1. Install `virtiofsd`
+2. Run `/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir=$HOME --cache always` as a regular user (or with another shared directory, it doesn't matter)
+3. Run QEMU with the aforementioned command line as a regular user
+4. Wait a bit for the OS to load and `virtiofsd` should error out
+Additional information:
+`virtiofsd` logs:
+```
+[2024-05-09T19:49:15Z WARN  virtiofsd::sandbox] Couldn't set the process uid as root: -1
+[2024-05-09T19:49:15Z WARN  virtiofsd::sandbox] Couldn't set the process gid as root: -1
+[2024-05-09T19:49:15Z INFO  virtiofsd] Waiting for vhost-user socket connection...
+[2024-05-09T19:49:16Z INFO  virtiofsd] Client connected, servicing requests
+[2024-05-09T19:49:22Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(ReqHandlerError(Custom { kind: Other, error: MissingMemoryMapping }))
+```
+
+QEMU logs (after virtiofsd errors out and exits):
+```
+qemu: Failed to read msg header. Read -1 instead of 12. Original request 0.
+qemu: Failed to write msg. Wrote -1 instead of 20.
+qemu: vhost VQ 1 ring restore failed: -22: Invalid argument (22)
+qemu: Failed to set msg fds.
+qemu: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
+qemu: Error starting vhost: 5
+qemu: Failed to set msg fds.
+qemu: vhost_set_vring_call failed 22
+qemu: Failed to set msg fds.
+qemu: vhost_set_vring_call failed 22
+qemu: Unexpected end-of-file before all data were read
+```
diff --git a/results/classifier/105/socket/2444 b/results/classifier/105/socket/2444
new file mode 100644
index 00000000..9a409aa2
--- /dev/null
+++ b/results/classifier/105/socket/2444
@@ -0,0 +1,14 @@
+socket: 0.870
+instruction: 0.822
+device: 0.720
+network: 0.682
+graphic: 0.509
+other: 0.478
+semantic: 0.443
+vnc: 0.428
+mistranslation: 0.386
+boot: 0.344
+assembly: 0.248
+KVM: 0.127
+
+Use of vulnerable function 'strcpy' at can_socketcan.c:213. This function is unsafe.
diff --git a/results/classifier/105/socket/2584 b/results/classifier/105/socket/2584
new file mode 100644
index 00000000..d29d3e48
--- /dev/null
+++ b/results/classifier/105/socket/2584
@@ -0,0 +1,29 @@
+socket: 0.966
+graphic: 0.816
+network: 0.728
+device: 0.684
+semantic: 0.486
+instruction: 0.450
+boot: 0.335
+other: 0.321
+vnc: 0.313
+mistranslation: 0.223
+KVM: 0.185
+assembly: 0.054
+
+nbd URI wrong export name (regression in qemu 9.1)
+Description of problem:
+qemu with an nbd URI seems to pass the wrong export name to the server, if the exportname is `.`.  This seems
+to be a regression in qemu 9.1, because it didn't happen in 9.0.
+Steps to reproduce:
+```
+$ nbdkit -fv -U - null --run 'qemu-img info "nbd+unix:///.?socket=$unixsocket"'
+...
+nbdkit: null[1]: debug: null: open readonly=0 exportname="" tls=0
+```
+
+In qemu 9.0 this was correct:
+
+```
+nbdkit: null[1]: debug: null: open readonly=0 exportname="." tls=0
+```
diff --git a/results/classifier/105/socket/2624 b/results/classifier/105/socket/2624
new file mode 100644
index 00000000..6f0a479b
--- /dev/null
+++ b/results/classifier/105/socket/2624
@@ -0,0 +1,52 @@
+socket: 0.988
+device: 0.988
+instruction: 0.955
+graphic: 0.896
+boot: 0.842
+other: 0.776
+network: 0.774
+semantic: 0.700
+vnc: 0.649
+mistranslation: 0.539
+assembly: 0.394
+KVM: 0.378
+
+qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed
+Description of problem:
+I'm using QEMU (compile from the latest source code) to simulate a tpm2 device with the above command, it just returns an error message:
+```
+qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed
+```
+swtpm start command:
+```
+TPMSOCK=/tmp/swtpm-sock$$                                                                                                                                                  
+swtpm socket --tpm2 -t -d --tpmstate dir=$PWD/tpm --ctrl type=unixio,path=$TPMSOCK --log level=20                                                                          
+```
+swtpm version:
+```
+TPM emulator version 0.7.3, Copyright (c) 2014-2021 IBM Corp.
+```
+Also tried the latest swtpm, encountered the same error.
+
+swtpm log (0.7.3):
+```
+swtpm: Data client disconnected
+swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied
+swtpm: Error: Could not initialize libtpms.
+swtpm: Error: Could not initialize the TPM
+swtpm: Data client disconnected
+```
+
+swtpm log (0.10.0):
+```
+swtpm: SWTPM_NVRAM_StoreData: Error (fatal) opening tpm/TMP2-00.permall for write failed, Permission denied
+swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied
+swtpm: Error: Could not initialize the TPM
+swtpm: Data client disconnected
+```
+
+Any clues about this error? Best regrads.
+Steps to reproduce:
+Refer to [Description of problem](#description-of-problem)
+Additional information:
+
diff --git a/results/classifier/105/socket/2678 b/results/classifier/105/socket/2678
new file mode 100644
index 00000000..16993538
--- /dev/null
+++ b/results/classifier/105/socket/2678
@@ -0,0 +1,22 @@
+socket: 0.758
+network: 0.732
+device: 0.640
+graphic: 0.573
+boot: 0.374
+KVM: 0.246
+vnc: 0.211
+instruction: 0.202
+semantic: 0.121
+mistranslation: 0.055
+assembly: 0.054
+other: 0.017
+
+virsh blockcommit failed, however the snapshot was merged into base successfully.
+Description of problem:
+
+Steps to reproduce:
+1.
+2.
+3.
+Additional information:
+
diff --git a/results/classifier/105/socket/284 b/results/classifier/105/socket/284
new file mode 100644
index 00000000..b4851c2a
--- /dev/null
+++ b/results/classifier/105/socket/284
@@ -0,0 +1,14 @@
+socket: 0.916
+instruction: 0.594
+network: 0.451
+graphic: 0.336
+semantic: 0.155
+device: 0.151
+mistranslation: 0.140
+vnc: 0.126
+boot: 0.055
+other: 0.018
+assembly: 0.018
+KVM: 0.014
+
+Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
diff --git a/results/classifier/105/socket/2867 b/results/classifier/105/socket/2867
new file mode 100644
index 00000000..a87768a2
--- /dev/null
+++ b/results/classifier/105/socket/2867
@@ -0,0 +1,26 @@
+socket: 0.901
+device: 0.891
+instruction: 0.887
+graphic: 0.879
+vnc: 0.777
+semantic: 0.757
+network: 0.754
+mistranslation: 0.639
+other: 0.610
+boot: 0.534
+KVM: 0.336
+assembly: 0.313
+
+qemu:block / io-qcow2-161 fails non-deterministically
+Description of problem:
+The test suite failed non-deterministically with failure:
+```
+729/838 qemu:block / io-qcow2-161                                                 ERROR            2.08s   exit status 1
+```
+Steps to reproduce:
+1. guix time-machine --commit=d706c1b -- build qemu
+2. or git clone,  build and run `make check -j32 V=1`
+Additional information:
+[qemu-9.1.3-io-qcow2-041-failure-build-log.txt](/uploads/077f61d9dd1a26bcd351c0995009131c/qemu-9.1.3-io-qcow2-041-failure-build-log.txt)
+
+[testlog.txt](/uploads/0b0244a337f2175bdba9e258c778481d/testlog.txt)
diff --git a/results/classifier/105/socket/2876 b/results/classifier/105/socket/2876
new file mode 100644
index 00000000..c93288cf
--- /dev/null
+++ b/results/classifier/105/socket/2876
@@ -0,0 +1,27 @@
+socket: 0.951
+graphic: 0.932
+device: 0.929
+instruction: 0.926
+network: 0.895
+vnc: 0.843
+boot: 0.661
+KVM: 0.596
+mistranslation: 0.538
+semantic: 0.464
+other: 0.219
+assembly: 0.201
+
+IPv6 support for hostfwd + guestfwd
+Description of problem:
+When using hostfwd, only IPv4 connections are forwarded.
+Steps to reproduce:
+1. Start vm with the aforementioned command using a system image that comes with a socket listening on both IPv4 and IPv6. (I used Arch Linux Box which comes with `sshd` enabled by default).
+2. Connect to the forwarded socket:
+  - IPv4 succeeds:
+    - `ssh -oPasswordAuthentication=yes arch@127.0.0.1 -p 52022`
+    - `nc -zv 127.0.0.1 52022`
+  - IPv6 does not:
+    - `ssh -oPasswordAuthentication=yes arch@::1 -p 52022`
+    - `nc -zv ::1 52022`
+Additional information:
+#
diff --git a/results/classifier/105/socket/2925 b/results/classifier/105/socket/2925
new file mode 100644
index 00000000..10a91bd7
--- /dev/null
+++ b/results/classifier/105/socket/2925
@@ -0,0 +1,38 @@
+socket: 0.860
+device: 0.796
+other: 0.667
+graphic: 0.612
+network: 0.594
+instruction: 0.591
+semantic: 0.573
+KVM: 0.541
+vnc: 0.537
+boot: 0.419
+mistranslation: 0.395
+assembly: 0.152
+
+Cannot exec certain QMP guest commands using unix socket but Virsh can
+Description of problem:
+There are two channels configured to communicate the guest. 
+ - a) qemu.guest_agent.0
+ - b) unix socket: -qmp unix:/tmp/qmp_win7-101.sock,server,nowait
+
+
+**For unix socket connection, certain commands like ```guest-info``` and other guest functions are missing.** However, invoking guest-xx functions successfully in Virsh (through qemu.guest_agent.0).
+Steps to reproduce:
+```
+$sudo socat unix-connect:/tmp/qmp_win7-101.sock readline
+{"QMP": {"version": {"qemu": {"micro": 0, "minor": 2, "major": 4}, "package": "qemu-kvm-4.2.0-59.module_el8.5.0+1063+c9b9feff.1"}, "capabilities": ["oob"]}}
+
+{"execute":"qmp_capabilities"}
+{"return": {}}
+
+{"execute": "guest-info"}
+{"error": {"class": "CommandNotFound", "desc": "The command guest-info has not been found"}}
+```
+
+I checked ```/etc/sysconfig/qemu-ga``` and unmarked blacklist functions, but it did not solve this problem.
+```
+# original contents of qemu-ga
+#BLACKLIST_RPC=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status
+```
diff --git a/results/classifier/105/socket/323 b/results/classifier/105/socket/323
new file mode 100644
index 00000000..9e76dc00
--- /dev/null
+++ b/results/classifier/105/socket/323
@@ -0,0 +1,14 @@
+socket: 0.873
+network: 0.864
+device: 0.850
+instruction: 0.763
+graphic: 0.494
+boot: 0.434
+vnc: 0.416
+semantic: 0.384
+mistranslation: 0.261
+assembly: 0.179
+other: 0.131
+KVM: 0.030
+
+qemu 5.2.0: Add reconnect option support for netdev socket
diff --git a/results/classifier/105/socket/347 b/results/classifier/105/socket/347
new file mode 100644
index 00000000..4cccc9be
--- /dev/null
+++ b/results/classifier/105/socket/347
@@ -0,0 +1,14 @@
+instruction: 0.965
+socket: 0.961
+network: 0.960
+device: 0.798
+vnc: 0.600
+mistranslation: 0.572
+boot: 0.549
+other: 0.524
+graphic: 0.487
+semantic: 0.450
+KVM: 0.343
+assembly: 0.054
+
+Forward host UNIX socket to guest TCP port
diff --git a/results/classifier/105/socket/588735 b/results/classifier/105/socket/588735
new file mode 100644
index 00000000..56f0fb36
--- /dev/null
+++ b/results/classifier/105/socket/588735
@@ -0,0 +1,51 @@
+socket: 0.856
+other: 0.820
+KVM: 0.772
+mistranslation: 0.757
+instruction: 0.720
+semantic: 0.718
+network: 0.591
+graphic: 0.589
+device: 0.575
+vnc: 0.264
+assembly: 0.187
+boot: 0.185
+
+Quit command not working
+
+Qemu strace
+
+
+
+rt_sigreturn(0x1b)                      = 56
+clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f6fddecbad0) = ? ERESTARTNOINTR (To be restarted)
+--- SIGPROF (Profiling timer expired) @ 0 (0) ---
+rt_sigreturn(0x1b)                      = 56
+
+
+started with :
+
+[root@virtual-test ~]# /root/qemu-test/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -net tap,vlan=0,name=tap.0 -chardev socket,id=serial0,host=0.0.0.0,port=$CONSOLEPORT,telnet,server,nowait -serial chardev:serial0 -hda hda -hdb hdb -hdc hdc -hdd hdd -fda fd0 -fdb fd1 -chardev socket,id=monitor,host=0.0.0.0,port=$MONITORPORT,telnet,server,nowait -monitor chardev:monitor -net nic,macaddr=$MAC,vlan=0,model=e1000,name=e1000.0 -M pc -m 4096
+
+when removing -m 4096, the quit command works.
+
+but I think its a combination of different args that causes the problem.
+
+I tried this exact syntax and could not reproduce.  What version of qemu are you using?
+
+how much memory do you have in the host?
+
+The host now has 8GB of memory, problem remains.
+
+
+Try
+
+ ./configure --target-list=x86_64-softmmu --enable-profiler --enable-gprof --enable-io-thread --enable-debug-tcg --enable-debug
+
+
+Without these options it magically works :)
+
+
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/761471 b/results/classifier/105/socket/761471
new file mode 100644
index 00000000..e0da3f09
--- /dev/null
+++ b/results/classifier/105/socket/761471
@@ -0,0 +1,28 @@
+socket: 0.872
+network: 0.805
+device: 0.660
+vnc: 0.601
+semantic: 0.559
+graphic: 0.553
+other: 0.409
+instruction: 0.377
+mistranslation: 0.293
+boot: 0.269
+assembly: 0.171
+KVM: 0.097
+
+Multicast VPN TTL hardcoded at 1
+
+The multicast VPN opens sockets with the default TTL of 1 and there doesn't appear to be an option anywhere that will allow you to increase that.
+
+This limits the usability of the VPN to the local network where the host server lives.
+
+Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
+
+
+This is for an ancient version of QEMU and no doubt a network approach that is long since obsolete. 
+
+Probably best to close it as an edge case. If I run into it again I'll re-raise. 
+
+Ok, thanks, so I'll close this now.
+
diff --git a/results/classifier/105/socket/778032 b/results/classifier/105/socket/778032
new file mode 100644
index 00000000..f0a262c7
--- /dev/null
+++ b/results/classifier/105/socket/778032
@@ -0,0 +1,108 @@
+instruction: 0.958
+socket: 0.943
+semantic: 0.941
+assembly: 0.940
+other: 0.928
+device: 0.925
+network: 0.920
+graphic: 0.920
+boot: 0.913
+vnc: 0.892
+KVM: 0.885
+mistranslation: 0.791
+
+qemu spinning on serial port writes
+
+As originally found at http://<email address hidden>/msg08745.html from 3 years ago! 
+
+Basically qemu seizes up in the event that the file descriptor for its emulated serial port has a full buffer, i.e. write() returns EAGAIN.  For me, this happened when the serial port was being directed through a UNIX socket, with a default-sized 4KB buffer.  Just the normal output from a Linux kernel boot caused it to seize up, and stop the main emulation / select loop.
+
+My suggestion is to remove the detection of EAGAIN in qemu-char.c:521, so that if the buffer is full, KVM discards the byte(s) it was trying to write.  This is a surely better outcome than the process spinning forever.
+
+I will submit a separate patch to control the buffer sizes when creating UNIX sockets, which will help allow slow-reading processes to tune things so that they don't miss any output.
+
+Additionally, in the context of a hosted environment, if the -serial option is used, this could be a small security issue. An untrusted user of a guest system, knowing their serial output is going via a small buffer, could spew output to their /dev/ttyS0 at a rate fast enough to trigger this bug and eat a CPU core on the host.
+
+To quote David S. Ahern's original bug report (mine was the same, only with the latest version from git, so line numbers may have changed - my suggested fix above is accurate though):
+
+I am trying to redirect a guest's boot output through the host's serial
+port.  Shortly after launching qemu, the main thread is spinning on:
+
+write(9, "0", 1)   = -1 EAGAIN (Resource temporarily unavailable)
+
+fd 9 is the serial port, ttyS0.
+
+
+The backtrace for the thread is:
+
+#0  0x00002ac3433f8c0b in write () from /lib64/libpthread.so.0
+#1  0x0000000000475df9 in send_all (fd=9, buf=<value optimized out>,
+len1=1) at qemu-char.c:477
+#2  0x000000000043a102 in serial_xmit (opaque=<value optimized out>) at
+/root/kvm-81/qemu/hw/serial.c:311
+#3  0x000000000043a591 in serial_ioport_write (opaque=0x14971790,
+addr=<value optimized out>, val=48)
+    at /root/kvm-81/qemu/hw/serial.c:366
+#4  0x00000000410eeedc in ?? ()
+#5  0x0000000000129000 in ?? ()
+#6  0x0000000014821fa0 in ?? ()
+#7  0x0000000000000007 in ?? ()
+#8  0x00000000004a54c5 in tlb_set_page_exec (env=0x10ab4,
+vaddr=46912496956816, paddr=1, prot=-1, mmu_idx=0, is_softmmu=1)
+    at /root/kvm-81/qemu/exec.c:388
+#9  0x0000000000512f3b in tlb_fill (addr=345446292, is_write=1,
+mmu_idx=-1, retaddr=0x0)
+    at /root/kvm-81/qemu/target-i386/op_helper.c:4690
+#10 0x00000000004a6bd2 in __ldb_cmmu (addr=9, mmu_idx=0) at
+/root/kvm-81/qemu/softmmu_template.h:135
+#11 0x00000000004a879b in cpu_x86_exec (env1=<value optimized out>) at
+/root/kvm-81/qemu/cpu-exec.c:628
+#12 0x000000000040ba29 in main (argc=12, argv=0x7fff67f7a398) at
+/root/kvm-81/qemu/vl.c:3816
+
+send_all() invokes unix_write() which by design is not breaking out on
+EAGAIN.
+
+The following command is enough to show the problem:
+
+qemu-system-x86_64 -m 256 -smp 1 -no-kvm \
+    -drivefile=/dev/cciss/c0d0,if=scsi,cache=off,boot=on \
+    -vnc :1 -serial /dev/ttyS0
+
+
+The guest is running RHEL3 with the parameter 'console=ttyS0' added to
+grub.conf; the problem appears to be with qemu, so I would expect it to
+show with any linux guest. This particular host is running RHEL5.2 with
+kvm-81, but I have also seen the problem with Fedora-9 as the host OS.
+
+Yes, the serial port of the server is connected to another system via a
+null modem. If I change the serial argument to '-serial udp::4555' and
+use  'nc -u -l  localhost 4555  > /dev/ttyS0' I see the guest's boot
+output show up on the second system as expected. I'd prefer to be able
+to use the serial port connection directly without nc as a proxy.
+Suggestions?
+
+I have a similar problem, and the problem goes away if I remove the "-serial pty" device from my command line:
+
+/home/mrhines/qemu/x86_64-softmmu/qemu-system-x86_64 /kvm_repo/cb/vmbase -serial pty
+
+Such a simple command line, but QEMU seizes up and slows to a crawl and the host CPU is spinning at 100%
+
+Which version of QEMU have you been using here? Can you still reproduce this problem with the latest version of QEMU (currently version 2.9)?
+
+I'm confident this has been solved a while ago. When this bug was reported, the code was indeed broken wrt EAGAIN handling. 
+
+The chardev code has long since been re-written though, and the send_all method replaced by io_channel_send_all() which will handle EAGAIN by returning instead of spinning in a loop.
+
+Specifically this commit changed the code to stop spinning in send_all() on EAGAIN
+
+commit 23673ca740e0eda66901ca801a5a901df378b063
+Author: Anthony Liguori <email address hidden>
+Date:   Tue Mar 5 23:21:23 2013 +0530
+
+    qemu-char: add watch support
+    
+    This allows a front-end to request for a callback when the backend
+    is writable again.
+
+
diff --git a/results/classifier/105/socket/796202 b/results/classifier/105/socket/796202
new file mode 100644
index 00000000..ca94772e
--- /dev/null
+++ b/results/classifier/105/socket/796202
@@ -0,0 +1,83 @@
+socket: 0.871
+instruction: 0.871
+graphic: 0.836
+other: 0.827
+boot: 0.813
+network: 0.805
+device: 0.803
+semantic: 0.794
+vnc: 0.793
+mistranslation: 0.694
+assembly: 0.558
+KVM: 0.478
+
+Doing a 64 bit load from a 32 bit local APIC register is allowed
+
+Doing
+
+u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;
+
+and later in an interrupt handler
+
+movq (lapic_idregister), %rcx
+movq (%rcx), %rcx
+
+in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots).
+On real hardware only
+
+movl (%rcx), %ecx
+
+works (also in qemu).
+
+Commandline:
+qemu-system-x86_64 \
+		-kernel $LINUXDIR/arch/x86_64/boot/bzImage \
+		-hda $BUILDROOTDIR/output/images/rootfs.ext2 \
+		-append "root=/dev/sda rw rootfstype=ext2 maxcpus=4" \
+		-cpu phenom \
+		-smp 4 \
+		-gdb tcp::1234 \
+		-net nic -net user
+
+Guest:
+Vanilla Linux Kernel 2.6.37.6 64-bit with buildroot
+
+Mikael Pettersson from the linux kernel mailinglist told me it's an accepts-invalid bug in qemu.
+
+On Sun, Jun 12, 2011 at 4:03 PM, Robert Uhl <email address hidden> wrote:
+> Public bug reported:
+>
+> Doing
+>
+> u64 lapic_idregister = (u64) fix_to_virt(FIX_APIC_BASE) + 0x20;
+>
+> and later in an interrupt handler
+>
+> movq (lapic_idregister), %rcx
+> movq (%rcx), %rcx
+>
+> in a linux kernel module works in qemu 0.13.91 but not on real hardware (it simply reboots).
+> On real hardware only
+>
+> movl (%rcx), %ecx
+>
+> works (also in qemu).
+
+Thank you for the report. Currently QEMU devices only provide access
+methods up to 32 bits, a 64 bit access is emulated with two 32 bit
+accesses. So it is not possible to handle a 32 bit access differently
+from a 64 bit one for now.
+
+So far this hasn't been considered to be a problem for x86, though it
+is clearly not correct for Sparc and Alpha. This report shows that it
+is necessary to add 64 bit access methods (or otherwise handle 64 bit
+accesses more realistically) since x86 is also affected.
+
+Adding the 64 bit method would be a major refactoring though and there
+are other designs possible.
+
+
+Triaging old bug tickets ... can you somehow still reproduce this problem with the latest version of QEMU (currently v2.9), or could we close this ticket nowadays?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+
diff --git a/results/classifier/105/socket/833 b/results/classifier/105/socket/833
new file mode 100644
index 00000000..d48f0ba1
--- /dev/null
+++ b/results/classifier/105/socket/833
@@ -0,0 +1,55 @@
+socket: 0.983
+network: 0.942
+instruction: 0.931
+device: 0.914
+graphic: 0.863
+other: 0.813
+vnc: 0.742
+mistranslation: 0.721
+boot: 0.674
+assembly: 0.650
+semantic: 0.594
+KVM: 0.473
+
+linux-user: sendmsg fails to send messages without iov
+Description of problem:
+When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux.
+
+A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526
+
+A message without data but only ancillary data is used to set the IV.
+Steps to reproduce:
+See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`).
+
+(Test case is to be considered GPL, as I've copied bits from `ell`)
+
+Native:
+```
+$ strace -esendmsg ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+
+Qemu (observe missing sendmsg call):
+```
+$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out 
+sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16
++++ exited with 0 +++
+```
+
+For a practical reproducer:
+
+1. Compile and run `ell`'s `test-cipher` test case:
+
+```
+$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher 
+TEST: unsupported
+TEST: aes
+TEST: aes_ctr
+test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed.
+Aborted (core dumped)
+```
+
+A strace will look similar.
diff --git a/results/classifier/105/socket/872 b/results/classifier/105/socket/872
new file mode 100644
index 00000000..c9b59202
--- /dev/null
+++ b/results/classifier/105/socket/872
@@ -0,0 +1,14 @@
+socket: 0.913
+instruction: 0.824
+network: 0.728
+device: 0.618
+boot: 0.373
+graphic: 0.269
+semantic: 0.248
+vnc: 0.196
+KVM: 0.113
+other: 0.108
+mistranslation: 0.099
+assembly: 0.007
+
+linux-user getsockopt(fd, SOL_SOCKET, SO_ERROR) returns host errno to target
diff --git a/results/classifier/105/socket/939995 b/results/classifier/105/socket/939995
new file mode 100644
index 00000000..3c25c9a6
--- /dev/null
+++ b/results/classifier/105/socket/939995
@@ -0,0 +1,114 @@
+socket: 0.977
+semantic: 0.969
+other: 0.968
+assembly: 0.967
+instruction: 0.964
+vnc: 0.964
+graphic: 0.952
+boot: 0.952
+device: 0.935
+network: 0.933
+KVM: 0.932
+mistranslation: 0.926
+
+v1.0-1172-g235fe3b crashes (opts=0x0)
+
+C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios
+GNU gdb (GDB) 7.3
+Copyright (C) 2011 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "mingw32".
+For bug reporting instructions, please see:
+<http://www.gnu.org/software/gdb/bugs/>...
+Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
+done.
+(gdb) r
+Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios
+[New Thread 4724.0x1224]
+
+Program received signal SIGSEGV, Segmentation fault.
+0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
+    at qemu-option.c:545
+545         QemuOpt *opt = qemu_opt_find(opts, name);
+(gdb) bt
+#0  0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
+    at qemu-option.c:545
+#1  0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0)
+    at C:/msys/home/User/qemu/vl.c:3250
+#2  0x004c906a in SDL_main (argc=3, argv=0x3e5200)
+    at C:/msys/home/User/qemu/vl.c:102
+#3  0x0061dcf4 in console_main ()
+#4  0x0061ddb4 in WinMain@16 ()
+#5  0x006329fb in main ()
+(gdb)
+
+qemu_opt_find() doesn't check if opts is NULL or not before use.
+The patch fixes that issue.
+
+This is fixed by http://patchwork.ozlabs.org/patch/142548/ (which hasn't been applied yet but hopefully will be soon).
+
+
+
+2012/2/24 Peter Maydell <email address hidden>:
+> This is fixed by http://patchwork.ozlabs.org/patch/142548/ (which hasn't
+> been applied yet but hopefully will be soon).
+>
+
+It looks like a workaround to me as if you feed NULL to
+qemu_opt_find() it will still crashing.
+
+> --
+> You received this bug notification because you are subscribed to the bug
+> report.
+> https://bugs.launchpad.net/bugs/939995
+>
+> Title:
+>  v1.0-1172-g235fe3b crashes (opts=0x0)
+>
+> Status in QEMU:
+>  New
+>
+> Bug description:
+>  C:\msys\home\User\qemu\i386-softmmu>gdb --args qemu-system-i386.exe -L ..\pc-bios
+>  GNU gdb (GDB) 7.3
+>  Copyright (C) 2011 Free Software Foundation, Inc.
+>  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+>  This is free software: you are free to change and redistribute it.
+>  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+>  and "show warranty" for details.
+>  This GDB was configured as "mingw32".
+>  For bug reporting instructions, please see:
+>  <http://www.gnu.org/software/gdb/bugs/>...
+>  Reading symbols from C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe...
+>  done.
+>  (gdb) r
+>  Starting program: C:\msys\home\User\qemu\i386-softmmu/qemu-system-i386.exe -L ..\\pc-bios
+>  [New Thread 4724.0x1224]
+>
+>  Program received signal SIGSEGV, Segmentation fault.
+>  0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
+>      at qemu-option.c:545
+>  545         QemuOpt *opt = qemu_opt_find(opts, name);
+>  (gdb) bt
+>  #0  0x004eeda6 in qemu_opt_get (opts=0x0, name=0x68a7c3 "kernel")
+>      at qemu-option.c:545
+>  #1  0x004c7166 in qemu_main (argc=3, argv=0x3e5200, envp=0x0)
+>      at C:/msys/home/User/qemu/vl.c:3250
+>  #2  0x004c906a in SDL_main (argc=3, argv=0x3e5200)
+>      at C:/msys/home/User/qemu/vl.c:102
+>  #3  0x0061dcf4 in console_main ()
+>  #4  0x0061ddb4 in WinMain@16 ()
+>  #5  0x006329fb in main ()
+>  (gdb)
+>
+> To manage notifications about this bug go to:
+> https://bugs.launchpad.net/qemu/+bug/939995/+subscriptions
+
+
+Peter's fix had been included here:
+http://git.qemu.org/?p=qemu.git;a=commitdiff;h=967c0da73a7b0da186baba6
+... so I think we can close this bug ticket now.
+
-- 
cgit 1.4.1