From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/118/socket/1020484 | 52 -----------------------
 results/classifier/118/socket/1055    | 46 --------------------
 results/classifier/118/socket/1064631 | 48 ---------------------
 results/classifier/118/socket/1075272 | 47 ---------------------
 results/classifier/118/socket/1075339 | 44 -------------------
 results/classifier/118/socket/1090    | 45 --------------------
 results/classifier/118/socket/1264    | 31 --------------
 results/classifier/118/socket/1542965 | 40 ------------------
 results/classifier/118/socket/1567    | 64 ----------------------------
 results/classifier/118/socket/1585432 | 62 ---------------------------
 results/classifier/118/socket/1612908 | 42 -------------------
 results/classifier/118/socket/1663079 | 57 -------------------------
 results/classifier/118/socket/1721220 | 66 -----------------------------
 results/classifier/118/socket/1721222 | 49 ----------------------
 results/classifier/118/socket/1721224 | 56 -------------------------
 results/classifier/118/socket/1744009 | 58 -------------------------
 results/classifier/118/socket/1754605 | 52 -----------------------
 results/classifier/118/socket/1756    | 73 --------------------------------
 results/classifier/118/socket/1781280 | 44 -------------------
 results/classifier/118/socket/1796754 | 68 ------------------------------
 results/classifier/118/socket/1829945 | 79 -----------------------------------
 results/classifier/118/socket/1837    | 65 ----------------------------
 results/classifier/118/socket/1837651 | 51 ----------------------
 results/classifier/118/socket/1843590 | 66 -----------------------------
 results/classifier/118/socket/1861884 | 67 -----------------------------
 results/classifier/118/socket/1867601 | 51 ----------------------
 results/classifier/118/socket/1886    | 47 ---------------------
 results/classifier/118/socket/1904    | 46 --------------------
 results/classifier/118/socket/1907926 | 68 ------------------------------
 results/classifier/118/socket/1923692 | 46 --------------------
 results/classifier/118/socket/1925449 | 76 ---------------------------------
 results/classifier/118/socket/1949    | 42 -------------------
 results/classifier/118/socket/2254    | 31 --------------
 results/classifier/118/socket/2292    | 49 ----------------------
 results/classifier/118/socket/2341    | 62 ---------------------------
 results/classifier/118/socket/2444    | 31 --------------
 results/classifier/118/socket/2584    | 46 --------------------
 results/classifier/118/socket/2624    | 69 ------------------------------
 results/classifier/118/socket/284     | 31 --------------
 results/classifier/118/socket/2867    | 43 -------------------
 results/classifier/118/socket/2876    | 44 -------------------
 results/classifier/118/socket/2925    | 55 ------------------------
 results/classifier/118/socket/347     | 31 --------------
 results/classifier/118/socket/761471  | 45 --------------------
 results/classifier/118/socket/833     | 72 -------------------------------
 45 files changed, 2357 deletions(-)
 delete mode 100644 results/classifier/118/socket/1020484
 delete mode 100644 results/classifier/118/socket/1055
 delete mode 100644 results/classifier/118/socket/1064631
 delete mode 100644 results/classifier/118/socket/1075272
 delete mode 100644 results/classifier/118/socket/1075339
 delete mode 100644 results/classifier/118/socket/1090
 delete mode 100644 results/classifier/118/socket/1264
 delete mode 100644 results/classifier/118/socket/1542965
 delete mode 100644 results/classifier/118/socket/1567
 delete mode 100644 results/classifier/118/socket/1585432
 delete mode 100644 results/classifier/118/socket/1612908
 delete mode 100644 results/classifier/118/socket/1663079
 delete mode 100644 results/classifier/118/socket/1721220
 delete mode 100644 results/classifier/118/socket/1721222
 delete mode 100644 results/classifier/118/socket/1721224
 delete mode 100644 results/classifier/118/socket/1744009
 delete mode 100644 results/classifier/118/socket/1754605
 delete mode 100644 results/classifier/118/socket/1756
 delete mode 100644 results/classifier/118/socket/1781280
 delete mode 100644 results/classifier/118/socket/1796754
 delete mode 100644 results/classifier/118/socket/1829945
 delete mode 100644 results/classifier/118/socket/1837
 delete mode 100644 results/classifier/118/socket/1837651
 delete mode 100644 results/classifier/118/socket/1843590
 delete mode 100644 results/classifier/118/socket/1861884
 delete mode 100644 results/classifier/118/socket/1867601
 delete mode 100644 results/classifier/118/socket/1886
 delete mode 100644 results/classifier/118/socket/1904
 delete mode 100644 results/classifier/118/socket/1907926
 delete mode 100644 results/classifier/118/socket/1923692
 delete mode 100644 results/classifier/118/socket/1925449
 delete mode 100644 results/classifier/118/socket/1949
 delete mode 100644 results/classifier/118/socket/2254
 delete mode 100644 results/classifier/118/socket/2292
 delete mode 100644 results/classifier/118/socket/2341
 delete mode 100644 results/classifier/118/socket/2444
 delete mode 100644 results/classifier/118/socket/2584
 delete mode 100644 results/classifier/118/socket/2624
 delete mode 100644 results/classifier/118/socket/284
 delete mode 100644 results/classifier/118/socket/2867
 delete mode 100644 results/classifier/118/socket/2876
 delete mode 100644 results/classifier/118/socket/2925
 delete mode 100644 results/classifier/118/socket/347
 delete mode 100644 results/classifier/118/socket/761471
 delete mode 100644 results/classifier/118/socket/833

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

