From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 19:39:53 +0200 Subject: restructure results --- results/classifier/108/socket/1055 | 31 --------- results/classifier/108/socket/1064631 | 33 --------- results/classifier/108/socket/1075272 | 32 --------- results/classifier/108/socket/1264 | 16 ----- results/classifier/108/socket/1450881 | 127 ---------------------------------- results/classifier/108/socket/1542965 | 25 ------- results/classifier/108/socket/1663079 | 42 ----------- results/classifier/108/socket/1673373 | 125 --------------------------------- results/classifier/108/socket/1721220 | 51 -------------- results/classifier/108/socket/1721222 | 34 --------- results/classifier/108/socket/1721224 | 41 ----------- results/classifier/108/socket/1744009 | 43 ------------ results/classifier/108/socket/1754605 | 37 ---------- results/classifier/108/socket/1781280 | 29 -------- results/classifier/108/socket/1837 | 50 ------------- results/classifier/108/socket/1837651 | 36 ---------- results/classifier/108/socket/1861884 | 52 -------------- results/classifier/108/socket/1867601 | 36 ---------- results/classifier/108/socket/1886 | 32 --------- results/classifier/108/socket/1907926 | 53 -------------- results/classifier/108/socket/1925449 | 61 ---------------- results/classifier/108/socket/1949 | 27 -------- results/classifier/108/socket/2254 | 16 ----- results/classifier/108/socket/2292 | 34 --------- results/classifier/108/socket/2341 | 47 ------------- results/classifier/108/socket/2584 | 31 --------- results/classifier/108/socket/2624 | 54 --------------- results/classifier/108/socket/2876 | 29 -------- results/classifier/108/socket/347 | 16 ----- results/classifier/108/socket/833 | 57 --------------- 30 files changed, 1297 deletions(-) delete mode 100644 results/classifier/108/socket/1055 delete mode 100644 results/classifier/108/socket/1064631 delete mode 100644 results/classifier/108/socket/1075272 delete mode 100644 results/classifier/108/socket/1264 delete mode 100644 results/classifier/108/socket/1450881 delete mode 100644 results/classifier/108/socket/1542965 delete mode 100644 results/classifier/108/socket/1663079 delete mode 100644 results/classifier/108/socket/1673373 delete mode 100644 results/classifier/108/socket/1721220 delete mode 100644 results/classifier/108/socket/1721222 delete mode 100644 results/classifier/108/socket/1721224 delete mode 100644 results/classifier/108/socket/1744009 delete mode 100644 results/classifier/108/socket/1754605 delete mode 100644 results/classifier/108/socket/1781280 delete mode 100644 results/classifier/108/socket/1837 delete mode 100644 results/classifier/108/socket/1837651 delete mode 100644 results/classifier/108/socket/1861884 delete mode 100644 results/classifier/108/socket/1867601 delete mode 100644 results/classifier/108/socket/1886 delete mode 100644 results/classifier/108/socket/1907926 delete mode 100644 results/classifier/108/socket/1925449 delete mode 100644 results/classifier/108/socket/1949 delete mode 100644 results/classifier/108/socket/2254 delete mode 100644 results/classifier/108/socket/2292 delete mode 100644 results/classifier/108/socket/2341 delete mode 100644 results/classifier/108/socket/2584 delete mode 100644 results/classifier/108/socket/2624 delete mode 100644 results/classifier/108/socket/2876 delete mode 100644 results/classifier/108/socket/347 delete mode 100644 results/classifier/108/socket/833 (limited to 'results/classifier/108/socket') diff --git a/results/classifier/108/socket/1055 b/results/classifier/108/socket/1055 deleted file mode 100644 index 1fe16ce9..00000000 --- a/results/classifier/108/socket/1055 +++ /dev/null @@ -1,31 +0,0 @@ -socket: 0.982 -PID: 0.882 -device: 0.838 -performance: 0.828 -network: 0.764 -graphic: 0.745 -debug: 0.546 -permissions: 0.446 -semantic: 0.438 -vnc: 0.421 -boot: 0.400 -KVM: 0.348 -files: 0.304 -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/108/socket/1064631 b/results/classifier/108/socket/1064631 deleted file mode 100644 index 3a33db77..00000000 --- a/results/classifier/108/socket/1064631 +++ /dev/null @@ -1,33 +0,0 @@ -socket: 0.956 -network: 0.947 -device: 0.795 -graphic: 0.635 -permissions: 0.582 -semantic: 0.458 -other: 0.404 -vnc: 0.389 -PID: 0.328 -boot: 0.301 -performance: 0.272 -KVM: 0.268 -files: 0.255 -debug: 0.155 - -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/108/socket/1075272 b/results/classifier/108/socket/1075272 deleted file mode 100644 index 9fa30fd2..00000000 --- a/results/classifier/108/socket/1075272 +++ /dev/null @@ -1,32 +0,0 @@ -socket: 0.921 -network: 0.791 -device: 0.791 -performance: 0.633 -other: 0.571 -graphic: 0.546 -files: 0.439 -vnc: 0.435 -permissions: 0.403 -boot: 0.360 -PID: 0.292 -KVM: 0.290 -debug: 0.255 -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/108/socket/1264 b/results/classifier/108/socket/1264 deleted file mode 100644 index 6ca4fd51..00000000 --- a/results/classifier/108/socket/1264 +++ /dev/null @@ -1,16 +0,0 @@ -socket: 0.953 -device: 0.816 -network: 0.713 -performance: 0.695 -graphic: 0.276 -PID: 0.256 -other: 0.248 -semantic: 0.241 -debug: 0.170 -boot: 0.155 -permissions: 0.121 -KVM: 0.078 -files: 0.059 -vnc: 0.053 - -socket chardev loses data when remote end closes the connection diff --git a/results/classifier/108/socket/1450881 b/results/classifier/108/socket/1450881 deleted file mode 100644 index 5801de92..00000000 --- a/results/classifier/108/socket/1450881 +++ /dev/null @@ -1,127 +0,0 @@ -socket: 0.965 -boot: 0.957 -debug: 0.955 -device: 0.955 -permissions: 0.946 -network: 0.940 -other: 0.938 -PID: 0.936 -performance: 0.930 -graphic: 0.930 -semantic: 0.925 -files: 0.922 -vnc: 0.908 -KVM: 0.893 - -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 < -