diff options
Diffstat (limited to 'results/classifier/zero-shot/108/socket')
30 files changed, 1297 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/socket/1055 b/results/classifier/zero-shot/108/socket/1055 new file mode 100644 index 00000000..1fe16ce9 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1055 @@ -0,0 +1,31 @@ +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/zero-shot/108/socket/1064631 b/results/classifier/zero-shot/108/socket/1064631 new file mode 100644 index 00000000..3a33db77 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1064631 @@ -0,0 +1,33 @@ +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/zero-shot/108/socket/1075272 b/results/classifier/zero-shot/108/socket/1075272 new file mode 100644 index 00000000..9fa30fd2 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1075272 @@ -0,0 +1,32 @@ +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/zero-shot/108/socket/1264 b/results/classifier/zero-shot/108/socket/1264 new file mode 100644 index 00000000..6ca4fd51 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1264 @@ -0,0 +1,16 @@ +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/zero-shot/108/socket/1450881 b/results/classifier/zero-shot/108/socket/1450881 new file mode 100644 index 00000000..5801de92 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1450881 @@ -0,0 +1,127 @@ +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 < +<email address hidden>> wrote: + +> Proposed patch posted to mailing list: +> https://lists.nongnu.org/archive/html/qemu-devel/2016-04/msg01645.html - +> please test and report back. +> +> -- +> You received this bug notification because you are subscribed to the bug +> report. +> https://bugs.launchpad.net/bugs/1450881 +> +> Title: +> qemu-system-sparc MUTEX_HELD assert and libC lock errors +> +> Status in QEMU: +> New +> +> Bug description: +> Here I am cross-posting a comment I made on Artyom's blog. Atar +> responded that he "fixed these issues for some customers". I hoped +> that opening a bug to the opensource project might help develop the +> solution for the public domain. +> +> I now have a mostly-working Solaris 6 emulation, with great thanks to +> the valuable information in Artyom's blog, brezular.com, and the +> QEMU/Solaris 4.14 wikibook. +> +> setup detail; +> QEMU (present git snapshot, reports --version 2.2.92) +> -M SS-20, openboot/proprietary prom +> +> # uname -a +> SunOS emu0 5.6 Generic_105181-33 sun4m sparc SUNW,SPARCstation-20 +> +> I continue to have a problem, which I have found others posted in blog +> comments, but have not seen a resolution yet. +> +> # /etc/init.d/init.dmi start +> Run-time error, libC: +> Trying to release a lock that was not acquired in this thread +> (repeat above 1x) +> Abort - core dumped +> +> as well as: +> Assertion failed: MUTEX_HELD(&svc_mutex), file rpc/svc_run.c, line 766 +> +> which prints to the console periodically when "dmispd" is running. +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1450881/+subscriptions +> + + +Excellent - thanks once again for all your help! + +Fix is included in the 2.6.0-rc2 release. + diff --git a/results/classifier/zero-shot/108/socket/1542965 b/results/classifier/zero-shot/108/socket/1542965 new file mode 100644 index 00000000..3e3eedf0 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1542965 @@ -0,0 +1,25 @@ +socket: 0.954 +device: 0.830 +network: 0.805 +performance: 0.557 +PID: 0.488 +other: 0.485 +graphic: 0.481 +vnc: 0.462 +files: 0.455 +boot: 0.365 +semantic: 0.345 +permissions: 0.315 +debug: 0.247 +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/zero-shot/108/socket/1663079 b/results/classifier/zero-shot/108/socket/1663079 new file mode 100644 index 00000000..0f22e744 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1663079 @@ -0,0 +1,42 @@ +socket: 0.980 +network: 0.964 +device: 0.847 +performance: 0.788 +graphic: 0.760 +other: 0.671 +PID: 0.578 +semantic: 0.547 +permissions: 0.473 +vnc: 0.430 +debug: 0.387 +boot: 0.384 +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/zero-shot/108/socket/1673373 b/results/classifier/zero-shot/108/socket/1673373 new file mode 100644 index 00000000..0853b3ac --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1673373 @@ -0,0 +1,125 @@ +socket: 0.959 +debug: 0.957 +other: 0.957 +permissions: 0.950 +performance: 0.950 +semantic: 0.948 +device: 0.932 +vnc: 0.925 +graphic: 0.920 +boot: 0.916 +network: 0.916 +files: 0.905 +KVM: 0.898 +PID: 0.872 + +qemu -version output is incorrect with configure --with-pkgversion + +Since qemu v2.7.0, up to the current master +(1883ff34b540daacae948f493b0ba525edf5f642) +the pkgversion feature appears to have a bug: + +$ ./configure --target-list=x86_64-softmmu --with-pkgversion=foo + +Results in this output: + +$ x86_64-softmmu/qemu-system-x86_64 -version +QEMU emulator version 2.8.90(foo) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + +This appears to have been introduced in: + +67a1de0d19 Makefile: Derive "PKGVERSION" from "git describe" by default + +The previous commit (077de81a4c) produces this output: + +$ x86_64-softmmu/qemu-system-x86_64 -version +QEMU emulator version 2.6.50 (foo), Copyright (c) 2003-2008 Fabrice Bellard + +On 16 March 2017 at 09:00, Jordan Justen <email address hidden> wrote: +> This appears to have regressed in 67a1de0d19. +> +> When the configure --with-pkgversion=foo option is used, the output +> from -version will look like: +> +> QEMU emulator version 2.8.90(foo) +> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +> +> After this patch, it will be: +> +> QEMU emulator version 2.8.90 (foo) +> Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers +> +> Cc: Paolo Bonzini <email address hidden> +> Cc: Fam Zheng <email address hidden> +> Fixes: https://bugs.launchpad.net/bugs/1673373 +> Cc: <email address hidden> +> Signed-off-by: Jordan Justen <email address hidden> +> --- +> Makefile | 2 +- +> configure | 2 +- +> vl.c | 2 +- +> 3 files changed, 3 insertions(+), 3 deletions(-) +> +> diff --git a/Makefile b/Makefile +> index 1c4c04f6f2..c9df119798 100644 +> --- a/Makefile +> +++ b/Makefile +> @@ -289,7 +289,7 @@ qemu-version.h: FORCE +> printf '"$(PKGVERSION)"\n'; \ +> else \ +> if test -d .git; then \ +> - printf '" ('; \ +> + printf '"('; \ +> git describe --match 'v*' 2>/dev/null | tr -d '\n'; \ +> if ! git diff-index --quiet HEAD &>/dev/null; then \ +> printf -- '-dirty'; \ +> diff --git a/configure b/configure +> index 99d8bece70..e94b06b5fc 100755 +> --- a/configure +> +++ b/configure +> @@ -1004,7 +1004,7 @@ for opt do +> ;; +> --disable-blobs) blobs="no" +> ;; +> - --with-pkgversion=*) pkgversion=" ($optarg)" +> + --with-pkgversion=*) pkgversion="($optarg)" +> ;; +> --with-coroutine=*) coroutine="$optarg" +> ;; +> diff --git a/vl.c b/vl.c +> index 0b4ed5241c..3e60e61905 100644 +> --- a/vl.c +> +++ b/vl.c +> @@ -1904,7 +1904,7 @@ static void main_loop(void) +> +> static void version(void) +> { +> - printf("QEMU emulator version " QEMU_VERSION QEMU_PKGVERSION "\n" +> + printf("QEMU emulator version " QEMU_VERSION " " QEMU_PKGVERSION "\n" +> QEMU_COPYRIGHT "\n"); +> } + +This is not the only place where we assemble a string from +QEMU_VERSION QEMU_PKGVERSION, so if you want to change from the +original approach where QEMU_PKGVERSION had a space in it then +you need to change the other places too. + +Also it looks like we return QEMU_PKGVERSION as part of the +QMP qmp_query_version() code, so we should check to see what +the expected behaviour there is regarding having the space +or not. + +I think when I wrote those printfs I was expecting that +QEMU_PKGVERSION might be a "-something" kind of string, +and so did whoever wrote the commit log for 67a1de0d19. +However looking at git history it seems to have always been +a " (something)" format, so obviously some confusion here... + +thanks +-- PMM + + +This should be fixed now in QEMU 2.12: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=7e563bfb8a5104ff0e + diff --git a/results/classifier/zero-shot/108/socket/1721220 b/results/classifier/zero-shot/108/socket/1721220 new file mode 100644 index 00000000..8917e103 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1721220 @@ -0,0 +1,51 @@ +socket: 0.988 +device: 0.961 +files: 0.914 +PID: 0.905 +debug: 0.856 +vnc: 0.839 +permissions: 0.832 +performance: 0.826 +network: 0.777 +boot: 0.758 +graphic: 0.636 +KVM: 0.623 +semantic: 0.539 +other: 0.423 + +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/zero-shot/108/socket/1721222 b/results/classifier/zero-shot/108/socket/1721222 new file mode 100644 index 00000000..393f01d4 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1721222 @@ -0,0 +1,34 @@ +socket: 0.971 +device: 0.969 +graphic: 0.938 +performance: 0.917 +files: 0.895 +network: 0.884 +PID: 0.863 +vnc: 0.859 +debug: 0.762 +boot: 0.761 +semantic: 0.756 +permissions: 0.746 +other: 0.587 +KVM: 0.375 + +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/zero-shot/108/socket/1721224 b/results/classifier/zero-shot/108/socket/1721224 new file mode 100644 index 00000000..aa238e1f --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1721224 @@ -0,0 +1,41 @@ +socket: 0.942 +device: 0.868 +performance: 0.862 +PID: 0.740 +semantic: 0.709 +debug: 0.689 +graphic: 0.682 +vnc: 0.656 +network: 0.655 +files: 0.618 +permissions: 0.571 +boot: 0.505 +KVM: 0.324 +other: 0.278 + +qemu crashes with Assertion `!bus->dma[0] && !bus->dma[1]' failed + +Re-production steps: +git clone today's qemu git tree (4th Oct 2017) +./configure --target-list=ppc64-softmmu && make -j 8 + +Run the device-crash-test from scripts folder, seeing the following error + +INFO: running test case: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +WARNING: qemu received signal -6: ppc64-softmmu/qemu-system-ppc64 -chardev socket,id=mon,path=/var/tmp/qemu-30972-monitor.sock -mon chardev=mon,mode=control -display none -vga none -S -machine prep,accel=tcg -device i82374 +CRITICAL: failed: machine=prep binary=ppc64-softmmu/qemu-system-ppc64 device=i82374 accel=tcg +CRITICAL: cmdline: ppc64-softmmu/qemu-system-ppc64 -S -machine prep,accel=tcg -device i82374 +CRITICAL: log: qemu-system-ppc64: hw/isa/isa-bus.c:110: isa_bus_dma: Assertion `!bus->dma[0] && !bus->dma[1]' failed. +CRITICAL: exit code: -6 + +v2 patch posted on list and waiting for review: + +https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04604.html +[PATCHv3] dma/i82374: avoid double creation of i82374 device + +v4 patch posted: +http://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg06565.html + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4968a2c6edb7b46b127c + diff --git a/results/classifier/zero-shot/108/socket/1744009 b/results/classifier/zero-shot/108/socket/1744009 new file mode 100644 index 00000000..09394ae2 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1744009 @@ -0,0 +1,43 @@ +socket: 0.942 +device: 0.941 +performance: 0.831 +network: 0.827 +graphic: 0.823 +semantic: 0.754 +vnc: 0.661 +other: 0.629 +permissions: 0.583 +PID: 0.560 +debug: 0.522 +files: 0.432 +boot: 0.338 +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/zero-shot/108/socket/1754605 b/results/classifier/zero-shot/108/socket/1754605 new file mode 100644 index 00000000..742453de --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1754605 @@ -0,0 +1,37 @@ +socket: 0.980 +graphic: 0.787 +device: 0.701 +semantic: 0.436 +vnc: 0.396 +PID: 0.385 +network: 0.375 +performance: 0.339 +boot: 0.336 +debug: 0.265 +other: 0.235 +KVM: 0.200 +permissions: 0.186 +files: 0.177 + +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/zero-shot/108/socket/1781280 b/results/classifier/zero-shot/108/socket/1781280 new file mode 100644 index 00000000..e2cab06f --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1781280 @@ -0,0 +1,29 @@ +socket: 0.962 +network: 0.851 +permissions: 0.825 +device: 0.794 +graphic: 0.697 +performance: 0.679 +vnc: 0.627 +PID: 0.511 +boot: 0.498 +files: 0.455 +semantic: 0.444 +other: 0.393 +debug: 0.363 +KVM: 0.340 + +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/zero-shot/108/socket/1837 b/results/classifier/zero-shot/108/socket/1837 new file mode 100644 index 00000000..b727767e --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1837 @@ -0,0 +1,50 @@ +socket: 0.927 +device: 0.713 +network: 0.685 +other: 0.676 +PID: 0.609 +graphic: 0.530 +performance: 0.442 +files: 0.421 +semantic: 0.352 +vnc: 0.301 +boot: 0.279 +debug: 0.185 +KVM: 0.114 +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/zero-shot/108/socket/1837651 b/results/classifier/zero-shot/108/socket/1837651 new file mode 100644 index 00000000..860b6400 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1837651 @@ -0,0 +1,36 @@ +socket: 0.931 +performance: 0.775 +network: 0.766 +graphic: 0.712 +device: 0.659 +vnc: 0.598 +other: 0.597 +PID: 0.444 +permissions: 0.441 +debug: 0.426 +semantic: 0.408 +files: 0.399 +boot: 0.299 +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/zero-shot/108/socket/1861884 b/results/classifier/zero-shot/108/socket/1861884 new file mode 100644 index 00000000..2b87dbb3 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1861884 @@ -0,0 +1,52 @@ +socket: 0.964 +network: 0.883 +other: 0.856 +device: 0.833 +graphic: 0.801 +performance: 0.797 +files: 0.735 +vnc: 0.713 +PID: 0.678 +permissions: 0.677 +semantic: 0.581 +boot: 0.558 +debug: 0.495 +KVM: 0.375 + +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/zero-shot/108/socket/1867601 b/results/classifier/zero-shot/108/socket/1867601 new file mode 100644 index 00000000..f6486f35 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1867601 @@ -0,0 +1,36 @@ +socket: 0.974 +graphic: 0.871 +network: 0.848 +device: 0.786 +performance: 0.754 +other: 0.637 +debug: 0.621 +files: 0.596 +vnc: 0.592 +semantic: 0.516 +PID: 0.515 +permissions: 0.514 +boot: 0.475 +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/zero-shot/108/socket/1886 b/results/classifier/zero-shot/108/socket/1886 new file mode 100644 index 00000000..dfad79cd --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1886 @@ -0,0 +1,32 @@ +socket: 0.931 +device: 0.818 +graphic: 0.746 +semantic: 0.729 +performance: 0.716 +PID: 0.570 +network: 0.532 +vnc: 0.509 +debug: 0.432 +files: 0.393 +permissions: 0.333 +other: 0.322 +boot: 0.267 +KVM: 0.070 + +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/zero-shot/108/socket/1907926 b/results/classifier/zero-shot/108/socket/1907926 new file mode 100644 index 00000000..0bc31655 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1907926 @@ -0,0 +1,53 @@ +socket: 0.921 +device: 0.886 +other: 0.761 +permissions: 0.722 +graphic: 0.652 +network: 0.605 +semantic: 0.580 +performance: 0.514 +debug: 0.511 +files: 0.500 +vnc: 0.480 +PID: 0.384 +boot: 0.378 +KVM: 0.348 + +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/zero-shot/108/socket/1925449 b/results/classifier/zero-shot/108/socket/1925449 new file mode 100644 index 00000000..dac17a0b --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1925449 @@ -0,0 +1,61 @@ +socket: 0.955 +device: 0.889 +vnc: 0.877 +network: 0.848 +PID: 0.831 +performance: 0.757 +permissions: 0.757 +boot: 0.704 +files: 0.673 +graphic: 0.607 +debug: 0.479 +semantic: 0.292 +KVM: 0.291 +other: 0.281 + +Failure building with clang-10 and libssh + +On Fedora 32, configuring with --enable-libssh and building with clang: + +qemu 5.2.94 + + Compilation + host CPU : x86_64 + host endianness : little + C compiler : clang-10 + Host C compiler : clang-10 + + Dependencies + libssh support : YES + +triggers: + +FAILED: libblock.fa.p/block_ssh.c.o +block/ssh.c:349:13: error: 'ssh_is_server_known' is deprecated [-Werror,-Wdeprecated-declarations] + state = ssh_is_server_known(s->session); + ^ +/usr/include/libssh/libssh.h:546:1: note: 'ssh_is_server_known' has been explicitly marked deprecated here +SSH_DEPRECATED LIBSSH_API int ssh_is_server_known(ssh_session session); +^ +/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' +#define SSH_DEPRECATED __attribute__ ((deprecated)) + ^ +block/ssh.c:444:9: error: 'ssh_get_publickey' is deprecated [-Werror,-Wdeprecated-declarations] + r = ssh_get_publickey(s->session, &pubkey); + ^ +/usr/include/libssh/libssh.h:543:1: note: 'ssh_get_publickey' has been explicitly marked deprecated here +SSH_DEPRECATED LIBSSH_API int ssh_get_publickey(ssh_session session, ssh_key *key); +^ +/usr/include/libssh/libssh.h:84:40: note: expanded from macro 'SSH_DEPRECATED' +#define SSH_DEPRECATED __attribute__ ((deprecated)) + ^ +2 errors generated. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'invalid' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/234 + + diff --git a/results/classifier/zero-shot/108/socket/1949 b/results/classifier/zero-shot/108/socket/1949 new file mode 100644 index 00000000..dba6e0d6 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/1949 @@ -0,0 +1,27 @@ +socket: 0.935 +device: 0.862 +PID: 0.768 +network: 0.668 +graphic: 0.646 +permissions: 0.566 +performance: 0.531 +debug: 0.448 +semantic: 0.433 +vnc: 0.401 +KVM: 0.267 +other: 0.250 +boot: 0.222 +files: 0.180 + +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/zero-shot/108/socket/2254 b/results/classifier/zero-shot/108/socket/2254 new file mode 100644 index 00000000..0c102a8a --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2254 @@ -0,0 +1,16 @@ +socket: 0.931 +network: 0.756 +device: 0.657 +vnc: 0.572 +graphic: 0.443 +performance: 0.394 +semantic: 0.376 +other: 0.336 +permissions: 0.328 +debug: 0.294 +PID: 0.211 +boot: 0.195 +KVM: 0.143 +files: 0.127 + +UNCHECKED_FUNC_RES.LIB.STRICT in /io/channel-socket.c diff --git a/results/classifier/zero-shot/108/socket/2292 b/results/classifier/zero-shot/108/socket/2292 new file mode 100644 index 00000000..1b1b031e --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2292 @@ -0,0 +1,34 @@ +socket: 0.956 +performance: 0.877 +device: 0.866 +network: 0.799 +files: 0.781 +vnc: 0.779 +graphic: 0.760 +other: 0.632 +debug: 0.576 +PID: 0.573 +semantic: 0.562 +permissions: 0.562 +boot: 0.413 +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/zero-shot/108/socket/2341 b/results/classifier/zero-shot/108/socket/2341 new file mode 100644 index 00000000..8e0b3b10 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2341 @@ -0,0 +1,47 @@ +socket: 0.928 +graphic: 0.924 +device: 0.907 +performance: 0.905 +other: 0.895 +PID: 0.849 +semantic: 0.809 +debug: 0.780 +permissions: 0.755 +network: 0.692 +files: 0.647 +boot: 0.537 +vnc: 0.489 +KVM: 0.444 + +IVSHMEM device doesn't work for sharing memory with virtiofsd +Description of problem: +Trying to share a folder on the host to the guest with `virtiofsd` using the `ivshmem-plain` device doesn't work (for memory sharing), while using a NUMA node (with `-numa node,memdev=mem`) works just fine. +Steps to reproduce: +1. Install `virtiofsd` +2. Run `/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir=$HOME --cache always` as a regular user (or with another shared directory, it doesn't matter) +3. Run QEMU with the aforementioned command line as a regular user +4. Wait a bit for the OS to load and `virtiofsd` should error out +Additional information: +`virtiofsd` logs: +``` +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process uid as root: -1 +[2024-05-09T19:49:15Z WARN virtiofsd::sandbox] Couldn't set the process gid as root: -1 +[2024-05-09T19:49:15Z INFO virtiofsd] Waiting for vhost-user socket connection... +[2024-05-09T19:49:16Z INFO virtiofsd] Client connected, servicing requests +[2024-05-09T19:49:22Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(ReqHandlerError(Custom { kind: Other, error: MissingMemoryMapping })) +``` + +QEMU logs (after virtiofsd errors out and exits): +``` +qemu: Failed to read msg header. Read -1 instead of 12. Original request 0. +qemu: Failed to write msg. Wrote -1 instead of 20. +qemu: vhost VQ 1 ring restore failed: -22: Invalid argument (22) +qemu: Failed to set msg fds. +qemu: vhost VQ 0 ring restore failed: -22: Invalid argument (22) +qemu: Error starting vhost: 5 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Failed to set msg fds. +qemu: vhost_set_vring_call failed 22 +qemu: Unexpected end-of-file before all data were read +``` diff --git a/results/classifier/zero-shot/108/socket/2584 b/results/classifier/zero-shot/108/socket/2584 new file mode 100644 index 00000000..87186b74 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2584 @@ -0,0 +1,31 @@ +socket: 0.966 +debug: 0.866 +graphic: 0.816 +network: 0.728 +device: 0.684 +performance: 0.592 +semantic: 0.486 +boot: 0.335 +other: 0.321 +vnc: 0.313 +permissions: 0.191 +KVM: 0.185 +PID: 0.179 +files: 0.171 + +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/zero-shot/108/socket/2624 b/results/classifier/zero-shot/108/socket/2624 new file mode 100644 index 00000000..02eb6ff3 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2624 @@ -0,0 +1,54 @@ +socket: 0.988 +device: 0.988 +permissions: 0.951 +debug: 0.934 +files: 0.908 +graphic: 0.896 +performance: 0.894 +boot: 0.842 +other: 0.776 +network: 0.774 +PID: 0.761 +semantic: 0.700 +vnc: 0.649 +KVM: 0.378 + +qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed +Description of problem: +I'm using QEMU (compile from the latest source code) to simulate a tpm2 device with the above command, it just returns an error message: +``` +qemu-system-aarch64: tpm-emulator: TPM result for CMD_INIT: 0x9 operation failed +``` +swtpm start command: +``` +TPMSOCK=/tmp/swtpm-sock$$ +swtpm socket --tpm2 -t -d --tpmstate dir=$PWD/tpm --ctrl type=unixio,path=$TPMSOCK --log level=20 +``` +swtpm version: +``` +TPM emulator version 0.7.3, Copyright (c) 2014-2021 IBM Corp. +``` +Also tried the latest swtpm, encountered the same error. + +swtpm log (0.7.3): +``` +swtpm: Data client disconnected +swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied +swtpm: Error: Could not initialize libtpms. +swtpm: Error: Could not initialize the TPM +swtpm: Data client disconnected +``` + +swtpm log (0.10.0): +``` +swtpm: SWTPM_NVRAM_StoreData: Error (fatal) opening tpm/TMP2-00.permall for write failed, Permission denied +swtpm: SWTPM_NVRAM_Lock_Dir: Could not open lockfile: Permission denied +swtpm: Error: Could not initialize the TPM +swtpm: Data client disconnected +``` + +Any clues about this error? Best regrads. +Steps to reproduce: +Refer to [Description of problem](#description-of-problem) +Additional information: + diff --git a/results/classifier/zero-shot/108/socket/2876 b/results/classifier/zero-shot/108/socket/2876 new file mode 100644 index 00000000..0c39d355 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/2876 @@ -0,0 +1,29 @@ +socket: 0.951 +graphic: 0.932 +device: 0.929 +network: 0.895 +vnc: 0.843 +PID: 0.731 +boot: 0.661 +debug: 0.647 +KVM: 0.596 +permissions: 0.581 +semantic: 0.464 +performance: 0.418 +other: 0.219 +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/zero-shot/108/socket/347 b/results/classifier/zero-shot/108/socket/347 new file mode 100644 index 00000000..32bc80a5 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/347 @@ -0,0 +1,16 @@ +socket: 0.961 +network: 0.960 +device: 0.798 +performance: 0.680 +vnc: 0.600 +boot: 0.549 +PID: 0.535 +other: 0.524 +graphic: 0.487 +semantic: 0.450 +KVM: 0.343 +permissions: 0.267 +debug: 0.204 +files: 0.127 + +Forward host UNIX socket to guest TCP port diff --git a/results/classifier/zero-shot/108/socket/833 b/results/classifier/zero-shot/108/socket/833 new file mode 100644 index 00000000..f440c9a0 --- /dev/null +++ b/results/classifier/zero-shot/108/socket/833 @@ -0,0 +1,57 @@ +socket: 0.983 +network: 0.942 +performance: 0.924 +device: 0.914 +graphic: 0.863 +PID: 0.818 +files: 0.815 +other: 0.813 +permissions: 0.808 +debug: 0.758 +vnc: 0.742 +boot: 0.674 +semantic: 0.594 +KVM: 0.473 + +linux-user: sendmsg fails to send messages without iov +Description of problem: +When run via qemu `sendmsg` fails to send messages which contain a zero length `iov` but _do_ contain ancillary data. This works fine on plain Linux. + +A practical example: the `ell` library relies on this for setting the IV on a kernel crypto (`AF_ALG`) socket: https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c#n526 + +A message without data but only ancillary data is used to set the IV. +Steps to reproduce: +See [qemu_ancillary.c](/uploads/84ee20aa3b9178022847d6cd7fcf0048/qemu_ancillary.c) for a self contained testcase which sends two mesages (one with `msg_iovlen=0`, one with `msg_iovlen=1`). + +(Test case is to be considered GPL, as I've copied bits from `ell`) + +Native: +``` +$ strace -esendmsg ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=NULL, msg_iovlen=0, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 0 +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + + +Qemu (observe missing sendmsg call): +``` +$ strace -esendmsg ~/debug/qemu/build/qemu-x86_64 ./a.out +sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=16}], msg_iovlen=1, msg_control=[{cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}], msg_controllen=40, msg_flags=0}, 0) = 16 ++++ exited with 0 +++ +``` + +For a practical reproducer: + +1. Compile and run `ell`'s `test-cipher` test case: + +``` +$ ~/debug/qemu/build/qemu-x86_64 ./unit/test-cipher +TEST: unsupported +TEST: aes +TEST: aes_ctr +test-cipher: unit/test-cipher.c:102: test_aes_ctr: Assertion `!r' failed. +Aborted (core dumped) +``` + +A strace will look similar. |