diff --git a/results/classifier/118/socket/1020484 b/results/classifier/118/socket/1020484
deleted file mode 100644
index 6f461dcf..00000000
--- a/results/classifier/118/socket/1020484
+++ /dev/null
@@ -1,52 +0,0 @@
-socket: 0.852
-network: 0.731
-semantic: 0.613
-device: 0.613
-arm: 0.573
-ppc: 0.555
-graphic: 0.485
-register: 0.477
-permissions: 0.427
-risc-v: 0.406
-i386: 0.400
-mistranslation: 0.394
-boot: 0.372
-PID: 0.359
-architecture: 0.336
-TCG: 0.324
-x86: 0.298
-kernel: 0.287
-vnc: 0.284
-performance: 0.257
-files: 0.248
-peripherals: 0.192
-hypervisor: 0.166
-virtual: 0.164
-user-level: 0.127
-VMM: 0.124
-KVM: 0.095
-debug: 0.064
-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/118/socket/1055 b/results/classifier/118/socket/1055
deleted file mode 100644
index 3194ff4a..00000000
--- a/results/classifier/118/socket/1055
+++ /dev/null
@@ -1,46 +0,0 @@
-socket: 0.982
-PID: 0.882
-device: 0.838
-performance: 0.828
-network: 0.764
-architecture: 0.761
-graphic: 0.745
-ppc: 0.662
-kernel: 0.644
-register: 0.548
-debug: 0.546
-hypervisor: 0.493
-peripherals: 0.491
-permissions: 0.446
-semantic: 0.438
-i386: 0.438
-vnc: 0.421
-assembly: 0.405
-arm: 0.403
-boot: 0.400
-x86: 0.383
-risc-v: 0.369
-KVM: 0.348
-files: 0.304
-VMM: 0.289
-TCG: 0.278
-mistranslation: 0.250
-user-level: 0.201
-virtual: 0.128
-
-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/118/socket/1064631 b/results/classifier/118/socket/1064631
deleted file mode 100644
index 30bf63ad..00000000
--- a/results/classifier/118/socket/1064631
+++ /dev/null
@@ -1,48 +0,0 @@
-socket: 0.956
-network: 0.947
-virtual: 0.878
-device: 0.795
-graphic: 0.635
-permissions: 0.582
-semantic: 0.458
-vnc: 0.389
-ppc: 0.341
-TCG: 0.339
-architecture: 0.335
-arm: 0.335
-PID: 0.328
-mistranslation: 0.315
-i386: 0.313
-boot: 0.301
-x86: 0.301
-register: 0.298
-performance: 0.272
-risc-v: 0.270
-KVM: 0.268
-hypervisor: 0.260
-files: 0.255
-peripherals: 0.250
-user-level: 0.229
-VMM: 0.215
-kernel: 0.194
-debug: 0.155
-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/118/socket/1075272 b/results/classifier/118/socket/1075272
deleted file mode 100644
index aac03e45..00000000
--- a/results/classifier/118/socket/1075272
+++ /dev/null
@@ -1,47 +0,0 @@
-socket: 0.921
-architecture: 0.900
-network: 0.791
-device: 0.791
-kernel: 0.783
-user-level: 0.735
-performance: 0.633
-ppc: 0.555
-graphic: 0.546
-arm: 0.539
-register: 0.510
-mistranslation: 0.496
-risc-v: 0.455
-files: 0.439
-vnc: 0.435
-VMM: 0.403
-permissions: 0.403
-boot: 0.360
-peripherals: 0.304
-PID: 0.292
-KVM: 0.290
-TCG: 0.257
-debug: 0.255
-i386: 0.242
-hypervisor: 0.198
-x86: 0.194
-virtual: 0.148
-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/118/socket/1075339 b/results/classifier/118/socket/1075339
deleted file mode 100644
index c50e154d..00000000
--- a/results/classifier/118/socket/1075339
+++ /dev/null
@@ -1,44 +0,0 @@
-socket: 0.815
-mistranslation: 0.768
-semantic: 0.637
-user-level: 0.579
-device: 0.551
-kernel: 0.535
-network: 0.424
-boot: 0.362
-graphic: 0.355
-architecture: 0.337
-performance: 0.329
-x86: 0.256
-risc-v: 0.244
-i386: 0.222
-vnc: 0.192
-debug: 0.167
-peripherals: 0.162
-KVM: 0.149
-arm: 0.149
-virtual: 0.142
-ppc: 0.133
-permissions: 0.128
-VMM: 0.111
-TCG: 0.105
-hypervisor: 0.097
-PID: 0.097
-register: 0.073
-assembly: 0.049
-files: 0.047
-
-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/118/socket/1090 b/results/classifier/118/socket/1090
deleted file mode 100644
index c4448837..00000000
--- a/results/classifier/118/socket/1090
+++ /dev/null
@@ -1,45 +0,0 @@
-socket: 0.913
-x86: 0.876
-device: 0.830
-graphic: 0.742
-peripherals: 0.659
-network: 0.565
-PID: 0.471
-debug: 0.436
-kernel: 0.418
-architecture: 0.400
-semantic: 0.298
-mistranslation: 0.173
-performance: 0.168
-virtual: 0.164
-boot: 0.144
-i386: 0.120
-user-level: 0.111
-KVM: 0.101
-hypervisor: 0.080
-vnc: 0.065
-permissions: 0.050
-register: 0.044
-risc-v: 0.040
-VMM: 0.039
-ppc: 0.028
-TCG: 0.016
-arm: 0.016
-assembly: 0.014
-files: 0.008
-
-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/118/socket/1264 b/results/classifier/118/socket/1264
deleted file mode 100644
index ab5d90d1..00000000
--- a/results/classifier/118/socket/1264
+++ /dev/null
@@ -1,31 +0,0 @@
-socket: 0.953
-device: 0.816
-architecture: 0.796
-network: 0.713
-performance: 0.695
-peripherals: 0.311
-graphic: 0.276
-PID: 0.256
-VMM: 0.247
-semantic: 0.241
-i386: 0.197
-mistranslation: 0.183
-debug: 0.170
-arm: 0.168
-x86: 0.155
-boot: 0.155
-TCG: 0.148
-ppc: 0.136
-virtual: 0.130
-permissions: 0.121
-risc-v: 0.099
-kernel: 0.083
-assembly: 0.080
-KVM: 0.078
-files: 0.059
-vnc: 0.053
-user-level: 0.048
-register: 0.027
-hypervisor: 0.017
-
-socket chardev loses data when remote end closes the connection
diff --git a/results/classifier/118/socket/1542965 b/results/classifier/118/socket/1542965
deleted file mode 100644
index e7968f34..00000000
--- a/results/classifier/118/socket/1542965
+++ /dev/null
@@ -1,40 +0,0 @@
-socket: 0.954
-device: 0.830
-network: 0.805
-mistranslation: 0.708
-architecture: 0.693
-performance: 0.557
-ppc: 0.503
-PID: 0.488
-graphic: 0.481
-vnc: 0.462
-files: 0.455
-kernel: 0.433
-boot: 0.365
-semantic: 0.345
-permissions: 0.315
-peripherals: 0.303
-risc-v: 0.295
-register: 0.275
-debug: 0.247
-x86: 0.234
-arm: 0.234
-i386: 0.182
-user-level: 0.151
-TCG: 0.139
-hypervisor: 0.134
-VMM: 0.120
-virtual: 0.095
-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/118/socket/1567 b/results/classifier/118/socket/1567
deleted file mode 100644
index 502efe4a..00000000
--- a/results/classifier/118/socket/1567
+++ /dev/null
@@ -1,64 +0,0 @@
-socket: 0.870
-kernel: 0.848
-ppc: 0.709
-device: 0.685
-vnc: 0.639
-PID: 0.614
-graphic: 0.573
-architecture: 0.559
-TCG: 0.499
-network: 0.498
-arm: 0.478
-register: 0.442
-VMM: 0.425
-semantic: 0.398
-risc-v: 0.392
-mistranslation: 0.350
-files: 0.335
-debug: 0.330
-permissions: 0.307
-assembly: 0.303
-user-level: 0.256
-performance: 0.196
-i386: 0.194
-boot: 0.188
-KVM: 0.142
-peripherals: 0.117
-x86: 0.113
-hypervisor: 0.083
-virtual: 0.078
-
-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/118/socket/1585432 b/results/classifier/118/socket/1585432
deleted file mode 100644
index 6d3a6de7..00000000
--- a/results/classifier/118/socket/1585432
+++ /dev/null
@@ -1,62 +0,0 @@
-socket: 0.883
-graphic: 0.663
-performance: 0.657
-mistranslation: 0.567
-device: 0.550
-network: 0.545
-debug: 0.523
-ppc: 0.480
-kernel: 0.447
-user-level: 0.431
-semantic: 0.430
-vnc: 0.410
-architecture: 0.405
-PID: 0.366
-VMM: 0.359
-x86: 0.350
-permissions: 0.316
-arm: 0.297
-i386: 0.294
-peripherals: 0.289
-risc-v: 0.289
-hypervisor: 0.256
-files: 0.255
-boot: 0.234
-TCG: 0.199
-register: 0.198
-assembly: 0.136
-KVM: 0.117
-virtual: 0.106
-
-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/118/socket/1612908 b/results/classifier/118/socket/1612908
deleted file mode 100644
index 262d73d0..00000000
--- a/results/classifier/118/socket/1612908
+++ /dev/null
@@ -1,42 +0,0 @@
-socket: 0.854
-network: 0.686
-mistranslation: 0.622
-device: 0.614
-graphic: 0.547
-semantic: 0.481
-user-level: 0.441
-architecture: 0.395
-performance: 0.358
-ppc: 0.285
-x86: 0.241
-hypervisor: 0.197
-kernel: 0.194
-register: 0.194
-peripherals: 0.194
-i386: 0.191
-vnc: 0.187
-debug: 0.177
-boot: 0.149
-VMM: 0.143
-arm: 0.135
-risc-v: 0.132
-permissions: 0.131
-virtual: 0.119
-TCG: 0.104
-assembly: 0.098
-files: 0.092
-PID: 0.074
-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/118/socket/1663079 b/results/classifier/118/socket/1663079
deleted file mode 100644
index a49d8360..00000000
--- a/results/classifier/118/socket/1663079
+++ /dev/null
@@ -1,57 +0,0 @@
-socket: 0.980
-network: 0.964
-device: 0.847
-performance: 0.788
-kernel: 0.780
-graphic: 0.760
-architecture: 0.702
-x86: 0.659
-mistranslation: 0.595
-PID: 0.578
-peripherals: 0.566
-register: 0.565
-semantic: 0.547
-ppc: 0.536
-user-level: 0.524
-permissions: 0.473
-vnc: 0.430
-debug: 0.387
-boot: 0.384
-risc-v: 0.374
-virtual: 0.348
-i386: 0.341
-hypervisor: 0.302
-arm: 0.301
-assembly: 0.224
-VMM: 0.164
-TCG: 0.135
-files: 0.117
-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/118/socket/1721220 b/results/classifier/118/socket/1721220
deleted file mode 100644
index f2488cdc..00000000
--- a/results/classifier/118/socket/1721220
+++ /dev/null
@@ -1,66 +0,0 @@
-socket: 0.988
-device: 0.961
-ppc: 0.950
-peripherals: 0.927
-files: 0.914
-PID: 0.905
-debug: 0.856
-vnc: 0.839
-permissions: 0.832
-performance: 0.826
-network: 0.777
-kernel: 0.759
-boot: 0.758
-architecture: 0.743
-VMM: 0.716
-risc-v: 0.716
-register: 0.698
-arm: 0.691
-user-level: 0.689
-virtual: 0.672
-TCG: 0.662
-graphic: 0.636
-KVM: 0.623
-hypervisor: 0.590
-semantic: 0.539
-x86: 0.528
-mistranslation: 0.495
-i386: 0.419
-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/118/socket/1721222 b/results/classifier/118/socket/1721222
deleted file mode 100644
index f64f71bd..00000000
--- a/results/classifier/118/socket/1721222
+++ /dev/null
@@ -1,49 +0,0 @@
-socket: 0.971
-device: 0.969
-ppc: 0.944
-graphic: 0.938
-performance: 0.917
-files: 0.895
-network: 0.884
-PID: 0.863
-vnc: 0.859
-peripherals: 0.839
-VMM: 0.811
-TCG: 0.789
-debug: 0.762
-boot: 0.761
-semantic: 0.756
-risc-v: 0.755
-permissions: 0.746
-kernel: 0.745
-mistranslation: 0.724
-architecture: 0.709
-arm: 0.706
-register: 0.692
-virtual: 0.622
-hypervisor: 0.582
-user-level: 0.563
-i386: 0.529
-x86: 0.472
-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/118/socket/1721224 b/results/classifier/118/socket/1721224
deleted file mode 100644
index 09f87625..00000000
--- a/results/classifier/118/socket/1721224
+++ /dev/null
@@ -1,56 +0,0 @@
-socket: 0.942
-device: 0.868
-performance: 0.862
-ppc: 0.849
-PID: 0.740
-mistranslation: 0.735
-semantic: 0.709
-debug: 0.689
-peripherals: 0.683
-architecture: 0.682
-graphic: 0.682
-vnc: 0.656
-network: 0.655
-user-level: 0.649
-kernel: 0.625
-files: 0.618
-VMM: 0.616
-permissions: 0.571
-register: 0.566
-risc-v: 0.547
-boot: 0.505
-x86: 0.487
-hypervisor: 0.485
-TCG: 0.464
-arm: 0.389
-virtual: 0.379
-KVM: 0.324
-i386: 0.319
-assembly: 0.292
-
-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/118/socket/1744009 b/results/classifier/118/socket/1744009
deleted file mode 100644
index 45e61c95..00000000
--- a/results/classifier/118/socket/1744009
+++ /dev/null
@@ -1,58 +0,0 @@
-socket: 0.942
-device: 0.941
-x86: 0.857
-performance: 0.831
-network: 0.827
-graphic: 0.823
-user-level: 0.790
-architecture: 0.763
-semantic: 0.754
-mistranslation: 0.685
-vnc: 0.661
-peripherals: 0.621
-permissions: 0.583
-PID: 0.560
-debug: 0.522
-ppc: 0.518
-virtual: 0.506
-register: 0.485
-VMM: 0.465
-kernel: 0.441
-files: 0.432
-TCG: 0.394
-risc-v: 0.367
-boot: 0.338
-hypervisor: 0.335
-arm: 0.332
-assembly: 0.293
-i386: 0.244
-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/118/socket/1754605 b/results/classifier/118/socket/1754605
deleted file mode 100644
index 11dfdc34..00000000
--- a/results/classifier/118/socket/1754605
+++ /dev/null
@@ -1,52 +0,0 @@
-socket: 0.980
-ppc: 0.912
-graphic: 0.787
-device: 0.701
-virtual: 0.539
-semantic: 0.436
-VMM: 0.433
-mistranslation: 0.408
-vnc: 0.396
-PID: 0.385
-network: 0.375
-arm: 0.364
-architecture: 0.363
-user-level: 0.356
-risc-v: 0.344
-performance: 0.339
-boot: 0.336
-i386: 0.312
-kernel: 0.296
-debug: 0.265
-register: 0.243
-TCG: 0.212
-KVM: 0.200
-x86: 0.188
-permissions: 0.186
-files: 0.177
-peripherals: 0.151
-assembly: 0.129
-hypervisor: 0.127
-
-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/118/socket/1756 b/results/classifier/118/socket/1756
deleted file mode 100644
index 949090d1..00000000
--- a/results/classifier/118/socket/1756
+++ /dev/null
@@ -1,73 +0,0 @@
-socket: 0.802
-graphic: 0.771
-device: 0.754
-kernel: 0.742
-performance: 0.724
-architecture: 0.689
-debug: 0.678
-x86: 0.664
-network: 0.646
-PID: 0.565
-vnc: 0.558
-ppc: 0.518
-hypervisor: 0.510
-permissions: 0.499
-VMM: 0.490
-risc-v: 0.489
-semantic: 0.474
-user-level: 0.444
-assembly: 0.430
-mistranslation: 0.423
-files: 0.417
-i386: 0.414
-boot: 0.381
-peripherals: 0.361
-arm: 0.334
-TCG: 0.295
-register: 0.283
-KVM: 0.258
-virtual: 0.172
-
-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/118/socket/1781280 b/results/classifier/118/socket/1781280
deleted file mode 100644
index f74cc92f..00000000
--- a/results/classifier/118/socket/1781280
+++ /dev/null
@@ -1,44 +0,0 @@
-socket: 0.962
-x86: 0.881
-architecture: 0.876
-network: 0.851
-permissions: 0.825
-device: 0.794
-arm: 0.743
-graphic: 0.697
-performance: 0.679
-vnc: 0.627
-risc-v: 0.609
-peripherals: 0.574
-kernel: 0.569
-PID: 0.511
-TCG: 0.506
-boot: 0.498
-register: 0.495
-mistranslation: 0.460
-ppc: 0.459
-VMM: 0.455
-files: 0.455
-semantic: 0.444
-i386: 0.398
-debug: 0.363
-KVM: 0.340
-hypervisor: 0.282
-user-level: 0.174
-virtual: 0.079
-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/118/socket/1796754 b/results/classifier/118/socket/1796754
deleted file mode 100644
index cd292e60..00000000
--- a/results/classifier/118/socket/1796754
+++ /dev/null
@@ -1,68 +0,0 @@
-socket: 0.896
-architecture: 0.819
-ppc: 0.815
-graphic: 0.787
-x86: 0.753
-network: 0.713
-kernel: 0.709
-device: 0.688
-semantic: 0.674
-user-level: 0.663
-files: 0.617
-debug: 0.605
-performance: 0.602
-PID: 0.595
-register: 0.557
-permissions: 0.555
-TCG: 0.553
-vnc: 0.545
-arm: 0.527
-VMM: 0.523
-mistranslation: 0.520
-hypervisor: 0.513
-risc-v: 0.502
-virtual: 0.496
-peripherals: 0.489
-boot: 0.428
-assembly: 0.388
-i386: 0.313
-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/118/socket/1829945 b/results/classifier/118/socket/1829945
deleted file mode 100644
index fb0c7426..00000000
--- a/results/classifier/118/socket/1829945
+++ /dev/null
@@ -1,79 +0,0 @@
-socket: 0.843
-graphic: 0.790
-architecture: 0.770
-device: 0.762
-x86: 0.742
-PID: 0.715
-performance: 0.706
-KVM: 0.697
-user-level: 0.671
-peripherals: 0.661
-arm: 0.646
-network: 0.645
-files: 0.644
-kernel: 0.629
-virtual: 0.624
-boot: 0.619
-vnc: 0.594
-register: 0.560
-TCG: 0.559
-permissions: 0.545
-hypervisor: 0.544
-debug: 0.535
-risc-v: 0.525
-ppc: 0.522
-assembly: 0.451
-semantic: 0.445
-i386: 0.415
-VMM: 0.379
-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/118/socket/1837 b/results/classifier/118/socket/1837
deleted file mode 100644
index 9ea90352..00000000
--- a/results/classifier/118/socket/1837
+++ /dev/null
@@ -1,65 +0,0 @@
-socket: 0.927
-user-level: 0.885
-architecture: 0.824
-device: 0.713
-arm: 0.687
-network: 0.685
-peripherals: 0.625
-PID: 0.609
-graphic: 0.530
-ppc: 0.514
-kernel: 0.460
-performance: 0.442
-files: 0.421
-semantic: 0.352
-vnc: 0.301
-TCG: 0.289
-boot: 0.279
-risc-v: 0.244
-VMM: 0.242
-debug: 0.185
-i386: 0.156
-mistranslation: 0.150
-x86: 0.136
-assembly: 0.130
-virtual: 0.115
-KVM: 0.114
-register: 0.093
-hypervisor: 0.078
-permissions: 0.022
-
-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/118/socket/1837651 b/results/classifier/118/socket/1837651
deleted file mode 100644
index fa216ac2..00000000
--- a/results/classifier/118/socket/1837651
+++ /dev/null
@@ -1,51 +0,0 @@
-i386: 0.972
-socket: 0.931
-performance: 0.775
-network: 0.766
-graphic: 0.712
-x86: 0.710
-device: 0.659
-vnc: 0.598
-ppc: 0.589
-kernel: 0.457
-architecture: 0.456
-mistranslation: 0.450
-PID: 0.444
-permissions: 0.441
-debug: 0.426
-peripherals: 0.424
-semantic: 0.408
-files: 0.399
-register: 0.396
-arm: 0.344
-user-level: 0.342
-boot: 0.299
-TCG: 0.290
-hypervisor: 0.270
-risc-v: 0.232
-virtual: 0.220
-VMM: 0.212
-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/118/socket/1843590 b/results/classifier/118/socket/1843590
deleted file mode 100644
index c8415c24..00000000
--- a/results/classifier/118/socket/1843590
+++ /dev/null
@@ -1,66 +0,0 @@
-socket: 0.870
-network: 0.841
-graphic: 0.836
-debug: 0.797
-peripherals: 0.779
-hypervisor: 0.769
-device: 0.755
-performance: 0.751
-PID: 0.742
-mistranslation: 0.727
-architecture: 0.703
-virtual: 0.689
-kernel: 0.644
-ppc: 0.644
-VMM: 0.634
-vnc: 0.609
-files: 0.594
-risc-v: 0.580
-permissions: 0.571
-TCG: 0.544
-user-level: 0.502
-boot: 0.477
-semantic: 0.473
-KVM: 0.446
-assembly: 0.427
-x86: 0.425
-arm: 0.410
-register: 0.358
-i386: 0.329
-
-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/118/socket/1861884 b/results/classifier/118/socket/1861884
deleted file mode 100644
index 18ebc638..00000000
--- a/results/classifier/118/socket/1861884
+++ /dev/null
@@ -1,67 +0,0 @@
-socket: 0.964
-x86: 0.957
-network: 0.883
-device: 0.833
-peripherals: 0.815
-architecture: 0.815
-graphic: 0.801
-performance: 0.797
-files: 0.735
-vnc: 0.713
-mistranslation: 0.710
-PID: 0.678
-permissions: 0.677
-i386: 0.665
-VMM: 0.639
-user-level: 0.618
-ppc: 0.617
-risc-v: 0.602
-semantic: 0.581
-register: 0.568
-virtual: 0.567
-boot: 0.558
-kernel: 0.556
-hypervisor: 0.541
-debug: 0.495
-arm: 0.433
-TCG: 0.405
-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/118/socket/1867601 b/results/classifier/118/socket/1867601
deleted file mode 100644
index 65ae02b5..00000000
--- a/results/classifier/118/socket/1867601
+++ /dev/null
@@ -1,51 +0,0 @@
-socket: 0.974
-graphic: 0.871
-network: 0.848
-device: 0.786
-performance: 0.754
-ppc: 0.712
-kernel: 0.685
-debug: 0.621
-mistranslation: 0.596
-files: 0.596
-vnc: 0.592
-architecture: 0.570
-register: 0.558
-arm: 0.549
-risc-v: 0.536
-semantic: 0.516
-PID: 0.515
-permissions: 0.514
-boot: 0.475
-user-level: 0.430
-TCG: 0.407
-i386: 0.406
-peripherals: 0.386
-VMM: 0.382
-x86: 0.345
-virtual: 0.303
-hypervisor: 0.264
-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/118/socket/1886 b/results/classifier/118/socket/1886
deleted file mode 100644
index 8a6c31c7..00000000
--- a/results/classifier/118/socket/1886
+++ /dev/null
@@ -1,47 +0,0 @@
-socket: 0.931
-device: 0.818
-graphic: 0.746
-semantic: 0.729
-performance: 0.716
-x86: 0.709
-PID: 0.570
-ppc: 0.534
-network: 0.532
-vnc: 0.509
-TCG: 0.481
-debug: 0.432
-register: 0.417
-files: 0.393
-arm: 0.334
-permissions: 0.333
-mistranslation: 0.331
-risc-v: 0.325
-i386: 0.284
-kernel: 0.274
-boot: 0.267
-architecture: 0.250
-VMM: 0.243
-virtual: 0.183
-user-level: 0.173
-peripherals: 0.108
-hypervisor: 0.099
-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/118/socket/1904 b/results/classifier/118/socket/1904
deleted file mode 100644
index 8781001d..00000000
--- a/results/classifier/118/socket/1904
+++ /dev/null
@@ -1,46 +0,0 @@
-socket: 0.915
-device: 0.852
-graphic: 0.757
-ppc: 0.753
-architecture: 0.734
-vnc: 0.673
-network: 0.672
-PID: 0.637
-semantic: 0.535
-files: 0.535
-debug: 0.533
-performance: 0.509
-register: 0.444
-VMM: 0.430
-permissions: 0.421
-TCG: 0.415
-peripherals: 0.384
-risc-v: 0.360
-arm: 0.335
-kernel: 0.298
-x86: 0.284
-i386: 0.239
-user-level: 0.213
-mistranslation: 0.213
-boot: 0.199
-hypervisor: 0.119
-virtual: 0.112
-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/118/socket/1907926 b/results/classifier/118/socket/1907926
deleted file mode 100644
index e7379c0b..00000000
--- a/results/classifier/118/socket/1907926
+++ /dev/null
@@ -1,68 +0,0 @@
-socket: 0.921
-device: 0.886
-permissions: 0.722
-user-level: 0.691
-graphic: 0.652
-network: 0.605
-semantic: 0.580
-architecture: 0.539
-mistranslation: 0.532
-register: 0.518
-performance: 0.514
-debug: 0.511
-peripherals: 0.502
-files: 0.500
-TCG: 0.497
-vnc: 0.480
-risc-v: 0.469
-i386: 0.453
-ppc: 0.453
-virtual: 0.435
-x86: 0.424
-hypervisor: 0.417
-VMM: 0.416
-PID: 0.384
-boot: 0.378
-kernel: 0.359
-KVM: 0.348
-arm: 0.330
-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/118/socket/1923692 b/results/classifier/118/socket/1923692
deleted file mode 100644
index a728a362..00000000
--- a/results/classifier/118/socket/1923692
+++ /dev/null
@@ -1,46 +0,0 @@
-socket: 0.872
-network: 0.800
-device: 0.733
-architecture: 0.480
-mistranslation: 0.439
-vnc: 0.352
-graphic: 0.346
-semantic: 0.345
-files: 0.341
-risc-v: 0.327
-arm: 0.323
-i386: 0.314
-boot: 0.305
-ppc: 0.303
-virtual: 0.293
-PID: 0.271
-kernel: 0.267
-register: 0.256
-x86: 0.255
-peripherals: 0.200
-VMM: 0.188
-permissions: 0.180
-debug: 0.156
-TCG: 0.155
-hypervisor: 0.136
-KVM: 0.116
-performance: 0.096
-assembly: 0.058
-user-level: 0.037
-
-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/118/socket/1925449 b/results/classifier/118/socket/1925449
deleted file mode 100644
index 70efdf84..00000000
--- a/results/classifier/118/socket/1925449
+++ /dev/null
@@ -1,76 +0,0 @@
-socket: 0.955
-kernel: 0.919
-device: 0.889
-vnc: 0.877
-ppc: 0.864
-x86: 0.859
-network: 0.848
-PID: 0.831
-architecture: 0.803
-performance: 0.757
-permissions: 0.757
-register: 0.749
-arm: 0.723
-hypervisor: 0.714
-boot: 0.704
-files: 0.673
-TCG: 0.637
-VMM: 0.630
-graphic: 0.607
-peripherals: 0.520
-user-level: 0.510
-risc-v: 0.493
-debug: 0.479
-mistranslation: 0.472
-assembly: 0.400
-i386: 0.348
-semantic: 0.292
-KVM: 0.291
-virtual: 0.265
-
-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/118/socket/1949 b/results/classifier/118/socket/1949
deleted file mode 100644
index 882c9a8e..00000000
--- a/results/classifier/118/socket/1949
+++ /dev/null
@@ -1,42 +0,0 @@
-socket: 0.935
-device: 0.862
-PID: 0.768
-network: 0.668
-graphic: 0.646
-TCG: 0.626
-permissions: 0.566
-kernel: 0.534
-performance: 0.531
-mistranslation: 0.523
-architecture: 0.522
-assembly: 0.495
-debug: 0.448
-user-level: 0.440
-ppc: 0.434
-semantic: 0.433
-vnc: 0.401
-risc-v: 0.385
-arm: 0.371
-i386: 0.367
-VMM: 0.338
-register: 0.315
-KVM: 0.267
-x86: 0.256
-peripherals: 0.234
-hypervisor: 0.228
-boot: 0.222
-files: 0.180
-virtual: 0.107
-
-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/118/socket/2254 b/results/classifier/118/socket/2254
deleted file mode 100644
index 788a8b35..00000000
--- a/results/classifier/118/socket/2254
+++ /dev/null
@@ -1,31 +0,0 @@
-socket: 0.931
-network: 0.756
-device: 0.657
-vnc: 0.572
-peripherals: 0.550
-architecture: 0.548
-graphic: 0.443
-arm: 0.410
-performance: 0.394
-VMM: 0.388
-mistranslation: 0.385
-semantic: 0.376
-risc-v: 0.355
-TCG: 0.352
-permissions: 0.328
-ppc: 0.309
-debug: 0.294
-kernel: 0.258
-PID: 0.211
-boot: 0.195
-register: 0.183
-KVM: 0.143
-virtual: 0.139
-files: 0.127
-assembly: 0.103
-user-level: 0.097
-i386: 0.094
-x86: 0.087
-hypervisor: 0.024
-
-UNCHECKED_FUNC_RES.LIB.STRICT in /io/channel-socket.c
diff --git a/results/classifier/118/socket/2292 b/results/classifier/118/socket/2292
deleted file mode 100644
index f9759a82..00000000
--- a/results/classifier/118/socket/2292
+++ /dev/null
@@ -1,49 +0,0 @@
-socket: 0.956
-virtual: 0.921
-architecture: 0.888
-performance: 0.877
-device: 0.866
-x86: 0.847
-kernel: 0.843
-network: 0.799
-files: 0.781
-VMM: 0.779
-vnc: 0.779
-graphic: 0.760
-TCG: 0.759
-hypervisor: 0.752
-register: 0.711
-ppc: 0.703
-arm: 0.637
-peripherals: 0.605
-debug: 0.576
-user-level: 0.575
-PID: 0.573
-risc-v: 0.570
-semantic: 0.562
-permissions: 0.562
-mistranslation: 0.453
-boot: 0.413
-i386: 0.393
-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/118/socket/2341 b/results/classifier/118/socket/2341
deleted file mode 100644
index 54f6efc9..00000000
--- a/results/classifier/118/socket/2341
+++ /dev/null
@@ -1,62 +0,0 @@
-socket: 0.928
-graphic: 0.924
-device: 0.907
-performance: 0.905
-user-level: 0.898
-mistranslation: 0.887
-PID: 0.849
-semantic: 0.809
-debug: 0.780
-peripherals: 0.771
-permissions: 0.755
-kernel: 0.716
-virtual: 0.708
-i386: 0.707
-architecture: 0.706
-hypervisor: 0.697
-network: 0.692
-ppc: 0.684
-x86: 0.665
-files: 0.647
-VMM: 0.633
-risc-v: 0.566
-assembly: 0.555
-register: 0.548
-boot: 0.537
-vnc: 0.489
-TCG: 0.478
-KVM: 0.444
-arm: 0.427
-
-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/118/socket/2444 b/results/classifier/118/socket/2444
deleted file mode 100644
index 50146b02..00000000
--- a/results/classifier/118/socket/2444
+++ /dev/null
@@ -1,31 +0,0 @@
-socket: 0.870
-architecture: 0.743
-device: 0.720
-network: 0.682
-performance: 0.675
-graphic: 0.509
-arm: 0.487
-debug: 0.453
-semantic: 0.443
-kernel: 0.437
-register: 0.431
-vnc: 0.428
-mistranslation: 0.386
-TCG: 0.357
-boot: 0.344
-VMM: 0.340
-peripherals: 0.326
-virtual: 0.288
-files: 0.277
-user-level: 0.268
-permissions: 0.268
-x86: 0.264
-assembly: 0.248
-ppc: 0.244
-hypervisor: 0.237
-i386: 0.178
-risc-v: 0.136
-KVM: 0.127
-PID: 0.125
-
-Use of vulnerable function 'strcpy' at can_socketcan.c:213. This function is unsafe.
diff --git a/results/classifier/118/socket/2584 b/results/classifier/118/socket/2584
deleted file mode 100644
index 169df852..00000000
--- a/results/classifier/118/socket/2584
+++ /dev/null
@@ -1,46 +0,0 @@
-socket: 0.966
-debug: 0.866
-graphic: 0.816
-network: 0.728
-device: 0.684
-performance: 0.592
-semantic: 0.486
-hypervisor: 0.386
-kernel: 0.384
-i386: 0.350
-boot: 0.335
-virtual: 0.314
-vnc: 0.313
-register: 0.262
-x86: 0.229
-mistranslation: 0.223
-ppc: 0.202
-peripherals: 0.194
-permissions: 0.191
-KVM: 0.185
-PID: 0.179
-risc-v: 0.176
-VMM: 0.174
-files: 0.171
-architecture: 0.144
-user-level: 0.135
-arm: 0.123
-TCG: 0.103
-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/118/socket/2624 b/results/classifier/118/socket/2624
deleted file mode 100644
index 5e1a247d..00000000
--- a/results/classifier/118/socket/2624
+++ /dev/null
@@ -1,69 +0,0 @@
-socket: 0.988
-device: 0.988
-permissions: 0.951
-debug: 0.934
-peripherals: 0.929
-files: 0.908
-ppc: 0.904
-architecture: 0.903
-graphic: 0.896
-performance: 0.894
-register: 0.890
-boot: 0.842
-user-level: 0.833
-network: 0.774
-kernel: 0.771
-PID: 0.761
-semantic: 0.700
-hypervisor: 0.667
-vnc: 0.649
-virtual: 0.638
-arm: 0.610
-mistranslation: 0.539
-TCG: 0.536
-x86: 0.532
-risc-v: 0.494
-VMM: 0.431
-assembly: 0.394
-KVM: 0.378
-i386: 0.254
-
-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/118/socket/284 b/results/classifier/118/socket/284
deleted file mode 100644
index 1fa064b9..00000000
--- a/results/classifier/118/socket/284
+++ /dev/null
@@ -1,31 +0,0 @@
-socket: 0.916
-performance: 0.506
-network: 0.451
-graphic: 0.336
-peripherals: 0.252
-semantic: 0.155
-device: 0.151
-arm: 0.151
-mistranslation: 0.140
-debug: 0.135
-register: 0.134
-vnc: 0.126
-x86: 0.099
-files: 0.098
-ppc: 0.091
-risc-v: 0.083
-VMM: 0.082
-user-level: 0.074
-virtual: 0.069
-boot: 0.055
-kernel: 0.050
-PID: 0.043
-i386: 0.036
-TCG: 0.035
-architecture: 0.022
-assembly: 0.018
-permissions: 0.015
-KVM: 0.014
-hypervisor: 0.004
-
-Assertion failed: (buf_len != 0), function soread, file socket.c, line 183.
diff --git a/results/classifier/118/socket/2867 b/results/classifier/118/socket/2867
deleted file mode 100644
index 39d2d2b2..00000000
--- a/results/classifier/118/socket/2867
+++ /dev/null
@@ -1,43 +0,0 @@
-socket: 0.901
-device: 0.891
-graphic: 0.879
-files: 0.857
-vnc: 0.777
-semantic: 0.757
-network: 0.754
-PID: 0.719
-VMM: 0.708
-register: 0.705
-performance: 0.690
-debug: 0.682
-permissions: 0.675
-i386: 0.661
-risc-v: 0.660
-mistranslation: 0.639
-TCG: 0.635
-ppc: 0.621
-hypervisor: 0.537
-boot: 0.534
-architecture: 0.526
-kernel: 0.518
-arm: 0.515
-x86: 0.510
-user-level: 0.434
-KVM: 0.336
-virtual: 0.322
-assembly: 0.313
-peripherals: 0.310
-
-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/118/socket/2876 b/results/classifier/118/socket/2876
deleted file mode 100644
index 7290b7c2..00000000
--- a/results/classifier/118/socket/2876
+++ /dev/null
@@ -1,44 +0,0 @@
-socket: 0.951
-graphic: 0.932
-device: 0.929
-network: 0.895
-virtual: 0.854
-vnc: 0.843
-architecture: 0.832
-arm: 0.771
-PID: 0.731
-register: 0.713
-boot: 0.661
-debug: 0.647
-kernel: 0.623
-KVM: 0.596
-permissions: 0.581
-ppc: 0.572
-mistranslation: 0.538
-VMM: 0.523
-risc-v: 0.503
-semantic: 0.464
-performance: 0.418
-TCG: 0.379
-i386: 0.372
-peripherals: 0.367
-x86: 0.326
-hypervisor: 0.265
-user-level: 0.244
-assembly: 0.201
-files: 0.194
-
-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/118/socket/2925 b/results/classifier/118/socket/2925
deleted file mode 100644
index b097a31c..00000000
--- a/results/classifier/118/socket/2925
+++ /dev/null
@@ -1,55 +0,0 @@
-socket: 0.860
-device: 0.796
-architecture: 0.718
-ppc: 0.642
-PID: 0.620
-graphic: 0.612
-network: 0.594
-semantic: 0.573
-VMM: 0.543
-KVM: 0.541
-vnc: 0.537
-hypervisor: 0.531
-risc-v: 0.506
-files: 0.487
-x86: 0.473
-kernel: 0.470
-performance: 0.464
-arm: 0.458
-TCG: 0.457
-permissions: 0.441
-i386: 0.427
-boot: 0.419
-register: 0.409
-mistranslation: 0.395
-peripherals: 0.365
-user-level: 0.329
-debug: 0.273
-virtual: 0.212
-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/118/socket/347 b/results/classifier/118/socket/347
deleted file mode 100644
index 014ce1b2..00000000
--- a/results/classifier/118/socket/347
+++ /dev/null
@@ -1,31 +0,0 @@
-socket: 0.961
-network: 0.960
-architecture: 0.939
-device: 0.798
-performance: 0.680
-arm: 0.622
-risc-v: 0.619
-vnc: 0.600
-peripherals: 0.575
-mistranslation: 0.572
-TCG: 0.568
-VMM: 0.557
-boot: 0.549
-PID: 0.535
-graphic: 0.487
-semantic: 0.450
-virtual: 0.438
-ppc: 0.403
-i386: 0.347
-KVM: 0.343
-x86: 0.288
-kernel: 0.275
-permissions: 0.267
-debug: 0.204
-register: 0.187
-files: 0.127
-user-level: 0.105
-assembly: 0.054
-hypervisor: 0.035
-
-Forward host UNIX socket to guest TCP port
diff --git a/results/classifier/118/socket/761471 b/results/classifier/118/socket/761471
deleted file mode 100644
index d10976f5..00000000
--- a/results/classifier/118/socket/761471
+++ /dev/null
@@ -1,45 +0,0 @@
-socket: 0.872
-network: 0.805
-device: 0.660
-vnc: 0.601
-performance: 0.586
-semantic: 0.559
-graphic: 0.553
-register: 0.443
-user-level: 0.429
-risc-v: 0.389
-ppc: 0.372
-i386: 0.350
-PID: 0.346
-architecture: 0.330
-peripherals: 0.312
-VMM: 0.293
-mistranslation: 0.293
-files: 0.286
-permissions: 0.273
-debug: 0.271
-boot: 0.269
-x86: 0.267
-kernel: 0.267
-arm: 0.256
-hypervisor: 0.252
-TCG: 0.204
-virtual: 0.179
-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/118/socket/833 b/results/classifier/118/socket/833
deleted file mode 100644
index 25bd2fcf..00000000
--- a/results/classifier/118/socket/833
+++ /dev/null
@@ -1,72 +0,0 @@
-socket: 0.983
-user-level: 0.966
-kernel: 0.956
-network: 0.942
-performance: 0.924
-device: 0.914
-architecture: 0.893
-arm: 0.889
-graphic: 0.863
-x86: 0.820
-PID: 0.818
-files: 0.815
-permissions: 0.808
-ppc: 0.793
-register: 0.768
-debug: 0.758
-vnc: 0.742
-mistranslation: 0.721
-VMM: 0.712
-TCG: 0.696
-risc-v: 0.681
-boot: 0.674
-assembly: 0.650
-hypervisor: 0.605
-peripherals: 0.601
-i386: 0.596
-semantic: 0.594
-KVM: 0.473
-virtual: 0.204
-
-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.
-- 
cgit 1.4.1