diff options
Diffstat (limited to 'results/classifier/zero-shot/108/KVM')
63 files changed, 3946 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/KVM/1002 b/results/classifier/zero-shot/108/KVM/1002 new file mode 100644 index 00000000..e3a99b60 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1002 @@ -0,0 +1,16 @@ +KVM: 0.953 +performance: 0.824 +device: 0.785 +network: 0.681 +debug: 0.633 +graphic: 0.617 +socket: 0.304 +boot: 0.227 +semantic: 0.164 +files: 0.160 +permissions: 0.117 +PID: 0.113 +vnc: 0.067 +other: 0.017 + +qemu-system-aarch64: Synchronous Exception with smp > 1 (on M1 running Asahi Linux with KVM) diff --git a/results/classifier/zero-shot/108/KVM/1009 b/results/classifier/zero-shot/108/KVM/1009 new file mode 100644 index 00000000..777c56d5 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1009 @@ -0,0 +1,38 @@ +KVM: 0.990 +network: 0.984 +graphic: 0.959 +performance: 0.951 +PID: 0.892 +device: 0.888 +debug: 0.839 +boot: 0.824 +semantic: 0.814 +permissions: 0.781 +socket: 0.760 +vnc: 0.759 +files: 0.751 +other: 0.704 + +Nested KVM Networking Issue (OpenStack) +Description of problem: +Hi, + +Inside openstack i have an instance of Ubuntu 20.04 and i have installed KVM ( using virt-manager ) to setup a Virtual Machine ... i have done that and i created a VM of ubuntu 20.04 inside the Openstack Instance but there are networking issue while i set the default parameter as setting up the VM ( i mean the networking is as default to NAT ) , So when the VM is up and running the PING to 8.8.8.8 is available and also ping to google.com is also valid which shows that the DNS is correctly working ... but there is not connectivity with packages while i do sudo apt update, it will not get any package update and also the wget to google.com is shows that its connected to it but it wont able to download!!! the same happen with curl to any other websites... + + +I'm confirming that the openstack instance has full access to the internet including ping and wget , .... but the VM is not working correctly! + +P.S. I have set the ip forwarding, Iptables , ... also disabled firewals but notting changed!! + + +Would you please fix this ? +Steps to reproduce: +1. creating an openstack instance from ubuntu 20.04 server image +2. updating and upgrading packages setting ip forwarding to 1 ( Enabled), firewall +3. and kernel to 5.13.0.40 and installing virt-manager then reboot +3. creating a VM with default KVM networking ( NAT ) using ubuntu 20.04 server image +4. trying ping, wget, curl , ... + + +Thanks +Best regards diff --git a/results/classifier/zero-shot/108/KVM/1035 b/results/classifier/zero-shot/108/KVM/1035 new file mode 100644 index 00000000..c38d30a3 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1035 @@ -0,0 +1,31 @@ +KVM: 0.969 +other: 0.930 +device: 0.837 +graphic: 0.800 +network: 0.713 +PID: 0.667 +performance: 0.610 +permissions: 0.601 +files: 0.557 +semantic: 0.546 +debug: 0.514 +boot: 0.427 +socket: 0.372 +vnc: 0.318 + +Hyper-V on KVM does not work on AMD CPUs +Description of problem: +Can not enable hytper-v on KVM on AMD 3970x +``` +[ 3743.647780] SVM: kvm [17094]: vcpu0, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.014046] SVM: kvm [17094]: vcpu1, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.016101] SVM: kvm [17094]: vcpu2, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.018011] SVM: kvm [17094]: vcpu3, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.020032] SVM: kvm [17094]: vcpu4, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.021834] SVM: kvm [17094]: vcpu5, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.023644] SVM: kvm [17094]: vcpu6, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +[ 3744.025478] SVM: kvm [17094]: vcpu7, guest rIP: 0xfffff8125288d7d7 unimplemented wrmsr: 0xc0010115 data 0x0 +``` +Additional information: +Related issue: +https://bugzilla.kernel.org/show_bug.cgi?id=203477 diff --git a/results/classifier/zero-shot/108/KVM/1073952 b/results/classifier/zero-shot/108/KVM/1073952 new file mode 100644 index 00000000..b231659f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1073952 @@ -0,0 +1,49 @@ +KVM: 0.943 +device: 0.893 +performance: 0.807 +files: 0.767 +graphic: 0.675 +vnc: 0.663 +boot: 0.652 +semantic: 0.617 +network: 0.550 +socket: 0.485 +other: 0.475 +debug: 0.419 +PID: 0.404 +permissions: 0.359 + +data sent to serial interface gets truncated after 64kb + +When sending more than 64kb of data to the serial interface in a short timespan, the data seems to disappear. + +I tested it with the latest release (qemu-kvm-1.2.0-rc2.tar.gz) where the bug still occurs. I stumbled upon it when I upraged my qemu version. The bug did not occur in the last version i had (0.12.5). + +You can reproduce it as follows: + +1. Start a dd or cat command in one terminal and pipe the output to a netcat. The testfile has to be larger than 64kb. I used one that had 93kb and did contain only ascii text. + + $ dd if=<TESTFILE> | nc -l 127.0.0.1 65432 + or + $ cat <TESTFILE> | nc -l 127.0.0.1 65432 + +2. Start a qemu and let the first serial port connect to the listening netcat. I suppose that the testsystem can be any system that does not read from the serial port on its own (e.g. during boot process). I used a self compiled minimal linux. + + $ qemu -cdrom <TESTSYSTEM> -serial tcp:127.0.0.1:65432 + +3. When the testsystem is booted, read from the serial device and write it to a file. + + $ dd if=/dev/ttyS0 of=/tmp/testFile + or + $ cat /dev/ttyS0 > /tmp/testFile + + +The result in almost all of my testruns is, that the /tmp/testFile does only has the size of 64kb. The rest of the data vanished. In some cases the file was slightly bigger (65kb or 67kb) but allways under 70kb. The complete file (93kb) was not trasmitted in any of the runs. + +I hope my explanation is exactly enough for you to reproduce it. + +Triaging old bug tickets ... can you still reproduce this issue with the +latest version of QEMU (version 2.9)? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/110 b/results/classifier/zero-shot/108/KVM/110 new file mode 100644 index 00000000..48e3a59c --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/110 @@ -0,0 +1,16 @@ +KVM: 0.996 +device: 0.910 +network: 0.763 +performance: 0.706 +other: 0.475 +debug: 0.435 +PID: 0.434 +graphic: 0.382 +boot: 0.331 +semantic: 0.301 +socket: 0.260 +permissions: 0.250 +vnc: 0.245 +files: 0.171 + +KVM guest VM does not reattach a throughpassed USB printer from Host after switching printer off and on diff --git a/results/classifier/zero-shot/108/KVM/1136 b/results/classifier/zero-shot/108/KVM/1136 new file mode 100644 index 00000000..3a0eaa9a --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1136 @@ -0,0 +1,16 @@ +KVM: 0.995 +device: 0.754 +performance: 0.687 +network: 0.667 +graphic: 0.442 +files: 0.417 +debug: 0.412 +semantic: 0.275 +boot: 0.271 +permissions: 0.249 +vnc: 0.233 +PID: 0.211 +socket: 0.146 +other: 0.143 + +qemu-system-ppc64: KVM HPT guest sometimes fails to migrate diff --git a/results/classifier/zero-shot/108/KVM/1156632 b/results/classifier/zero-shot/108/KVM/1156632 new file mode 100644 index 00000000..2dcf80f8 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1156632 @@ -0,0 +1,51 @@ +KVM: 0.966 +socket: 0.940 +performance: 0.830 +device: 0.806 +semantic: 0.731 +graphic: 0.726 +debug: 0.726 +other: 0.693 +network: 0.541 +permissions: 0.426 +vnc: 0.391 +boot: 0.326 +PID: 0.310 +files: 0.195 + +not receiving RESET event after system_reset command causes QMP connection to die + +I have written my own implementation to control machine running KVM instances with the QMP protocol. Its a pretty basic implementation that sends/receives in the same thread. This means that all of the events QEMU sents are received only when the application expects a reply from a command. In the following scenario, i'm unable to (re)connect to the QMP socket from QEMU after I closed the connection: + +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) close socket +7) Connect to socket -> connection refused + +However, in the following scenario, I am able to connect after I disconnect the socket because I have read the two RESET events: +1) Connect to QMP +2) Sent qmp_capabilities +3) Receive reply +4) Send system_reset +5) Receive reply +6) Receive reply (is a RESET event) +7) Receive reply (is a RESET event) +8) close socket +9) Connect to socket -> ok + +I don't know if this is a bug or expected behavior. I can't find any proper way to disconnect the socket documentated. Am I doïng something wrong, or is this a bug in the QMP implementation of QEMU? + +For what its worth, i'm using Ubuntu 12.10: +kvm --version +QEMU emulator version 1.2.0 (qemu-kvm-1.2.0+noroms-0ubuntu2.12.10.3, Debian), Copyright (c) 2003-2008 Fabrice Bellard + + +Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +I'm not sure, the current implementation is multi-threaded so I won't hit this bug if its still present. If I can find the time I will make a proof of concept and test if the bug is still present. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1201447 b/results/classifier/zero-shot/108/KVM/1201447 new file mode 100644 index 00000000..0d825000 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1201447 @@ -0,0 +1,43 @@ +KVM: 0.978 +device: 0.922 +files: 0.915 +other: 0.873 +performance: 0.726 +PID: 0.685 +graphic: 0.669 +semantic: 0.630 +permissions: 0.537 +socket: 0.536 +network: 0.462 +vnc: 0.459 +boot: 0.446 +debug: 0.312 + +Blue screen when disk uses cache='writeback' + +I am running Windows 2008R2 as KVM guest on Ubuntu 12.04 hypervisor. Disk controller and network card are virtio devices with drivers from https://launchpad.net/kvm-guest-drivers-windows/+download (virtio-win-drivers-20120712-1.iso). +Everything worked fine until I changed disk controller cache from the default (writethrough) to writeback. This introduced occasional blue screens. I noticed that they are linked to high disk IO. For example restoring over 1GB of backup files will results in a blue screen on around 4 out of 5 attempts. Also Windows update crashes the system sometimes. When idle the system will run fine for hours or sometimes even days. +After removing cache='writeback' from the config everything came back to normal. + +qemu-kvm: + Installed: 1.0+noroms-0ubuntu14.8 + Candidate: 1.0+noroms-0ubuntu14.8 + Version table: + *** 1.0+noroms-0ubuntu14.8 0 + 500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages + 100 /var/lib/dpkg/status + 1.0+noroms-0ubuntu14.7 0 + 500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages + 1.0+noroms-0ubuntu13 0 + 500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages + + + +Hi Jacek, +I haven't seen other writeback related crashes and the info so far isn't enough to debug anything. + +Did you get any related host logs on the crashes. +In dmesg or the guest log in /var/log/libvirt/qemu/<guestname>.log? + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1268596 b/results/classifier/zero-shot/108/KVM/1268596 new file mode 100644 index 00000000..1d89eba7 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1268596 @@ -0,0 +1,68 @@ +KVM: 0.972 +vnc: 0.960 +other: 0.955 +PID: 0.950 +device: 0.944 +performance: 0.939 +graphic: 0.938 +files: 0.937 +semantic: 0.929 +socket: 0.893 +network: 0.882 +permissions: 0.879 +debug: 0.869 +boot: 0.864 + +Compilation Error: hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function + +Qemu git-cloned from mo. 13.01.14 (ca. 13:00 GMT), Version 1.7.50 + + +#git clone git://git.qemu-project.org/qemu.git +# cd qemu; git submodule update --init dtc +#./configure --disable-xen --enable-kvm +...No Errors... + +#CC="ccache gcc" make -j8 +.... + GEN qemu.1 + Signing optionrom/kvmvapic.bin + GEN qemu-img.1 + CC qapi-types.o +hw/virtio/dataplane/vring.c: In function ‘vring_pop’: +hw/virtio/dataplane/vring.c:400:5: error: ‘ret’ may be used uninitialised in this function [-Werror=uninitialized] +cc1: all warnings being treated as errors +make: *** [hw/virtio/dataplane/vring.o] Error 1 +make: *** Waiting for unfinished jobs.... + + +Thx. + + + +What compiler is this? The variable is quite obviously initialized before that line. + +On 13 January 2014 14:40, Paolo Bonzini <email address hidden> wrote: +> What compiler is this? The variable is quite obviously initialized +> before that line. + +The issue is that one of the code paths has a shadowing declaration +of 'ret' which is what gets assigned to, and so in that code path +the compiler is correct that the outer 'ret' is not assigned to. + +Stefan said he was going to send out a fix for this. + +thanks +-- PMM + + +A fix has been posted to the mailing list and will soon be merged into qemu.git: + +http://thread.gmane.org/gmane.comp.emulators.qemu/250657 + +Thanks a lot. + +Fix had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=385c04d0b66917457b6 +... thus marking this ticked as fixed. + diff --git a/results/classifier/zero-shot/108/KVM/1312668 b/results/classifier/zero-shot/108/KVM/1312668 new file mode 100644 index 00000000..6ce393a6 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1312668 @@ -0,0 +1,73 @@ +KVM: 0.936 +performance: 0.915 +device: 0.908 +graphic: 0.873 +socket: 0.829 +files: 0.813 +boot: 0.807 +PID: 0.787 +vnc: 0.756 +permissions: 0.693 +other: 0.677 +debug: 0.668 +network: 0.638 +semantic: 0.623 + +x86 cpu nx feature: guest reboots after migrate exec + +Using instruction on +http://www.linux-kvm.org/page/Migration +I save VM state to external file and try load it, but VM starts, shows saved screen and reboots immediatly. + +Cmdline for vm state saving: + +$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm -m 512 -hda image.raw -vga std -net none -M pc -monitor stdio -cpu SandyBridge +(or -cpu "n270" , or "kvm32,+sse2,+pae,+nx") + +Monitor cmd: +(qemu) stop +(qemu) migrate_set_speed 4095m +(qemu) migrate "exec:gzip -c > STATEFILE.gz" +(qemu) q + +Cmdline for vm state loading: + +$ sudo ./i386-softmmu/qemu-system-i386 -machine accel=kvm,kernel_irqchip=on -enable-kvm -m 512 -hda image.raw -vga std -net none -M pc -monitor stdio -cpu SandyBridge -incoming "exec: gzip -c -d STATEFILE.gz" +(or -cpu "n270" , or "kvm32,+sse2,+pae,+nx") + +If I do the same without NX cpu feature (-cpu option "n270,-nx" / "SandyBridge,-nx" / "kvm32,+pae,+sse2") or on qemu-system-x86_64, VM save/load works correctly. + +Log kvm-all.c, DEBUG_KVM=y: + +QEMU 2.0.0 monitor - type 'help' for more information +(qemu) kvm_init_vcpu +...handle_io.../...handle_mmio... +kvm_cpu_exec() +shutdown +kvm_cpu_exec() +interrupt exit requested +io window exit +kvm_cpu_exec() + +Host: + + $ lsb_release -rd + Description: Ubuntu 12.04.4 LTS + Release: 12.04 + + $ uname -a + Linux <username> 3.8.0-38-generic #56~precise1 SMP Tue Apr 22 12:46:44 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux + +Guest: + 1. Ubuntu 12.04 32bit + 2. WIndows 8 32bit + +Qemu: v2.0.0 +commit a9e8aeb3755bccb7b51174adcf4a3fc427e0d147 +Author: Peter Maydell <email address hidden> +Date: Thu Apr 17 13:41:45 2014 +0100 + +Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1344 b/results/classifier/zero-shot/108/KVM/1344 new file mode 100644 index 00000000..f5edbaad --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1344 @@ -0,0 +1,16 @@ +KVM: 0.977 +debug: 0.682 +device: 0.674 +graphic: 0.650 +semantic: 0.648 +other: 0.528 +boot: 0.393 +performance: 0.348 +permissions: 0.248 +PID: 0.193 +vnc: 0.147 +network: 0.119 +files: 0.027 +socket: 0.025 + +custom kernel give me KVM internal error. Suberror: 4 diff --git a/results/classifier/zero-shot/108/KVM/1353149 b/results/classifier/zero-shot/108/KVM/1353149 new file mode 100644 index 00000000..17b5e743 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1353149 @@ -0,0 +1,54 @@ +KVM: 0.969 +performance: 0.918 +socket: 0.898 +semantic: 0.896 +other: 0.745 +PID: 0.711 +graphic: 0.680 +debug: 0.665 +device: 0.657 +permissions: 0.597 +vnc: 0.563 +boot: 0.553 +files: 0.532 +network: 0.515 + +qemu 2.1.0 fails to start if number of cores is greater than 1. + +qemu (kvm) 2.1.0 (built from sources) fails to start if number of cores is greater than 1. + +relevant part of commandline arguments: + +/usr/bin/qemu-system-x86_64 -name test3 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Westmere -m 4096 -realtime mlock=off -smp 1,maxcpus=4,sockets=1,cores=4,threads=1 + +the error reported is: + +qemu-system-x86_64: /home/asavah/pkgbuild/qemu-2.1.0/hw/i386/smbios.c:825: smbios_get_tables: Assertion `smbios_smp_sockets >= 1' failed. +2014-08-05 21:45:35.825+0000: shutting down + +however setting 4 sockets with 1 core each allows me to start the machine just fine. + +the system is debian wheezy +Linux hostname 3.16.0-hostname2 #2 SMP Mon Aug 4 17:02:16 EEST 2014 x86_64 GNU/Linux + +libvirt 1.2.7 (built from sources) + +-smp 1,maxcpus=4,sockets=1,cores=4,threads=1 + +should be + +-smp 4,maxcpus=4,sockets=1,cores=4,threads=1 + +although more human-friendly error is more appropriate there (better than a silent fallback to either 1- or 4- core topology) + +I forgot to mention that VM was created and managed remotely via virt-manager 0.9.5 from another host. +I used custom cpu topology. + +however this config worked fine on qemu 2.0.0 with virt-manager 0.9.5 + +just tried virt-manager 1.0.1 - it creates the proper argument -smp 4,maxcpus=4,sockets=1,cores=4,threads=1 + +so this was a virt-manager bug already fixed upstream. + +this bug can be closed :) + diff --git a/results/classifier/zero-shot/108/KVM/1398 b/results/classifier/zero-shot/108/KVM/1398 new file mode 100644 index 00000000..5ada005e --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1398 @@ -0,0 +1,21 @@ +KVM: 0.979 +device: 0.901 +graphic: 0.696 +boot: 0.519 +debug: 0.479 +semantic: 0.402 +PID: 0.380 +permissions: 0.366 +vnc: 0.252 +other: 0.207 +socket: 0.164 +performance: 0.158 +files: 0.089 +network: 0.052 + +Kernel Fault in primary space mode while using user ASCE emulating s390x with AlmaLinux release 9.1 (Lime Lynx) +Description of problem: +Happens twice during startup, however the system keeps running. +Steps to reproduce: +1. Install Alma Linux s390x on in KVM on x86_64 +2. Start KVM diff --git a/results/classifier/zero-shot/108/KVM/1441443 b/results/classifier/zero-shot/108/KVM/1441443 new file mode 100644 index 00000000..47e952ad --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1441443 @@ -0,0 +1,55 @@ +KVM: 0.988 +network: 0.963 +device: 0.936 +performance: 0.878 +socket: 0.809 +other: 0.761 +graphic: 0.690 +vnc: 0.644 +semantic: 0.626 +PID: 0.626 +permissions: 0.599 +boot: 0.563 +files: 0.365 +debug: 0.307 + +Is there a way to create a 10G network interface for VMs in KVM2.0? + + + +We have installed & configured the KVM 2.0 (qemu-kvm 2.0.0+dfsg-2ubuntu1.10) on Ubuntu 14.04. The physical server is connected to 10G network, KVM is configured in Bridged mode But the issue is, when we create Network interface on VMs, we have only 1G device as an options for vmhosts. Is this the limit of the KVM or is there a way to create a 10G network interface for VMs? Available device models + +E1000 +Ne2k_pci +Pcnet +Rtl8139 +virtio + +Please find the network configuration details + +Source device : Host device vnet1 (Bridge ‘br0’) +Device model : virtio + +Network configuration in the host /etc/network/interfaces + +auto br0 +iface br0 inet static + address 10.221.x.10 + netmask 255.255.255.0 + network 10.221.x.0 + broadcast 10.221.x.255 + gateway 10.221.x.1 + # dns-* options are implemented by the resolvconf package, if installed + dns-nameservers X.X.X.X + dns-search XXX.NET + bridge_ports em1 + bridge_fd 0 + bridge_stp off + bridge_maxwait 0 + +Looking through old bug tickets ... have you already tried to use vhost-net? That should be one of the fastest ways of networking with QEMU as far as I know... + +Unless you are using SRIOV or DPDK which both need hardware support. If could support SRIOV, then using IOMMU+VFIO, and pass-through to VM, this will get a close number. Or DPDK, using a user-space driver + vhost-net, will also get a pretty good value. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1529187 b/results/classifier/zero-shot/108/KVM/1529187 new file mode 100644 index 00000000..0731dc06 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1529187 @@ -0,0 +1,58 @@ +KVM: 0.945 +semantic: 0.944 +device: 0.931 +graphic: 0.928 +performance: 0.907 +other: 0.887 +debug: 0.879 +PID: 0.874 +files: 0.871 +permissions: 0.869 +network: 0.858 +socket: 0.815 +vnc: 0.787 +boot: 0.691 + +vfio passtrhough fails at 'No available IOMMU models' on Intel BDW-EP platform + +Environment: + ------------ + Host OS (ia32/ia32e/IA64): ia32e + Guest OS (ia32/ia32e/IA64): ia32e + Guest OS Type (Linux/Windows): linux + kvm.git Commit: da3f7ca3 + qemu.git Commit: 38a762fe + Host Kernel Version: 4.4.0-rc2 + Hardware: BDW EP (Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz, Grantley-EP) + +Bug description: + -------------------------- + when create guest with vt-d assignment using vfio-pci driver, the guest can not be created. +Warning 'No available IOMMU models' + + +Reproduce steps: + ---------------- + 1. bind device to vfio-pci driver + 2. qemu-system-x86_64 -enable-kvm -m 512 -smp 2 -device vfio-pci,host=81:00.0 -net none -drive file=rhel7u2.qcow2,if=none,id=virtio-disk0 -device virtio-blk-pci,drive=virtio-disk0 + +Current result: + ---------------- + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: No available IOMMU models + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to setup container for group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: vfio: failed to get group 41 + qemu-system-x86_64: -device vfio-pci,host=81:00.0: Device initialization failed + +Expected result: + ---------------- + guest can be created +Basic root-causing log: + ---------------------- + + + + +You've somehow managed to not load the vfio_iommu_type1 module. The vfio module will request it when loading, if the module is not available when loading, such as from an initramfs that does not include the full set of vfio modules, it will need to be loaded later manually. + +You're right. After I manually load vfio_iommu_type1, the error is gone. + diff --git a/results/classifier/zero-shot/108/KVM/1545 b/results/classifier/zero-shot/108/KVM/1545 new file mode 100644 index 00000000..e8e19075 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1545 @@ -0,0 +1,24 @@ +KVM: 0.990 +device: 0.797 +network: 0.733 +socket: 0.665 +graphic: 0.641 +vnc: 0.460 +boot: 0.449 +semantic: 0.422 +debug: 0.413 +PID: 0.293 +files: 0.245 +permissions: 0.195 +performance: 0.168 +other: 0.139 + +SSL is out of date on website +Description of problem: +The Linux KVM website is running an out of date SSL certificate. +Steps to reproduce: +1. visit the website. https://www.linux-kvm.org/page/Main_Page +2. +3. +Additional information: + diff --git a/results/classifier/zero-shot/108/KVM/1553999 b/results/classifier/zero-shot/108/KVM/1553999 new file mode 100644 index 00000000..5b6d5174 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1553999 @@ -0,0 +1,42 @@ +KVM: 0.971 +graphic: 0.839 +device: 0.818 +semantic: 0.803 +other: 0.787 +performance: 0.735 +PID: 0.714 +boot: 0.597 +network: 0.571 +debug: 0.569 +permissions: 0.564 +socket: 0.546 +files: 0.541 +vnc: 0.516 + +OpenGL support is disabled + +$ qemu-system-x86_64 -enable-kvm -display sdl,gl=on -vga qxl +SDL1 display code has no opengl support. +Please recompile qemu with SDL2, using +./configure --enable-sdl --with-sdlabi=2.0 +qemu-system-x86_64: OpenGL support is disabled + + +Can you please recompile qemu with support for opengl. The -display mode allows for opengl support. + +This feature allows for the guest OS to have opengl 2 support, that is require for several 3d applications. +It also opens the way for supporting acceleration on windows and Linux guest systems. + +Since you're talking about a pre-compiled binary, I assume you wanted to open this bug against Ubuntu's QEMU package, not against the QEMU project? + +Looks like that this bug is duplicate of https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1540692 + +Isn't it? + +Status changed to 'Confirmed' because the bug affects multiple users. + +Opengl in general as requested was enabled and backported up to Bionic (18.04). + +There are several usability enhancements to use that with either mdev passthrough and virtgl which I work on upstream and are going into Disco (19.04). + + diff --git a/results/classifier/zero-shot/108/KVM/1559 b/results/classifier/zero-shot/108/KVM/1559 new file mode 100644 index 00000000..23e55545 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1559 @@ -0,0 +1,22 @@ +KVM: 0.995 +boot: 0.981 +graphic: 0.863 +device: 0.838 +performance: 0.758 +semantic: 0.675 +debug: 0.598 +other: 0.529 +vnc: 0.288 +PID: 0.227 +socket: 0.128 +files: 0.049 +network: 0.048 +permissions: 0.006 + +7.2 (regression?): ppc64 KVM-HV hangs during boot +Description of problem: +qemu 7.2.0 hangs at " * Mounting ZFS filesystem(s) ..." whereas 7.1.0 would fully boot. + +Without -smp, sometimes gets further and hangs later on at " * Seeding random number generator ..." +Additional information: +7.1.0 used to work before upgrading to 7.2.0, but would hang randomly after booting (usually during my benchmark). Not sure if related. Unfortunately, after downgrading back to 7.1.0, it also now hangs the same way as 7.2.0 does. diff --git a/results/classifier/zero-shot/108/KVM/1579645 b/results/classifier/zero-shot/108/KVM/1579645 new file mode 100644 index 00000000..8e337ac9 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1579645 @@ -0,0 +1,33 @@ +KVM: 0.952 +graphic: 0.948 +boot: 0.912 +device: 0.732 +semantic: 0.716 +performance: 0.711 +network: 0.639 +files: 0.635 +other: 0.623 +PID: 0.622 +permissions: 0.585 +debug: 0.525 +vnc: 0.491 +socket: 0.409 + + [XEN/KVM] pch audio doesn't work on both Windows and linux guest with soundhw="ac97" + +Environment: + +when try to boot a guest by qemu with parameter "-soundhw ac97", it showed like below: +"audio: Could no init “oss” audio driver.", +then login the guest and try run audio, no sound output. +Reproduce: +1. kvm: qemu-system-x86_64 -enable-kvm -m 2048 -smp 4 -net nic,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -soundhw ac97 -hda [target.img] + xen: add the audio device in guest configure file by soundhw="ac97", xl create $guest-configure +2. it will show "audio: Could no init “oss” audio driver". +3. login in guest, it can detect audio device, but actually it is not working. + +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/KVM/1583 b/results/classifier/zero-shot/108/KVM/1583 new file mode 100644 index 00000000..e4bdf033 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1583 @@ -0,0 +1,34 @@ +KVM: 0.996 +device: 0.949 +graphic: 0.927 +files: 0.851 +vnc: 0.722 +semantic: 0.683 +other: 0.673 +socket: 0.655 +PID: 0.644 +boot: 0.639 +network: 0.627 +permissions: 0.625 +debug: 0.570 +performance: 0.540 + +SGX Device mapping is not listed into QEMU KVM +Description of problem: +I want to run SGX into QEMU VM, the vm is up and running but SGX device mappings are not listed there. I also looked in dmesg | grep sgx and it returned "There are zero epc section" + +I have upgraded the libvirt to 8.6.0 because of below issue +https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1982896 + +I tried with libvirt-8.0.0 but it did not help + +I have attached the xml, please let me know why sgx mappings are not showing inside VM +Steps to reproduce: +1. Create a Ubuntu 20.04 VM with SGX mapping +Additional information: +Please let me know if any other logs are required + + + + +[ubuntu20.04.xml](/uploads/2609abc31db08e04cc3e3dbf923cd8d7/ubuntu20.04.xml) diff --git a/results/classifier/zero-shot/108/KVM/1642011 b/results/classifier/zero-shot/108/KVM/1642011 new file mode 100644 index 00000000..d1b1fdb2 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1642011 @@ -0,0 +1,38 @@ +KVM: 0.955 +PID: 0.940 +device: 0.930 +network: 0.900 +graphic: 0.883 +socket: 0.856 +vnc: 0.782 +files: 0.782 +semantic: 0.772 +performance: 0.754 +permissions: 0.749 +debug: 0.728 +other: 0.637 +boot: 0.588 + +Mouse wheel events not forwarded to guest using GTK display + +Using QEMU 2.7.0 with KVM enabled, when I launch the guest without options (using the default of gtk), the mouse wheel events are not propagated to the guest. + +When I start qemu using -display sdk, mouse wheel events are properly forwarded. + +I can determine that the guest is not receiving mouse wheel events by doing cat /dev/input/by-id/usb-QEMU_QEMU_USB_Mouse_42-event-mouse. When I scroll the wheel, no output is printed to the screen. + +The guest is ChromiumOS. + +The command line is: + +qemu-system-x86_64 -enable-kvm -m 2G -smp 4 -vga cirrus -usbdevice mouse -pidfile /tmp/kvm.pid -chardev pipe,id=control_pipe,path=/tmp/kvm.pipe -serial file:/tmp/kvm.serial -mon chardev=control_pipe -net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:9222-:22 -drive file=chromiumos/src/build/images/amd64-generic/latest/chromiumos_qemu_image.bin,index=0,media=disk,cache=unsafe + +(Most of that invocation sets up Linux fifos for various and nefarious purposes and can be profitably ignored). + +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 all 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". 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/KVM/1682128 b/results/classifier/zero-shot/108/KVM/1682128 new file mode 100644 index 00000000..7f8671cf --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1682128 @@ -0,0 +1,21 @@ +KVM: 0.984 +graphic: 0.893 +device: 0.853 +other: 0.798 +semantic: 0.745 +performance: 0.734 +socket: 0.527 +boot: 0.512 +permissions: 0.441 +debug: 0.364 +network: 0.334 +PID: 0.260 +files: 0.184 +vnc: 0.174 + +solaris can't power off + +I have created solaris 10 VM on KVM. Everything in VM is running OK, but finally I use shell command ‘poweroff’ or ‘init 5’, the solaris VM system could’t be poweroff but with promoting me the message: perss any key to reboot ….. + +but on Xen, solaris can be powerofff + diff --git a/results/classifier/zero-shot/108/KVM/1686350 b/results/classifier/zero-shot/108/KVM/1686350 new file mode 100644 index 00000000..9eab9c88 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1686350 @@ -0,0 +1,66 @@ +KVM: 0.927 +performance: 0.572 +device: 0.531 +semantic: 0.500 +graphic: 0.354 +PID: 0.303 +permissions: 0.295 +socket: 0.295 +debug: 0.271 +network: 0.270 +other: 0.238 +boot: 0.187 +files: 0.144 +vnc: 0.124 + +[KVM] The qemu ‘-cpu’ option not have skylake server cpu model + +Environment: +------------------- +KVM commit/branch: bd17117b/next +Qemu commit/branch: cd1ea508/master +Host OS: RHEL7.3 ia32e +Host Kernel:4.11.0-rc3 +Bug detailed description: +---------------------------------- +In latest qemu commit the qemu still not have skylake server cpu model +Reproduce steps: +------------------------- +[root@skl-2s2 ~]# qemu-system-x86_64 -cpu help +Available CPUs: +x86 486 +x86 Broadwell-noTSX Intel Core Processor (Broadwell, no TSX) +x86 Broadwell Intel Core Processor (Broadwell) +x86 Conroe Intel Celeron_4x0 (Conroe/Merom Class Core 2) +x86 Haswell-noTSX Intel Core Processor (Haswell, no TSX) +x86 Haswell Intel Core Processor (Haswell) +x86 IvyBridge Intel Xeon E3-12xx v2 (Ivy Bridge) +x86 Nehalem Intel Core i7 9xx (Nehalem Class Core i7) +x86 Opteron_G1 AMD Opteron 240 (Gen 1 Class Opteron) +x86 Opteron_G2 AMD Opteron 22xx (Gen 2 Class Opteron) +x86 Opteron_G3 AMD Opteron 23xx (Gen 3 Class Opteron) +x86 Opteron_G4 AMD Opteron 62xx class CPU +x86 Opteron_G5 AMD Opteron 63xx class CPU +x86 Penryn Intel Core 2 Duo P9xxx (Penryn Class Core 2) +x86 SandyBridge Intel Xeon E312xx (Sandy Bridge) +x86 Skylake-Client Intel Core Processor (Skylake) +x86 Westmere Westmere E56xx/L56xx/X56xx (Nehalem-C) +x86 athlon QEMU Virtual CPU version 2.5+ +x86 core2duo Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz +x86 coreduo Genuine Intel(R) CPU T2600 @ 2.16GHz +x86 kvm32 Common 32-bit KVM processor +x86 kvm64 Common KVM processor +x86 n270 Intel(R) Atom(TM) CPU N270 @ 1.60GHz +x86 pentium +x86 pentium2 +x86 pentium3 +x86 phenom AMD Phenom(tm) 9550 Quad-Core Processor +x86 qemu32 QEMU Virtual CPU version 2.5+ +x86 qemu64 QEMU Virtual CPU version 2.5+ +x86 base base CPU model type with no features enabled +x86 host KVM processor with all supported host features (only available in KVM mode) +x86 max Enables all features supported by the accelerator in the current host + +The Skylake-Server cpu type was added for either QEMU 3.0 or 3.1, so this bug is fix-released. + + diff --git a/results/classifier/zero-shot/108/KVM/1688 b/results/classifier/zero-shot/108/KVM/1688 new file mode 100644 index 00000000..56b77fbd --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1688 @@ -0,0 +1,48 @@ +KVM: 0.978 +graphic: 0.899 +semantic: 0.835 +device: 0.835 +performance: 0.789 +network: 0.740 +files: 0.706 +socket: 0.684 +PID: 0.678 +vnc: 0.628 +debug: 0.568 +boot: 0.459 +permissions: 0.452 +other: 0.320 + +target/riscv KVM_RISCV_SET_TIMER macro is not configured correctly +Description of problem: +When riscv kvm vm state changed, guest virtual time would stop/continue. But KVM_RISCV_SET_TIMER is wrong, qemu-kvm can only set 'time'. +Steps to reproduce: +1.start host kernel +2.start qemu-kvm +Additional information: +Below code has some probelm: +``` +=================================================================== +#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \ + do { \ + int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), ®); \ + +=================================================================== +``` +I think it should be like this: + +``` +diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c +index 30f21453d6..0c567f668c 100644 +--- a/target/riscv/kvm.c ++++ b/target/riscv/kvm.c +@@ -99,7 +99,7 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, + + #define KVM_RISCV_SET_TIMER(cs, env, name, reg) \ + do { \ +- int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), ®); \ ++ int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, name), ®); \ + if (ret) { \ + abort(); \ + } \ +``` diff --git a/results/classifier/zero-shot/108/KVM/1754038 b/results/classifier/zero-shot/108/KVM/1754038 new file mode 100644 index 00000000..31d60fd9 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1754038 @@ -0,0 +1,356 @@ +KVM: 0.922 +permissions: 0.905 +performance: 0.877 +debug: 0.874 +other: 0.864 +device: 0.855 +graphic: 0.853 +vnc: 0.839 +boot: 0.812 +files: 0.811 +socket: 0.809 +PID: 0.808 +network: 0.792 +semantic: 0.790 + +ARM M: Systick first wrap delayed (qemu-timers/icount prb?) + +When running this kind of code with qemu: + +static void SysTickISR(void) +{ + printf("SysTick\n"); +} + +void main() +{ + volatile int i, j; + printf("setup timer\n"); + *(uint32_t*) 0xE000E014 = 0x8FFFFF; //reload value + *(uint32_t*) 0xE000E018 = 0; //force reload + *(uint32_t*) 0xE000E010 = 7; //cpu clk + ISR + enable + + for (j = 0; j < 0x100; j++) { + for (i = 0; i < 0x100000; i++) + ; + printf("cnt %08x -- %8x\n", *(uint32_t*) 0xE000E018, *(uint32_t*)0xE000E010); + } +} + +I get the following output (comments added after '#'): + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +cnt 00000000 -- 7 <--- problem here, systick should wrap and raise isr +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +SysTick <--- delayed isr occuring here +cnt 000986e0 -- 10007 +SysTick +cnt 00865290 -- 10007 <---- then running fine as long as regs not modified +cnt 00731e51 -- 7 +cnt 005fea27 -- 7 +cnt 004cb5ff -- 7 +cnt 003981d6 -- 7 +cnt 00264dad -- 7 +cnt 00131984 -- 7 +SysTick +cnt 008fe545 -- 10007 +cnt 007cb106 -- 7 +cnt 00697cdd -- 7 +cnt 005648b4 -- 7 +cnt 0043148b -- 7 +cnt 002fe061 -- 7 +cnt 001cac38 -- 7 +cnt 00097810 -- 7 +SysTick +cnt 008643d6 -- 10007 +cnt 00730f97 -- 7 +cnt 005fdb6d -- 7 +cnt 004ca745 -- 7 +cnt 0039731c -- 7 +cnt 00263ef3 -- 7 +cnt 00130aca -- 7 +SysTick +cnt 008fd68b -- 10007 +cnt 007ca24c -- 7 +cnt 00696e23 -- 7 +cnt 005639fa -- 7 +cnt 004305d1 -- 7 +cnt 002fd1a8 -- 7 +cnt 001c9d7f -- 7 +cnt 00096956 -- 7 +SysTick +cnt 0086351d -- 10007 +cnt 007300dd -- 7 +cnt 005fccb4 -- 7 +cnt 004c988c -- 7 +cnt 00396463 -- 7 +cnt 00263039 -- 7 +cnt 0012fc10 -- 7 +[...] + +Command line and version: +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -monitor stdio -serial file:/dev/pts/6 -icount 4 -cpu cortex-m4 +QEMU 2.11.50 + +I am compiling from git repo, head is: +commit f32408f3b472a088467474ab152be3b6285b2d7b +Author: Daniel P. Berrangé <email address hidden> +Date: Tue Mar 6 13:43:17 2018 +0000 + +Config options: +./configure --target-list=arm-softmmu --enable-debug --disable-slirp --enable-tcg-interpreter --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native + + +Not working with git tag 2.10.0 (almost same config) + +Working with stock qemu-arm 2.5.0 from Ubuntu 16.04. + +I started investigating, though I am not familiar with qemu code and I could see that the execution is not geting out of qemu_tcg_rr_cpu_thread_fn() 'while' loop and timers are not triggered because the values in cpu->icount_extra or cpu->icount_budget are not to modified accordingly after the timer is set (host side) when the systick register is written (target side). + +Delay between the counter hitting zero and the ISR firing is architecturally permitted (the interrupt must be recognized in finite time or at a context synchronizing event, but not necessarily at the same 'clock tick' that the counter hits zero). If you want to ensure that an interrupt has been taken before you read the counter value, you need to use an ISB instruction in your loop. + +(There are also some buggy behaviours in our systick device implementation, but in this case I don't think you're running into them.) + + +I tried to insert an ISB in the loop but I get more or less the same result. + +However, I guess from your response that I did not explain the problem well enough. I understand that qemu will not be cycle accurate, however, here, we are not even "one million cycles accurate"! The counter would have the time to wrap twice before qemu is taking into account the first ISR... and if we check the following ISR time, we have a good accuracy, so I still think this is a bug. + +Morever, as said above, if I test with qemu 2.5.0 from Ubuntu package I get an accurate behavior: + +setup timer +cnt 00799997 -- 7 +cnt 0063323b -- 7 +cnt 004ccade -- 7 +cnt 00366383 -- 7 +cnt 001ffc26 -- 7 +cnt 000994ca -- 7 +SysTick +cnt 00832d5e -- 10007 +cnt 006cc5eb -- 7 +cnt 00565e8f -- 7 +cnt 003ff733 -- 7 +cnt 00298fd7 -- 7 +cnt 0013287b -- 7 +SysTick +cnt 008cc108 -- 10007 +cnt 00765996 -- 7 +cnt 005ff239 -- 7 +cnt 00498add -- 7 +cnt 00332381 -- 7 +cnt 001cbc24 -- 7 +cnt 000654c8 -- 7 +SysTick +cnt 007fed5c -- 10007 +cnt 006985ea -- 7 +cnt 00531e8d -- 7 +cnt 003cb731 -- 7 +cnt 00264fd5 -- 7 +cnt 000fe879 -- 7 +SysTick +cnt 0089810c -- 10007 +cnt 0073199a -- 7 +cnt 005cb23d -- 7 +[...] + +So here I would suspect either a regression in the code or a wrong combination of options when I compile it myself. I am trying to recompile version 2.5 myself to sort this out but I am running in other errors. + + + +OK, I will see if I can find some time to investigate this. Can you attach your guest binary, please? + + +Please find the binary attached. + +I have been trying several versions and it looks like the regression occured between v2.8.0 and v2.9.0. + + +Ok I spent more time trying to identify the commits giving problem. + +So before 8d04fb5, qemu is executing the binary as expected: + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +SysTick +cnt 00865f9c -- 10007 +cnt 00732b5c -- 7 +cnt 005ff733 -- 7 +cnt 004cc30a -- 7 +[...] + + +Then, after this commit "tcg: drop global lock during TCG code execution": + +https://git.qemu.org/?p=qemu.git;a=commit;h=8d04fb55dec381bc5105cb47f29d918e579e8cbd + +things start to look bad (but not the same way I first ran into): + +setup timer +SysTick +cnt 00000000 -- 10007 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 008ff3e3 -- 7 +cnt 007cbfba -- 7 +cnt 00698b92 -- 7 +cnt 00565768 -- 7 +cnt 0043233f -- 7 +cnt 002fef16 -- 7 +cnt 001cbaed -- 7 +cnt 000986c5 -- 7 +SysTick +cnt 0086528b -- 10007 +cnt 00731e4c -- 7 +cnt 005fea23 -- 7 +cnt 004cb5fa -- 7 +cnt 003981d1 -- 7 +[...] + +Then, not long after, this commit changes a little bit the prb "icount: process QEMU_CLOCK_VIRTUAL timers in vCPU thread" + +https://git.qemu.org/?p=qemu.git;a=commit;h=6b8f0187a4d7c263e356302f8d308655372a4b5b + +Output then looks like: + +setup timer +cnt 007cccca -- 7 +cnt 006998a2 -- 7 +cnt 00566479 -- 7 +cnt 0043304f -- 7 +cnt 002ffc26 -- 7 +cnt 001cc7fd -- 7 +cnt 000993d5 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +cnt 00000000 -- 7 +SysTick +cnt 000986e0 -- 10007 +SysTick +cnt 00865290 -- 10007 +cnt 00731e51 -- 7 +cnt 005fea27 -- 7 +[...] + +... and it seems this very problem has been occurring up to now. + +I am here using the binary attached, with this command line: + +qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4 + +And with these build options: + +./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-tcmalloc --disable-jemalloc --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-pie --extra-cflags=-mtune=native + +Note that, to prevent MTTCG/icount error, we must modify configure for the arm target with: + + mttcg="no" + + + + +I finally implemented a workaround to correct the problem: + +in cpus.c : qemu_start_warp_timer(), in the "if (deadline > 0) { ... }" part, I added: + + CPUState *cpu; + CPU_FOREACH(cpu) { + atomic_mb_set(&cpu->exit_request, 1); + } + +I do not understand more than 5% of the code I am messing up, so this hack is probably broken... + +Then I tested a bit more the code with different testcases... and I found a new bug when writing a reload value smaller than the current counter (the counter will then read as 0). It is due to this piece of code in armv7m_systick.c : systick_read() : + + /* The interrupt in triggered when the timer reaches zero. + However the counter is not reloaded until the next clock + tick. This is a hack to return zero during the first tick. */ + if (val > s->reload) { + val = 0; + } + +Well this is not really a prb for me with normal code, and it looks like under control, but I can open another bug if needed. + + + +The workaround I described above is actually not the good one, because of this check occurring just before: + + if (!all_cpu_threads_idle()) { + return; + } + +The exit request setting must be done before, so my code looks like this: + + + CPUState *cpu; + CPU_FOREACH(cpu) { + atomic_mb_set(&cpu->exit_request, 1); + } + + if (!all_cpu_threads_idle()) { + return; + } + +(version is v2.11.0-2122-g9fa673c-dirty) + + + + +Thanks for the test case; that was very useful. I've sent a patch which should fix this bug: +https://patchwork.ozlabs.org/patch/895693/ + +The "writing a reload value smaller than the current counter" bug is one of the ones I know about in our systick implementation. I may have time to overhaul that code in the 2.13 timeframe. + + +Hi Peter, + +I just tested your patch, I confirm it is also working on my side. Many thanks. + +Now fixed in master, commit c52e7132d7c885, and will be in 2.12.0. + diff --git a/results/classifier/zero-shot/108/KVM/1778966 b/results/classifier/zero-shot/108/KVM/1778966 new file mode 100644 index 00000000..86d99a54 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1778966 @@ -0,0 +1,51 @@ +KVM: 0.971 +boot: 0.938 +graphic: 0.878 +device: 0.847 +other: 0.842 +files: 0.828 +performance: 0.779 +semantic: 0.676 +PID: 0.624 +permissions: 0.599 +network: 0.578 +debug: 0.457 +socket: 0.389 +vnc: 0.348 + +Windows 1803 and later crashes on KVM + +For a bionic host, using the current public kvm modules, KVM is not capable of booting a WindowsInsider or msdn Windows 1803 iso. In stallign from an ISO from a started windows 2016 guest results in an unbootable and unrepairable guest. + +The hardware is a threadripper 1920x with 32GB of main memory, disk mydigital BPX SSD and WD based 4 column RAID 5 via mdadm. + +This sounds like the same problem we're investigating in Fedora/RHEL land affecting guests with EPYC CPU, or host-passthrough from an EPYC family 17h host. Workaround should be to use "-cpu Opteron_G5" for now + +https://bugzilla.redhat.com/show_bug.cgi?id=1592276 +https://bugzilla.redhat.com/show_bug.cgi?id=1593190 + +Looks like windows is tickling an undocumented MSR and we're trying to find out what this MSR is supposed todo and thus how to handle it in KVM/QEMU + +That is very helpful. I'll try it. + +I standby to try a fix as soon as someone has one. + +Regrettably opteron_g5 is not a workaround. I get a complaint that my cpu doesn't provide xop, fma4, tbm. + +I've tried a number of other cpus including nehalem, phenom and athlon with similar results. + +Opteron didn't work do to some missing features. I was able to get nehalem to come up but that looks like the closest. + +Is there any way to define a new CPU model that isn't EPYC (maybe ryzen?) but is feature compatible with the threadripper? + +I ran into the same problem on threadripper 1900X. I was using cpu type "host-passthough" and it crashed. I fixed the crash by disabling the MSR with + +kvm.ignore_msrs=1 + +as describe in https://forum.level1techs.com/t/windows-10-1803-as-guest-with-qemu-kvm-bsod-under-install/127425/10 + +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/KVM/1821771 b/results/classifier/zero-shot/108/KVM/1821771 new file mode 100644 index 00000000..19dc6687 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1821771 @@ -0,0 +1,105 @@ +KVM: 0.943 +boot: 0.921 +permissions: 0.906 +other: 0.905 +performance: 0.887 +debug: 0.877 +device: 0.873 +files: 0.871 +graphic: 0.866 +semantic: 0.863 +socket: 0.862 +network: 0.860 +vnc: 0.850 +PID: 0.837 + +KVM guest does not reflect numa distances configured through qemu + +KVM guest does not reflect numa distances configured through qemu + +Env: +Host/Guest Kernel: 5.1.0-rc1-g72999bbdc +qemu : 3.1.90 (v2.8.0-rc0-18614-g278aebafa0-dirty) [repo: https://github.com/dgibson/qemu; branch:ppc-for-4.1 ] +# git log -1 +commit 278aebafa02f699857ca082d966bcbc05dc9bffb (HEAD -> ppc-for-4.1) +Author: Jafar Abdi <email address hidden> +Date: Sat Mar 23 17:26:36 2019 +0300 + + tests/libqos: fix usage of bool in pci-spapr.c + + Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. + + FALSE and TRUE (with capital letters) are the constants defined by glib for + being used with the "gboolean" type of glib. But some parts of the code also use + TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). + + Signed-off-by: Jafar Abdi <email address hidden> + Reviewed-by: Eric Blake <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: David Gibson <email address hidden> + +# libvirtd -V +libvirtd (libvirt) 5.1.0 + + + +Steps to reproduce: +1. Boot attached guest xml with predefined numa distance. + +qemu-commandline: +/usr/share/avocado-plugins-vt/bin/install_root/bin/qemu-system-ppc64 -name guest=vm2,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-vm2/master-key.aes -machine pseries-4.0,accel=kvm,usb=off,dump-guest-core=off -m 4096 -realtime mlock=off -smp 4,sockets=1,cores=4,threads=1 -numa node,nodeid=0,cpus=0-1,mem=2048 -numa node,nodeid=1,cpus=2-3,mem=2048 -uuid 1a870f1d-269a-4a8c-84bc-2b5bda72823a -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=28,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -kernel /home/kvmci/linux/vmlinux -append root=/dev/sda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug selinux=0 -device qemu-xhci,id=usb,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -drive file=/var/lib/avocado/data/avocado-vt/images/jeos-27-ppc64le.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:f4:f5:f6,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,id=serial0,reg=0x30000000 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on + + +2. Check numa distance and other details inside guest +# numactl -H +available: 2 nodes (0-1) +node 0 cpus: 0 1 +node 0 size: 2025 MB +node 0 free: 1837 MB +node 1 cpus: 2 3 +node 1 size: 2045 MB +node 1 free: 1646 MB +node distances: +node 0 1 + 0: 10 40 -----------------------------------NOK + 1: 40 10 + +# lsprop /proc/device-tree/cpus/PowerPC\,POWER9\@*/ibm\,associativity +/proc/device-tree/cpus/PowerPC,POWER8@0/ibm,associativity + 00000005 00000000 00000000 00000000 00000000 00000000 +/proc/device-tree/cpus/PowerPC,POWER8@10/ibm,associativity + 00000005 00000000 00000000 00000000 00000001 00000010 +/proc/device-tree/cpus/PowerPC,POWER8@18/ibm,associativity + 00000005 00000000 00000000 00000000 00000001 00000018 +/proc/device-tree/cpus/PowerPC,POWER8@8/ibm,associativity + 00000005 00000000 00000000 00000000 00000000 00000008 + +# lsprop /proc/device-tree/rtas/ibm,associativity-reference-points +/proc/device-tree/rtas/ibm,associativity-reference-points + 00000004 00000004 + +Expected numa distances: +node distances: +node 0 1 + 0: 10 20 + 1: 20 10 + + + +Documentation describing the current qemu behaviour is captured here, https://<email address hidden>/msg726442.html + +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/KVM/1834051 b/results/classifier/zero-shot/108/KVM/1834051 new file mode 100644 index 00000000..3ee5cd37 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1834051 @@ -0,0 +1,42 @@ +KVM: 0.947 +device: 0.656 +performance: 0.650 +other: 0.630 +semantic: 0.627 +graphic: 0.621 +network: 0.578 +socket: 0.552 +permissions: 0.517 +files: 0.496 +debug: 0.495 +vnc: 0.454 +PID: 0.390 +boot: 0.371 + +IRQ2 ignored under KVM when using IOAPIC + +When using KVM, and an OS that supports the IOAPIC, interrupts mapped on IRQ2 (for instance, routing an HPET timer on interrupt 2) will cause the interrupts to never be delivered. This is because QEmu, when setting up the KVM interrupt routes, will not set one up for IRQ2[0]. When running without KVM, IRQ2 is identity-mapped to GSI2. + +My understanding is that IRQs should be identity mapped to their equivalent GSI unless a redirection entry is present in the MADT. This is supported by ACPI 6.2 spec[1], 5.2.12.5 Interrupt Source Override Structure, which claims: "It is assumed that the ISA interrupts will be identity-mapped into the first I/O APIC sources.". + +I stumbled across this while working on my own custom OS, got very confused why the HPET wasn't triggering any interruption - and even more confused why the behavior only happened in KVM and not in non-KVM. + +[0]: https://github.com/qemu/qemu/blob/37560c259d7a0d6aceb96e9d6903ee002f4e5e0c/hw/i386/kvm/ioapic.c#L40 + +[1]: https://uefi.org/sites/default/files/resources/ACPI_6_2.pdf + +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/KVM/1859310 b/results/classifier/zero-shot/108/KVM/1859310 new file mode 100644 index 00000000..3e57f28f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1859310 @@ -0,0 +1,38 @@ +KVM: 0.975 +device: 0.916 +semantic: 0.804 +PID: 0.776 +performance: 0.765 +socket: 0.751 +graphic: 0.745 +permissions: 0.644 +other: 0.613 +network: 0.593 +vnc: 0.542 +files: 0.530 +debug: 0.507 +boot: 0.425 + +libvirt probing fails due to assertion failure with KVM and 'none' machine type + +Using libvirt on Ubuntu 19.10, I get the following error when I try to set <emulator> to the latest qemu from git (commit dc65a5bdc9): + + error: internal error: Failed to start QEMU binary /usr/local/bin/qemu-system-x86_64 for probing: /home/joey/git/qemu/target/i386/kvm.c:2176:kvm_arch_init: Object 0x564bfd5c3200 is not an instance of type x86-machine + +Qemu command line to reproduce: + + sudo x86_64-softmmu/qemu-system-x86_64 -machine 'none,accel=kvm' + +Commit ed9e923c3c (Dec 12, 2019) introduced the issue by removing an object_dynamic_cast call. In this scenario, kvm_arch_init is passed an instance of "none-machine" instead of "x86-machine". + +The following one-line change to target/i386/kvm.c reintroduces the cast: + + if (kvm_check_extension(s, KVM_CAP_X86_SMM) && ++ object_dynamic_cast(OBJECT(ms), TYPE_X86_MACHINE) && + x86_machine_is_smm_enabled(X86_MACHINE(ms))) { + smram_machine_done.notify = register_smram_listener; + qemu_add_machine_init_done_notifier(&smram_machine_done); + } + +This was fixed in commit 8f54bbd0b4 "x86: Check for machine state object class before typecasting it". + diff --git a/results/classifier/zero-shot/108/KVM/1863819 b/results/classifier/zero-shot/108/KVM/1863819 new file mode 100644 index 00000000..3d45ac63 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1863819 @@ -0,0 +1,61 @@ +KVM: 0.931 +graphic: 0.916 +other: 0.894 +debug: 0.880 +performance: 0.869 +semantic: 0.848 +files: 0.810 +socket: 0.761 +vnc: 0.739 +device: 0.711 +permissions: 0.708 +network: 0.688 +PID: 0.602 +boot: 0.520 + +repeated KVM single step crashes leaks into SMP guest and crashes guest application + +Guest: Windows 7 x64 +Host: Ubuntu 18.04.4 (kernel 5.3.0-40-generic) +QEMU: master 6c599282f8ab382fe59f03a6cae755b89561a7b3 + +If I try to use GDB to repeatedly single-step a userspace process while running a KVM guest, the userspace process will eventually crash with a 0x80000004 exception (single step). This is easily reproducible on a Windows guest, I've not tried another guest type but I've been told it's the same there also. + +On a Ubuntu 16 host with an older kernel, this will hang the entire machine. However, it seems it may have been fixed by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cc244a20b86090c087073c124284381cdf47234 ? + +It's not clear to me whether this is a KVM or a QEMU bug. A TCG guest does not crash the userspace process in the same way, but it does hang the VM. + +I've tried a variety of QEMU versions (3.0, 4.2, master) and they all exhibit the same behavior. I'm happy to dig into this more if someone can point me in the right direction. + +Here's the outline for reproducing the bug: + +* Compile iloop.cpp (attached) as a 32-bit application using MSVC +* Start Windows 7 x64 guest under GDB + * Pass '-enable-kvm -smp 4,cores=2 -gdb tcp::4567' to QEMU along with other typical options + +(need to get CR3 to ensure we're in the right application context -- if there's an easier way to do this I'd love to hear it!) +* Install WinDBG on guest +* Copy SysInternals LiveKD to guest +* Start iloop.exe in guest, note loop address +* Run LiveKD from administrative prompt + * livekd64.exe -w +* In WinDBG: + * !process 0 0 + * Search for iloop.exe, note DirBase (this is CR3) + +In GDB: +* Execute 'target remote tcp::4567' +* Execute 'c' +* Hit CTRL-C to pause the VM +* Execute 'p/x $cr3' + .. continue if not equal to DirBase in WinDBG, keep stopping until it is equal +* Once $cr3 is correct value, if you 'stepi' a few times you'll note the process going in a loop, it should keep hitting the address echoed to the console by iloop.exe + +Crash the process from GDB: +* Execute 'stepi 100000000' +* Watch the process, eventually it'll die with an 0x80000004 error + + + +Some experimentation with newer kernels indicate that this is most likely a KVM bug. + diff --git a/results/classifier/zero-shot/108/KVM/1873340 b/results/classifier/zero-shot/108/KVM/1873340 new file mode 100644 index 00000000..6bebfcac --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1873340 @@ -0,0 +1,41 @@ +KVM: 0.944 +device: 0.832 +socket: 0.749 +boot: 0.631 +vnc: 0.604 +graphic: 0.595 +performance: 0.571 +files: 0.569 +other: 0.470 +permissions: 0.461 +semantic: 0.406 +network: 0.397 +PID: 0.344 +debug: 0.318 + +KVM Old ATI(pre) AMD card passthrough is not working + +Hello, +tried to passthroug old ATI pre AMD PCI / PCI-E cards, on machine where anything else is working - Nvidia /Matrox / 3dfx cards.. + +Here are results: +ATI Mach 64 PCI - videocard - machine start segfault +ATI Rage XL PCI - videocard - machine start segfault +ATI Radeon 7000 PCI - Segmentation fault +ATI X600 Giabyte GV-RX60P128D - Segmentation fault +ATI X700 PCI-E Legend - videocard - completely broken picture from boot +ATI X800 XL PCI-E Gigabyte - videocard - completely broken picture from boot + All cards has last bioses. + +ATI X600 - HP one professional with DMS-59 connector, im unable to make passthrough, but im not able to set in Windows 98/WinXP machine.. anything less than 16 bit colors.. Im getting VM crashes or boot freezes, when i try to boot with more colors. + + Qemu 2.11 and 4.2, is the same, Mint Linux 19.3. + + +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/252 + + diff --git a/results/classifier/zero-shot/108/KVM/1877052 b/results/classifier/zero-shot/108/KVM/1877052 new file mode 100644 index 00000000..0c6d9e4c --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1877052 @@ -0,0 +1,63 @@ +KVM: 0.954 +other: 0.943 +graphic: 0.873 +boot: 0.871 +performance: 0.804 +semantic: 0.784 +device: 0.614 +permissions: 0.535 +PID: 0.532 +files: 0.509 +vnc: 0.504 +debug: 0.476 +socket: 0.459 +network: 0.454 + +KVM Win 10 guest pauses after kernel upgrade + + + +Hello! +Unfortunately the bug has apparently reappeared. I have a Windows 10 running in a VM, which after my today's "apt upgrade" goes into pause mode after a few seconds of running time. + +Until yesterday it used to work and I was able to boot the VM. During the kernel update (from 5.4.0-28.33 to 5.4.0-29.34) the VM was active and then went into pause mode. Even after a reboot of my host system the problem still persists: the VM boots for a few seconds and then switches to pause mode. + + +Kind regards, + Andreas + + + + + + + + + +Note: might be related (or not) to bug 1866870 +Let's analyze as independent and dup if it turns out to be a dup. + +The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are unrelated (in regard to guest hang). +Those happen on +a) too old kernels that don't support the feature +b) mismatch of expectations of a chips vs its actual capabilities +E.g. if libvirt thinks a feature should be supported by a chip, but isn't. +There are toomany SKUs out there to be perfect - so these are red-herrings at best. + +I have not seen similar reports recently nor anyone else chiming in on this one. +After loosing what e thought could be a track to the bgu I'm puzzled what to do now on this? + +@Andreas - did you in the meantime find any new insight on this? + +@Andreas - If we find nothing else to try I'll ping you when I have a newer qemu&libvirt build for Ubuntu 20.10 for you to try. + +I haven't seen any similar reports nor any updates here. +Might I ask if you have got any further since then? + +Qemu 5.0 is available in Ubuntu 20.10 now, if you are willing to upgrade or install a test system that might be worth a try (new libvirt is still WIP, but unlikely to play a role here). +20.10 proposed would even have a 5.8.0.12.14 kernel since a kernel change might have been what started this that might be worth a check as well. + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1878250 b/results/classifier/zero-shot/108/KVM/1878250 new file mode 100644 index 00000000..b2df0617 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1878250 @@ -0,0 +1,69 @@ +KVM: 0.936 +other: 0.928 +vnc: 0.925 +files: 0.915 +permissions: 0.907 +graphic: 0.905 +performance: 0.905 +semantic: 0.901 +debug: 0.897 +device: 0.895 +network: 0.889 +boot: 0.887 +socket: 0.885 +PID: 0.876 + +Assertion failure in iov_from_buf_full through the e1000e + +Hello, +While fuzzing, I found an input that triggers an assertion failure in +iov_from_buf_full through the e1000e: + +size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t): Assertion `offset == 0' failed. + + +#3 0x00007ffff6866092 in __GI___assert_fail (assertion=0x5555570c74c0 <str> "offset == 0", file=0x5555570c7500 <str> "/home/alxndr/Development/qemu/util/iov.c", line=0x28, function=0x5555570c7560 <__PRETTY_FUNCTION__.iov_from_buf_full> "size_t iov_from_buf_full(const struct iovec *, unsigned int, size_t, const void *, size_t)") at assert.c:101 +#4 0x0000555556c5fa5e in iov_from_buf_full (iov=<optimized out>, iov_cnt=<optimized out>, offset=<optimized out>, buf=buf@entry=0x7fffffffbb60, bytes=<optimized out>, bytes@entry=0x2) at /home/alxndr/Development/qemu/util/iov.c:40 +#5 0x00005555565f585e in iov_from_buf (iov=0x7fffffffb830, iov_cnt=0xffffb830, offset=0x0, buf=0x7fffffffbb60, bytes=0x2) at /home/alxndr/Development/qemu/include/qemu/iov.h:49 +#6 0x00005555565f585e in net_tx_pkt_update_ip_checksums (pkt=<optimized out>) at /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:139 +#7 0x0000555556621f9c in e1000e_setup_tx_offloads (core=0x7fffeeb754e0, tx=0x7fffeeb95748) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:638 +#8 0x0000555556621f9c in e1000e_tx_pkt_send (core=0x7fffeeb754e0, tx=0x7fffeeb95748, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:658 +#9 0x0000555556621f9c in e1000e_process_tx_desc (core=0x7fffeeb754e0, tx=0x7fffeeb95748, dp=<optimized out>, queue_index=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:743 +#10 0x0000555556621f9c in e1000e_start_xmit (core=<optimized out>, txr=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934 +#11 0x000055555661edb1 in e1000e_set_tdt (core=0x7fffffffb830, index=0xe06, val=0x563) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451 +#12 0x000055555660f2cd in e1000e_core_write (core=<optimized out>, addr=<optimized out>, val=<optimized out>, size=<optimized out>) at /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261 +#13 0x00005555560028d7 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>, mask=<optimized out>, attrs=...) at /home/alxndr/Development/qemu/memory.c:483 + +I can reproduce it in qemu 5.0 using: + +cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none +outl 0xcf8 0x80001010 +outl 0xcfc 0xe1020000 +outl 0xcf8 0x80001014 +outl 0xcf8 0x80001004 +outw 0xcfc 0x7 +outl 0xcf8 0x800010a2 +write 0xe10207e8 0x14 0x00002d05225f3f5f5e00000200000000250013ff +write 0x200006a 0xc 0x08004500feffffff02007b06 +write 0xe1020098 0x3a2 0x000006ffdf054e411b0002e10000000006ffe1054e411b0002e10000000006ffe3054e411b0002e10000000006ffe5054e411b0002e10000000006ffe7054e411b0002e10000000006ffe9054e411b0002e10000000006ffeb054e411b0002e10000000006ffed054e411b0002e10000000006ffef054e411b0002e10000000006fff1054e411b0002e10000000006fff3054e411b0002e10000000006fff5054e411b0002e10000000006fff7054e411b0002e10000000006fff9054e411b0002e10000000006fffb054e411b0002e10000000006fffd054e411b0002e10000000006ffff054e411b0002e10000000006ff01054e411b0002e10000000006ff03054e411b0002e10000000006ff05054e411b0002e10000000006ff07054e411b0002e10000000006ff09054e411b0002e10000000006ff0b054e411b0002e10000000006ff0d054e411b0002e10000000006ff0f054e411b0002e10000000006ff11054e411b0002e10000000006ff13054e411b0002e10000000006ff15054e411b0002e10000000006ff17054e411b0002e10000000006ff19054e411b0002e10000000006ff1b054e411b0002e10000000006ff1d054e411b0002e10000000006ff1f054e411b0002e10000000006ff21054e411b0002e10000000006ff23054e411b0002e10000000006ff25054e411b0002e10000000006ff27054e411b0002e10000000006ff29054e411b0002e10000000006ff2b054e411b0002e10000000006ff2d054e411b0002e10000000006ff2f054e411b0002e10000000006ff31054e411b0002e10000000006ff33054e411b0002e10000000006ff35054e411b0002e10000000006ff37054e411b0002e10000000006ff39054e411b0002e10000000006ff3b054e411b0002e10000000006ff3d054e411b0002e10000000006ff3f054e411b0002e10000000006ff41054e411b0002e10000000006ff43054e411b0002e10000000006ff45054e411b0002e10000000006ff47054e411b0002e10000000006ff49054e411b0002e10000000006ff4b054e411b0002e10000000006ff4d054e411b0002e10000000006ff4f054e411b0002e10000000006ff51054e411b0002e10000000006ff53054e411b0002e10000000006ff55054e411b0002e10000000006ff57054e411b0002e10000000006ff59054e411b0002e10000000006ff5b054e411b0002e10000000006ff5d054e411b0002e10000000006ff5f054e411b0002e10000000006ff61054e411b0002e10000000006ff6305 +EOF + +I also attached the traces to this launchpad report, in case the formatting is broken: + +qemu-system-i386 -M pc-q35-5.0 -nographic -qtest stdio -monitor none -serial none < attachment + +Please let me know if I can provide any further info. +-Alex + + + +This still triggers with current QEMU development version ... marking as "Confirmed" ... Alexander, could you please move this ticket to the new issue tracker at gitlab? + +I moved this report over to QEMU's new bug tracker on gitlab.com. +Please continue with the discussion here: + +https://gitlab.com/qemu-project/qemu/-/issues/535 + +Thanks for moving it over! ... let's close this one here on Launchpad now. + + diff --git a/results/classifier/zero-shot/108/KVM/1880507 b/results/classifier/zero-shot/108/KVM/1880507 new file mode 100644 index 00000000..3bb8492d --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1880507 @@ -0,0 +1,27 @@ +KVM: 0.983 +semantic: 0.860 +device: 0.799 +other: 0.704 +graphic: 0.655 +performance: 0.423 +boot: 0.402 +network: 0.395 +debug: 0.304 +PID: 0.278 +socket: 0.230 +files: 0.166 +permissions: 0.121 +vnc: 0.109 + +VMM from Ubuntu 20.04 does not show the memory consumption + +KVM host system: Ubuntu 18.04 and 20.04, guest machines: Windows and Ubuntu. Management through Ubuntu 20.04, vmm does not show RAM consumption for Windows guest systems (Win7, Win2008R2), for Ubuntu values are shown. The error is not observed in Ubuntu 18.04/vmm. + +Does "vmm" mean Virtual Machine Manager (aka virt-manager)? If yes, +please file this bug against the virt-manager package instead of qemu. + +Thanks! + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/1883732 b/results/classifier/zero-shot/108/KVM/1883732 new file mode 100644 index 00000000..f282924f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1883732 @@ -0,0 +1,136 @@ +KVM: 0.941 +other: 0.905 +performance: 0.857 +vnc: 0.845 +permissions: 0.841 +device: 0.812 +debug: 0.772 +PID: 0.763 +files: 0.762 +graphic: 0.751 +boot: 0.739 +network: 0.726 +socket: 0.712 +semantic: 0.667 + +xhci_kick_epctx: Assertion `ring->dequeue != 0' failed. + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +Here's a QTest reproducer: + +cat << EOF | ./i386-softmmu/qemu-system-i386 \ +-device nec-usb-xhci -trace usb\* \ +-device usb-audio -device usb-storage,drive=mydrive \ +-drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \ +-nodefaults -nographic -qtest stdio +outl 0xcf8 0x80001014 +outl 0xcfc 0xff000a8e +outl 0xcf8 0x80001004 +outl 0xcfc 0x1c77695e +writel 0xff000a8e00000040 0x1d00d815 +write 0x1d 0x1 0x5c +write 0x2d 0x1 0x27 +write 0x3d 0x1 0x2e +write 0xd 0x1 0x60 +write 0x17232 0x1 0x03 +write 0x17254 0x1 0x05 +write 0x4d 0x1 0x5c +write 0x5d 0x1 0x27 +write 0x60 0x1 0x2e +write 0x61 0x1 0x72 +write 0x62 0x1 0x01 +write 0x6d 0x1 0x2e +write 0x6f 0x1 0x01 +writel 0xff000a8e00002000 0x0 +writeq 0xff000a8e00002000 0x514ef0100000009 +EOF + +The trace: +[R +0.031152] writel 0xff000a8e00000040 0x1d00d815 +26994@1597124755.565242:usb_xhci_oper_write off 0x0000, val 0x1d00d815 +26994@1597124755.565247:usb_xhci_run +26994@1597124755.565252:usb_xhci_irq_intx level 0 +OK +[S +0.031173] OK +[R +0.031179] write 0x1d 0x1 0x5c +OK +[S +0.031190] OK +[R +0.031195] write 0x2d 0x1 0x27 +OK +[S +0.031198] OK +[R +0.031203] write 0x3d 0x1 0x2e +OK +[S +0.031207] OK +[R +0.031211] write 0xd 0x1 0x60 +OK +[S +0.031214] OK +[R +0.031219] write 0x17232 0x1 0x03 +OK +[S +0.031224] OK +[R +0.031228] write 0x17254 0x1 0x05 +OK +[S +0.031231] OK +[R +0.031236] write 0x4d 0x1 0x5c +OK +[S +0.031239] OK +[R +0.031244] write 0x5d 0x1 0x27 +OK +[S +0.031247] OK +[R +0.031251] write 0x60 0x1 0x2e +OK +[S +0.031254] OK +[R +0.031259] write 0x61 0x1 0x72 +OK +[S +0.031262] OK +[R +0.031267] write 0x62 0x1 0x01 +OK +[S +0.031270] OK +[R +0.031275] write 0x6d 0x1 0x2e +OK +[S +0.031278] OK +[R +0.031282] write 0x6f 0x1 0x01 +OK +[S +0.031286] OK +[R +0.031290] writel 0xff000a8e00002000 0x0 +26994@1597124755.565377:usb_xhci_doorbell_write off 0x0000, val 0x00000000 +26994@1597124755.565384:usb_xhci_fetch_trb addr 0x0000000000000000, ???, p 0x0000000000000000, s 0x00000000, c 0x00006000 +26994@1597124755.565390:usb_xhci_unimplemented command (0x18) +26994@1597124755.565395:usb_xhci_fetch_trb addr 0x0000000000000010, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00 +26994@1597124755.565399:usb_xhci_fetch_trb addr 0x0000000000000020, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +26994@1597124755.565403:usb_xhci_slot_enable slotid 1 +26994@1597124755.565406:usb_xhci_fetch_trb addr 0x0000000000000030, CR_ADDRESS_DEVICE, p 0x0000000000000000, s 0x00000000, c 0x00002e00 +26994@1597124755.565411:usb_xhci_fetch_trb addr 0x0000000000000040, CR_NOOP, p 0x0000000000000000, s 0x00000000, c 0x00005c00 +26994@1597124755.565416:usb_xhci_fetch_trb addr 0x0000000000000050, CR_ENABLE_SLOT, p 0x0000000000000000, s 0x00000000, c 0x00002700 +26994@1597124755.565421:usb_xhci_slot_enable slotid 2 +26994@1597124755.565423:usb_xhci_fetch_trb addr 0x0000000000000060, CR_ADDRESS_DEVICE, p 0x000000000001722e, s 0x00000000, c 0x01002e00 +26994@1597124755.565431:usb_xhci_slot_address slotid 1, port 1 +26994@1597124755.565436:usb_xhci_ep_enable slotid 1, epid 1 +26994@1597124755.565444:usb_xhci_fetch_trb addr 0x0000000000000070, TRB_RESERVED, p 0x0000000000000000, s 0x00000000, c 0x00000000 +OK +[S +0.031365] OK +[R +0.031370] writeq 0xff000a8e00002000 0x514ef0100000009 +26994@1597124755.565456:usb_xhci_doorbell_write off 0x0000, val 0x00000009 +26994@1597124755.565459:usb_xhci_doorbell_write off 0x0004, val 0x0514ef01 +26994@1597124755.565462:usb_xhci_ep_kick slotid 1, epid 1, streamid 1300 +qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/hw/usb/hcd-xhci.c:1955: void xhci_kick_epctx(XHCIEPContext *, unsigned int): Assertion `ring->dequeue != 0' failed. +Aborted + +-Alex + +ClusterFuzz testcase 5662083651469312 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_qemu&range=202011160601:202011170627 + diff --git a/results/classifier/zero-shot/108/KVM/1883733 b/results/classifier/zero-shot/108/KVM/1883733 new file mode 100644 index 00000000..212f9d32 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1883733 @@ -0,0 +1,372 @@ +KVM: 0.928 +other: 0.914 +vnc: 0.901 +performance: 0.896 +permissions: 0.892 +semantic: 0.832 +device: 0.814 +graphic: 0.811 +debug: 0.810 +files: 0.808 +PID: 0.786 +boot: 0.785 +network: 0.779 +socket: 0.756 + +FIXME xhci_alloc_device_streams:972 guest streams config not identical for all eps + +To reproduce run the QEMU with the following command line: +``` +qemu-system-x86_64 -cdrom hypertrash_os_bios_crash.iso -nographic -m 100 -enable-kvm -device virtio-gpu-pci -device nec-usb-xhci -device usb-audio +``` + +QEMU Version: +``` +# qemu-5.0.0 +$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make +$ x86_64-softmmu/qemu-system-x86_64 --version +QEMU emulator version 5.0.0 +Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers +``` + + + +OSS-Fuzz reported this: + +=== Reproducer === +cat << EOF | ./qemu-system-i386 -display none \ +-machine accel=qtest, -m 512M -machine q35 -nodefaults \ +-device qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0 \ +-device usb-tablet -device usb-wacom-tablet -device usb-audio \ +-qtest stdio +outl 0xcf8 0x80000803 +outl 0xcfc 0x18ffffff +outl 0xcf8 0x80000813 +outb 0xcfc 0x5e +write 0x5e000074 0x4 0x5a636c6f +writel 0x5e000040 0x5adeb005 +write 0xd 0x1 0x24 +write 0x1d 0x1 0x2e +write 0x2d 0x1 0xff +write 0x3d 0x1 0x24 +write 0x4d 0x1 0x2e +write 0x5d 0x1 0xff +write 0x6d 0x1 0x24 +write 0x7d 0x1 0x2e +write 0x8d 0x1 0xff +write 0x9d 0x1 0x24 +write 0xad 0x1 0x2e +write 0xbd 0x1 0xff +write 0xcd 0x1 0x24 +write 0xdd 0x1 0x2e +write 0x6d04 0x1 0x03 +write 0x6d26 0x1 0x04 +write 0xed 0x1 0xff +write 0xfd 0x1 0x24 +write 0x10d 0x1 0x2e +write 0x11d 0x1 0xff +write 0x12d 0x1 0x24 +write 0x13d 0x1 0x2e +write 0x14d 0x1 0xff +write 0x15d 0x1 0x24 +write 0x16d 0x1 0x2e +write 0x17d 0x1 0xff +write 0x18d 0x1 0x24 +write 0x19d 0x1 0x2e +write 0x1ad 0x1 0xff +write 0x1bd 0x1 0x24 +write 0x1cd 0x1 0x2e +write 0x1dd 0x1 0xff +write 0x1ed 0x1 0x24 +write 0x1fd 0x1 0x2e +write 0x20d 0x1 0xff +write 0x21d 0x1 0x24 +write 0x22d 0x1 0x2e +write 0x23d 0x1 0xff +write 0x24d 0x1 0x24 +write 0x25d 0x1 0x2e +write 0x26d 0x1 0xff +write 0x27d 0x1 0x24 +write 0x28d 0x1 0x2e +write 0x29d 0x1 0xff +write 0x2ad 0x1 0x24 +write 0x2bd 0x1 0x2e +write 0x2cd 0x1 0xff +write 0x2dd 0x1 0x24 +write 0x2ed 0x1 0x2e +write 0x2fd 0x1 0xff +write 0x30d 0x1 0x24 +write 0x31d 0x1 0x2e +write 0x32d 0x1 0xff +write 0x33d 0x1 0x24 +write 0x34d 0x1 0x2e +write 0x35d 0x1 0xff +write 0x36d 0x1 0x24 +write 0x37d 0x1 0x2e +write 0x38d 0x1 0xff +write 0x39d 0x1 0x24 +write 0x3ad 0x1 0x2e +write 0x3bd 0x1 0xff +write 0x3cd 0x1 0x24 +write 0x3dd 0x1 0x2e +write 0x3ed 0x1 0xff +write 0x3fd 0x1 0x24 +write 0x40d 0x1 0x2e +write 0x41d 0x1 0xff +write 0x42d 0x1 0x24 +write 0x43d 0x1 0x2e +write 0x44d 0x1 0xff +write 0x45d 0x1 0x24 +write 0x46d 0x1 0x2e +write 0x47d 0x1 0xff +write 0x48d 0x1 0x24 +write 0x49d 0x1 0x2e +write 0x4ad 0x1 0xff +write 0x4bd 0x1 0x24 +write 0x4cd 0x1 0x2e +write 0x4dd 0x1 0xff +write 0x4ed 0x1 0x24 +write 0x4fd 0x1 0x2e +write 0x50d 0x1 0xff +write 0x51d 0x1 0x24 +write 0x52d 0x1 0x2e +write 0x53d 0x1 0xff +write 0x54d 0x1 0x24 +write 0x55d 0x1 0x2e +write 0x56d 0x1 0xff +write 0x57d 0x1 0x24 +write 0x58d 0x1 0x2e +write 0x59d 0x1 0xff +write 0x5ad 0x1 0x24 +write 0x5bd 0x1 0x2e +write 0x5cd 0x1 0xff +write 0x5dd 0x1 0x24 +write 0x5ed 0x1 0x2e +write 0x5fd 0x1 0xff +write 0x60d 0x1 0x24 +write 0x61d 0x1 0x2e +write 0x62d 0x1 0xff +write 0x63d 0x1 0x24 +write 0x64d 0x1 0x2e +write 0x65d 0x1 0xff +write 0x66d 0x1 0x24 +write 0x67d 0x1 0x2e +write 0x68d 0x1 0xff +write 0x69d 0x1 0x24 +write 0x6ad 0x1 0x2e +write 0x6bd 0x1 0xff +write 0x6cd 0x1 0x24 +write 0x6dd 0x1 0x2e +write 0x6ed 0x1 0xff +write 0x6fd 0x1 0x24 +write 0x70d 0x1 0x2e +write 0x71d 0x1 0xff +write 0x72d 0x1 0x24 +write 0x73d 0x1 0x2e +write 0x74d 0x1 0xff +write 0x75d 0x1 0x24 +write 0x76d 0x1 0x2e +write 0x77d 0x1 0xff +write 0x78d 0x1 0x24 +write 0x79d 0x1 0x2e +write 0x7ad 0x1 0xff +write 0x7bd 0x1 0x24 +write 0x7cd 0x1 0x2e +write 0x7dd 0x1 0xff +write 0x7ed 0x1 0x24 +write 0x7fd 0x1 0x2e +write 0x80d 0x1 0xff +write 0x81d 0x1 0x24 +write 0x82d 0x1 0x2e +write 0x83d 0x1 0xff +write 0x84d 0x1 0x24 +write 0x85d 0x1 0x2e +write 0x86d 0x1 0xff +write 0x87d 0x1 0x24 +write 0x88d 0x1 0x2e +write 0x89d 0x1 0xff +write 0x8ad 0x1 0x24 +write 0x8bd 0x1 0x2e +write 0x8cd 0x1 0xff +write 0x8dd 0x1 0x24 +write 0x8ed 0x1 0x2e +write 0x8fd 0x1 0xff +write 0x90d 0x1 0x24 +write 0x91d 0x1 0x2e +write 0x92d 0x1 0xff +write 0x93d 0x1 0x24 +write 0x94d 0x1 0x2e +write 0x95d 0x1 0xff +write 0x96d 0x1 0x24 +write 0x97d 0x1 0x2e +write 0x98d 0x1 0xff +write 0x99d 0x1 0x24 +write 0x9ad 0x1 0x2e +write 0x9bd 0x1 0xff +write 0x9cd 0x1 0x24 +write 0x9dd 0x1 0x2e +write 0x9ed 0x1 0xff +write 0x9fd 0x1 0x24 +write 0xa0d 0x1 0x2e +write 0xa1d 0x1 0xff +write 0xa2d 0x1 0x24 +write 0xa3d 0x1 0x2e +write 0xa4d 0x1 0xff +write 0xa5d 0x1 0x24 +write 0xa6d 0x1 0x2e +write 0xa7d 0x1 0xff +write 0xa8d 0x1 0x24 +write 0xa9d 0x1 0x2e +write 0xaad 0x1 0xff +write 0xabd 0x1 0x24 +write 0xacd 0x1 0x2e +write 0xadd 0x1 0xff +write 0xaed 0x1 0x24 +write 0xafd 0x1 0x2e +write 0xb0d 0x1 0xff +write 0xb1d 0x1 0x24 +write 0xb2d 0x1 0x2e +write 0xb3d 0x1 0xff +write 0xb4d 0x1 0x24 +write 0xb5d 0x1 0x2e +write 0xb6d 0x1 0xff +write 0xb7d 0x1 0x24 +write 0xb8d 0x1 0x2e +write 0xb9d 0x1 0xff +write 0xbad 0x1 0x24 +write 0xbbd 0x1 0x2e +write 0xbcd 0x1 0xff +write 0xbdd 0x1 0x24 +write 0xbed 0x1 0x2e +write 0xbfd 0x1 0xff +write 0xc0d 0x1 0x24 +write 0xc1d 0x1 0x2e +write 0xc2d 0x1 0xff +write 0xc3d 0x1 0x24 +write 0xc4d 0x1 0x2e +write 0xc5d 0x1 0xff +write 0xc6d 0x1 0x24 +write 0xc7d 0x1 0x2e +write 0xc8d 0x1 0xff +write 0xc9d 0x1 0x24 +write 0xcad 0x1 0x2e +write 0xcbd 0x1 0xff +write 0xccd 0x1 0x24 +write 0xcdd 0x1 0x2e +write 0xced 0x1 0xff +write 0xcfd 0x1 0x24 +write 0xd0d 0x1 0x2e +write 0xd1d 0x1 0xff +write 0xd2d 0x1 0x24 +write 0xd3d 0x1 0x2e +write 0xd4d 0x1 0xff +write 0xd5d 0x1 0x24 +write 0xd6d 0x1 0x2e +write 0xd7d 0x1 0xff +write 0xd8d 0x1 0x24 +write 0xd9d 0x1 0x2e +write 0xdad 0x1 0xff +write 0xdbd 0x1 0x24 +write 0xdcd 0x1 0x2e +write 0xddd 0x1 0xff +write 0xded 0x1 0x24 +write 0xdfd 0x1 0x2e +write 0xe0d 0x1 0xff +write 0xe1d 0x1 0x24 +write 0xe2d 0x1 0x2e +write 0xe3d 0x1 0xff +write 0xe4d 0x1 0x24 +write 0xe5d 0x1 0x2e +write 0xe6d 0x1 0xff +write 0xe7d 0x1 0x24 +write 0xe8d 0x1 0x2e +write 0xe9d 0x1 0xff +write 0xead 0x1 0x24 +write 0xebd 0x1 0x2e +write 0xecd 0x1 0xff +write 0xedd 0x1 0x24 +write 0xeed 0x1 0x2e +write 0xefd 0x1 0xff +write 0xf0d 0x1 0x24 +write 0xf1d 0x1 0x2e +write 0xf2d 0x1 0xff +write 0xf3d 0x1 0x24 +write 0xf4d 0x1 0x2e +write 0xf5d 0x1 0xff +write 0xf6d 0x1 0x24 +write 0xf7d 0x1 0x2e +write 0xf8d 0x1 0xff +write 0xf9d 0x1 0x24 +write 0xfad 0x1 0x2e +write 0xfbd 0x1 0xff +write 0xfcd 0x1 0x24 +write 0xfdd 0x1 0x2e +write 0xfed 0x1 0xff +write 0xffd 0x1 0x24 +write 0x1001 0x1 0x6d +write 0x100d 0x1 0x2e +write 0x100f 0x1 0x05 +writel 0x5e002000 0x0 +write 0x102d 0x1 0x24 +write 0x103d 0x1 0x2e +write 0x1040 0x1 0xfe +write 0x1041 0x1 0xff +write 0x1042 0x1 0xff +write 0x1043 0x1 0xff +write 0x1044 0x1 0xff +write 0x1045 0x1 0xff +write 0x1046 0x1 0xff +write 0x1047 0x1 0xff +write 0x104d 0x1 0x31 +write 0x104f 0x1 0x05 +write 0x2 0x1 0x11 +write 0x3 0x1 0x07 +write 0xf 0x1 0x73 +write 0x9f 0x1 0x65 +write 0x13f 0x1 0x6d +writel 0x5e002000 0x0 +EOF + +=== Stack Trace === +FIXME xhci_alloc_device_streams:921 guest streams config not identical for all eps +==683875== ERROR: libFuzzer: deadly signal +0x56009f09d311 in __sanitizer_print_stack_trace (fuzz-i386+0x2b16311) +0x56009efe63d8 in fuzzer::PrintStackTrace() (fuzz-i386+0x2a5f3d8) +0x56009efcc413 in fuzzer::Fuzzer::CrashCallback() (fuzz-i386+0x2a45413) +0x7f0aed93e13f (/lib/x86_64-linux-gnu/libpthread.so.0+0x1413f) +0x7f0aed773db0 in __libc_signal_restore_set signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3 +0x7f0aed773db0 in raise signal/../sysdeps/unix/sysv/linux/raise.c:48:3 +0x7f0aed75d536 in abort stdlib/abort.c:79:7 +0x56009f4ecde7 in xhci_alloc_device_streams hw/usb/hcd-xhci.c:921:13 +0x56009f4ecde7 in xhci_configure_slot hw/usb/hcd-xhci.c:2223:11 +0x56009f4ecde7 in xhci_process_commands hw/usb/hcd-xhci.c:2466:31 +0x56009f4e36fb in xhci_doorbell_write hw/usb/hcd-xhci.c:3100:13 +0x5600a07fb025 in memory_region_write_accessor softmmu/memory.c:491:5 +0x5600a07faa93 in access_with_adjusted_size softmmu/memory.c:552:18 +0x5600a07fa2f0 in memory_region_dispatch_write softmmu/memory.c +0x5600a0249f36 in flatview_write_continue softmmu/physmem.c:2759:23 +0x5600a023fbbb in flatview_write softmmu/physmem.c:2799:14 +0x5600a023fbbb in address_space_write softmmu/physmem.c:2891:18 +0x5600a06d4362 in qtest_process_command softmmu/qtest.c:534:13 +0x5600a06d15bf in qtest_process_inbuf softmmu/qtest.c:797:9 +0x5600a06d1315 in qtest_server_inproc_recv softmmu/qtest.c:904:9 +0x5600a0d0edf8 in qtest_sendf tests/qtest/libqtest.c:438:5 +0x5600a0d1038e in qtest_write tests/qtest/libqtest.c:1004:5 +0x5600a0d1038e in qtest_writel tests/qtest/libqtest.c:1020:5 +0x56009f0d7eaa in __wrap_qtest_writel tests/qtest/fuzz/qtest_wrappers.c:180:9 +0x56009f0d0299 in op_write tests/qtest/fuzz/generic_fuzz.c:473:13 +0x56009f0ce4e9 in generic_fuzz tests/qtest/fuzz/generic_fuzz.c:680:17 +0x56009f0c7723 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:151:5 + +OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28602 + + + + +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/274 + + diff --git a/results/classifier/zero-shot/108/KVM/1914353 b/results/classifier/zero-shot/108/KVM/1914353 new file mode 100644 index 00000000..49786e4d --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1914353 @@ -0,0 +1,76 @@ +KVM: 0.974 +graphic: 0.775 +other: 0.747 +device: 0.739 +PID: 0.720 +socket: 0.622 +vnc: 0.528 +semantic: 0.523 +performance: 0.517 +network: 0.506 +files: 0.506 +permissions: 0.493 +debug: 0.471 +boot: 0.416 + +QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID + +Via [qemu-security] list + ++-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+ +| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote: +| > Per the ARM Generic Interrupt Controller Architecture specification +| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit, +| > not 10: +| > +| > - Table 4-21 GICD_SGIR bit assignments +| > +| > The Interrupt ID of the SGI to forward to the specified CPU +| > interfaces. The value of this field is the Interrupt ID, in +| > the range 0-15, for example a value of 0b0011 specifies +| > Interrupt ID 3. +| > +... +| > Correct the irq mask to fix an undefined behavior (which eventually +| > lead to a heap-buffer-overflow, see [Buglink]): +| > +| > $ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M virt,accel=qtest -qtest stdio +| > [I 1612088147.116987] OPENED +| > [R +0.278293] writel 0x8000f00 0xff4affb0 +| > ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for type 'uint8_t [16][8]' +| > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../hw/intc/arm_gic.c:1498:13 +| > +| > Cc: <email address hidden> +| > Fixes: 9ee6e8bb853 ("ARMv7 support.") +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916 +| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917 +... + +On 210202 1221, Peter Maydell wrote: +> In both cases the overrun is on the first writel to 0x8000f00, +> but the fuzzer has for some reason not reported that but instead +> blundered on until it happens to trigger some other issue that +> resulted from the memory corruption it induced with the first write. +> +... +> On the CVE: +> +> Since this can affect systems using KVM, this is a security bug for +> us. However, it only affects an uncommon configuration: +> you are only vulnerable if you are using "kernel-irqchip=off" +> (the default is 'on', and turning it off is an odd thing to do). +> +> thanks +> -- PMM +> + +Upstream patch: + -> https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg00709.html + +CVE requested. + +'CVE-2021-20221' assigned by Red Hat Inc. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bd + diff --git a/results/classifier/zero-shot/108/KVM/1914748 b/results/classifier/zero-shot/108/KVM/1914748 new file mode 100644 index 00000000..1180f1b5 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1914748 @@ -0,0 +1,39 @@ +KVM: 0.970 +graphic: 0.801 +device: 0.781 +vnc: 0.699 +performance: 0.672 +semantic: 0.623 +network: 0.530 +permissions: 0.458 +other: 0.416 +boot: 0.400 +socket: 0.345 +files: 0.338 +debug: 0.309 +PID: 0.287 + +Confuse error message when KVM can not start requested CPU + +As of commit 1ba089f2255, on Cavium CN8890 (ThunderX cores): + +$ qemu-system-aarch64 -display none -accel kvm -M virt,gic-version=3 -accel kvm -cpu cortex-a57 --trace \*kvm_vcpu\* +kvm_vcpu_ioctl cpu_index 0, type 0x4020aeae, arg 0xffff9b7f9b18 +qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument + +(same using "-cpu cortex-a53" or cortex-a72). + +Explanation from Peter Maydell on IRC: +> using a specific cpu type will only work with KVM if the host CPU really is that +> exact CPU type, otherwise, use "-cpu host" or "-cpu max" + +Having a better error description would help to understand the reason. + + +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/239 + + diff --git a/results/classifier/zero-shot/108/KVM/1919169 b/results/classifier/zero-shot/108/KVM/1919169 new file mode 100644 index 00000000..4f49ed7d --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1919169 @@ -0,0 +1,36 @@ +KVM: 0.928 +graphic: 0.912 +performance: 0.905 +device: 0.870 +boot: 0.867 +semantic: 0.827 +PID: 0.825 +files: 0.815 +other: 0.805 +vnc: 0.750 +socket: 0.721 +network: 0.691 +permissions: 0.622 +debug: 0.536 + +[git]Startup crash when trying to use an EFI enabled VM in accel/kvm/kvm-all.c + +Hello. + +I build a git version based on commit 6157b0e19721aadb4c7fdcfe57b2924af6144b14. + +When I try to launch an EFI enabled VM, it crashes on start. Here is the command line used: + +qemu-system-x86_64 -bios /usr/share/edk2-ovmf/x64/OVMF.fd -enable-kvm -smp 4 -soundhw all -k fr -m 4096 -vga qxl -hda disk.img -cdrom archlinux-2021.03.01-x86_64.iso -boot cd & + +Here is the log I get: + +``` +qemu-system-x86_64: ../accel/kvm/kvm-all.c:690: kvm_log_clear_one_slot: Assertion `QEMU_IS_ALIGNED(start | size, psize)' failed. +``` + + +ed2k-ovmf version: 202102 + +I tried an older version, edk2-ovmf 202011, same crash on start. + diff --git a/results/classifier/zero-shot/108/KVM/1922430 b/results/classifier/zero-shot/108/KVM/1922430 new file mode 100644 index 00000000..622eda55 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1922430 @@ -0,0 +1,86 @@ +KVM: 0.954 +graphic: 0.913 +performance: 0.892 +permissions: 0.885 +device: 0.882 +boot: 0.863 +other: 0.857 +semantic: 0.843 +socket: 0.837 +PID: 0.816 +network: 0.804 +files: 0.792 +vnc: 0.665 +debug: 0.527 + +3d accel does not take care of 1280x960 setting + +openSuse 15.2 +kde plasma 5.21.3, frameworks 5.80.0 +libvirt 7.0.0 +qemu 5.2.0 +virgl renderer 0.8.2 + +here is my invocation + +qemu-kvm -enable-kvm \ +-m 2048 -smp 2 -cpu host \ +-device virtio-vga,virgl=on -display gtk,gl=on \ +-device usb-ehci \ +-device usb-kbd \ +-device usb-mouse \ +-device usb-tablet \ +-device ich9-intel-hda \ +-device hda-duplex,audiodev=snd0 \ +-audiodev pa,id=snd0 \ +-device usb-host,vendorid=0x046d,productid=0x08e5 \ +-boot menu=on \ +-nic bridge \ +~/QEMU_VM/android_x86_7.1-r5.img \ + +in the kernel command there is "vga=1280x960" + +with "-device qxl" no problem. I get immediately a window of size 1280x960. + +with "-device virtio-vga,virgl=on -display gtk,gl=on" + +i get a tiny window. + +i must uncheck "zoom to fit" to get a window of size 1280x960. + +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. + + +done + +Ticket has been moved here (thanks!): +https://gitlab.com/qemu-project/qemu/-/issues/315 +... so I'm closing this on Launchpad now. + diff --git a/results/classifier/zero-shot/108/KVM/1926596 b/results/classifier/zero-shot/108/KVM/1926596 new file mode 100644 index 00000000..ffb8c08a --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1926596 @@ -0,0 +1,82 @@ +KVM: 0.961 +debug: 0.958 +graphic: 0.921 +other: 0.885 +device: 0.840 +performance: 0.827 +semantic: 0.807 +permissions: 0.778 +PID: 0.774 +files: 0.702 +network: 0.700 +vnc: 0.631 +socket: 0.615 +boot: 0.457 + +qemu-monitor-event command gets stuck randomly + +We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command +For eg:- +/usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex + +the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process. + +Can you suggest how can we debug this further to find the actual issue. + + +/usr/bin/virsh version + +Compiled against library: libvirt 4.5.0 +Using library: libvirt 4.5.0 +Using API: QEMU 4.5.0 +Running hypervisor: QEMU 2.0.0 + +cat /etc/os-release +NAME="CentOS Linux" +VERSION="7 (Core)" +ID="centos" +ID_LIKE="rhel fedora" +VERSION_ID="7" +PRETTY_NAME="CentOS Linux 7 (Core)" +ANSI_COLOR="0;31" +CPE_NAME="cpe:/o:centos:centos:7" +HOME_URL="https://www.centos.org/" +BUG_REPORT_URL="https://bugs.centos.org/" + +CENTOS_MANTISBT_PROJECT="CentOS-7" +CENTOS_MANTISBT_PROJECT_VERSION="7" +REDHAT_SUPPORT_PRODUCT="centos" +REDHAT_SUPPORT_PRODUCT_VERSION="7" + +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/KVM/1936 b/results/classifier/zero-shot/108/KVM/1936 new file mode 100644 index 00000000..e813b905 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1936 @@ -0,0 +1,16 @@ +KVM: 0.956 +device: 0.858 +files: 0.843 +performance: 0.697 +permissions: 0.627 +semantic: 0.549 +debug: 0.398 +graphic: 0.363 +boot: 0.309 +network: 0.285 +other: 0.280 +PID: 0.198 +socket: 0.087 +vnc: 0.056 + +Pass file descriptor to /dev/kvm device node? diff --git a/results/classifier/zero-shot/108/KVM/1941 b/results/classifier/zero-shot/108/KVM/1941 new file mode 100644 index 00000000..66ae1627 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/1941 @@ -0,0 +1,117 @@ +KVM: 0.943 +graphic: 0.942 +other: 0.935 +permissions: 0.914 +debug: 0.912 +semantic: 0.908 +performance: 0.903 +vnc: 0.885 +device: 0.881 +PID: 0.867 +boot: 0.861 +files: 0.845 +network: 0.844 +socket: 0.840 + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/zero-shot/108/KVM/2046 b/results/classifier/zero-shot/108/KVM/2046 new file mode 100644 index 00000000..460b70fe --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2046 @@ -0,0 +1,16 @@ +KVM: 0.953 +device: 0.857 +network: 0.850 +files: 0.681 +vnc: 0.625 +PID: 0.622 +socket: 0.606 +debug: 0.599 +graphic: 0.547 +permissions: 0.517 +boot: 0.509 +semantic: 0.362 +performance: 0.342 +other: 0.298 + +live migration error : qemu-kvm: Missing section footer for 0000:00:01.3/piix4_pm diff --git a/results/classifier/zero-shot/108/KVM/2313 b/results/classifier/zero-shot/108/KVM/2313 new file mode 100644 index 00000000..52967a8f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2313 @@ -0,0 +1,32 @@ +KVM: 0.982 +device: 0.705 +graphic: 0.685 +semantic: 0.583 +PID: 0.578 +files: 0.484 +vnc: 0.469 +permissions: 0.445 +other: 0.403 +network: 0.389 +socket: 0.369 +boot: 0.362 +performance: 0.330 +debug: 0.318 + +RISC-V KVM strerrorname_np regression breaks build on Alpine Linux +Description of problem: +Build from source fails on Alpine Linux due to the use of the non-portable `strerrorname_np`: +``` +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_realize': +kvm-cpu.c:(.text+0x538): undefined reference to `strerrorname_np' +/usr/lib/gcc/riscv64-alpine-linux-musl/13.2.1/../../../../riscv64-alpine-linux-musl/bin/ld: libqemu-riscv64-softmmu.fa.p/target_riscv_kvm_kvm-cpu.c.o: in function `kvm_cpu_instance_init': +kvm-cpu.c:(.text+0x1244): undefined reference to `strerrorname_np' +``` +Steps to reproduce: +1. install alpine linux on a riscv64 machine +2. build qemu-9.0.0 from source. +3. +Additional information: +Same problem as https://gitlab.com/qemu-project/qemu/-/issues/2041 + +Re-introduced with d4ff3da8f45c52670941c6e1b94e771d69d887e9 and 0d71f0a34938a6ac11953ae3dbec40113d2838a1 diff --git a/results/classifier/zero-shot/108/KVM/239 b/results/classifier/zero-shot/108/KVM/239 new file mode 100644 index 00000000..40c2f84a --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/239 @@ -0,0 +1,16 @@ +KVM: 0.991 +device: 0.831 +debug: 0.763 +graphic: 0.750 +performance: 0.739 +other: 0.714 +semantic: 0.698 +boot: 0.476 +vnc: 0.138 +PID: 0.128 +permissions: 0.060 +socket: 0.022 +files: 0.014 +network: 0.011 + +Confusing error message when KVM can not start requested ARM CPU diff --git a/results/classifier/zero-shot/108/KVM/2392 b/results/classifier/zero-shot/108/KVM/2392 new file mode 100644 index 00000000..ecc9f64f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2392 @@ -0,0 +1,16 @@ +KVM: 0.961 +device: 0.804 +performance: 0.606 +semantic: 0.491 +boot: 0.378 +network: 0.225 +graphic: 0.200 +permissions: 0.195 +other: 0.169 +files: 0.140 +debug: 0.093 +vnc: 0.064 +PID: 0.040 +socket: 0.032 + +Ability to use KVM on Windows diff --git a/results/classifier/zero-shot/108/KVM/2394 b/results/classifier/zero-shot/108/KVM/2394 new file mode 100644 index 00000000..3cdcd084 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2394 @@ -0,0 +1,44 @@ +KVM: 0.995 +graphic: 0.991 +performance: 0.968 +device: 0.952 +semantic: 0.907 +network: 0.861 +PID: 0.833 +files: 0.831 +socket: 0.769 +other: 0.760 +permissions: 0.711 +boot: 0.693 +debug: 0.676 +vnc: 0.624 + +kvm-unit-tests vmx failed +Description of problem: +On the Sierra Forest platform, the vmx test in kvm-unit-tests failed. But this issue cannot be replicated on Emerald Rapids platform. + +The first bad commit is ba6780905943696d790cc880c8e5684b51f027fe. +Steps to reproduce: +1.git clone https://gitlab.com/kvm-unit-tests/kvm-unit-tests.git + +2.cd kvm-unit-tests; ./configure + +3.make standalone + +4.rmmod kvm_intel + +5.modprobe kvm_intel nested=Y allow_smaller_maxphyaddr=Y + +6.cd tests; ./vmx +Additional information: +... +FAIL: HOST_CR3 2000000001007000: vmlaunch fails + +FAIL: HOST_CR3 4000000001007000: vmlaunch fails +... + +SUMMARY: 430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped + +FAIL vmx (430013 tests, 2 unexpected failures, 2 expected failures, 5 skipped) + +[error.log](/uploads/02456b40f2736c0bf34d3f4b3a0c872a/error.log) diff --git a/results/classifier/zero-shot/108/KVM/2436 b/results/classifier/zero-shot/108/KVM/2436 new file mode 100644 index 00000000..cb78be99 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2436 @@ -0,0 +1,16 @@ +KVM: 0.968 +device: 0.947 +network: 0.914 +performance: 0.862 +semantic: 0.350 +graphic: 0.302 +vnc: 0.184 +boot: 0.176 +debug: 0.129 +other: 0.079 +permissions: 0.065 +PID: 0.033 +files: 0.030 +socket: 0.011 + +virtio kvm iofd sigfault bypass diff --git a/results/classifier/zero-shot/108/KVM/252 b/results/classifier/zero-shot/108/KVM/252 new file mode 100644 index 00000000..dceba693 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/252 @@ -0,0 +1,16 @@ +KVM: 0.975 +device: 0.883 +performance: 0.560 +graphic: 0.526 +debug: 0.512 +semantic: 0.449 +permissions: 0.409 +other: 0.379 +network: 0.346 +vnc: 0.191 +files: 0.185 +PID: 0.084 +boot: 0.068 +socket: 0.023 + +KVM Old ATI(pre) AMD card passthrough is not working diff --git a/results/classifier/zero-shot/108/KVM/2548 b/results/classifier/zero-shot/108/KVM/2548 new file mode 100644 index 00000000..ad26576b --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2548 @@ -0,0 +1,421 @@ +KVM: 0.943 +graphic: 0.938 +other: 0.933 +debug: 0.930 +vnc: 0.927 +semantic: 0.924 +performance: 0.917 +PID: 0.917 +network: 0.916 +device: 0.914 +permissions: 0.913 +socket: 0.912 +boot: 0.904 +files: 0.860 + +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. +Description of problem: +Assert failure in `usb_ep_get` : Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT` failed. + +The TD PID needs to be either `USB_TOKEN_IN` or `USB_TOKEN_OUT` in `usb_ep_get`, but in the caller `uhci_handle_td` it may be `USB_TOKEN_SETUP`. + +An unprivileged guest user may be able to reach the assertion, I think this bug is quite akin to CVE-2024-3567 (https://gitlab.com/qemu-project/qemu/-/issues/2273) : + +Users are not directly able to craft URBs, however as a user, one might be able to find a kernel path that would send a TD with PID `USB_TOKEN_SETUP` to QEMU (which is called `USB_PID_SETUP` in Linux). +For instance in the Linux Kernel, `uhci_submit_control` in `drivers/usb/host/uhci-q.c:789` does link a `USB_PID_SETUP` TD to the URB. +Steps to reproduce: +Minimized reproducer: + +``` +cat << EOF | ./qemu/build2/qemu-system-x86_64 -machine q35 -nodefaults \ +-device \ +ich9-usb-ehci1,bus=pcie.0,addr=1d.7,multifunction=on,id=ich9-ehci-1 \ +-device ich9-usb-uhci1,bus=pcie.0,addr=1d.0,multifunction=on,masterbus=i\ +ch9-ehci-1.0,firstport=0 -device ich9-usb-uhci2,bus=pcie.0,addr=1d.1,mul\ +tifunction=on,masterbus=ich9-ehci-1.0,firstport=2 -device ich9-usb-uhci3\ +,bus=pcie.0,addr=1d.2,multifunction=on,masterbus=ich9-ehci-1.0,firstport\ +=4 -drive if=none,id=usbcdrom,media=cdrom -device \ +usb-tablet,bus=ich9-ehci-1.0,port=1,usb_version=1 -device \ +usb-storage,bus=ich9-ehci-1.0,port=2,drive=usbcdrom -qtest stdio +outl 0xcf8 0x8000e900 +inw 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e920 +inl 0xcfc +outl 0xcf8 0x8000e920 +outl 0xcfc 0xc001 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000e904 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e904 +inw 0xcfc +outl 0xcf8 0x8000ef00 +inw 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ef10 +inl 0xcfc +outl 0xcf8 0x8000ef10 +outl 0xcfc 0xe0000000 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ef04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ef04 +inw 0xcfc +outl 0xcf8 0x8000ea00 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000ea20 +inl 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0xc021 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000ea04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000ea04 +inw 0xcfc +outl 0xcf8 0x8000e800 +inw 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000e820 +inl 0xcfc +outl 0xcf8 0x8000e820 +outl 0xcfc 0xc041 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000e804 +outw 0xcfc 0x7 +outl 0xcf8 0x8000e804 +inw 0xcfc +outl 0xcf8 0x8000fa00 +inw 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa20 +inl 0xcfc +outl 0xcf8 0x8000fa20 +outl 0xcfc 0xc061 +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xffffffff +outl 0xcf8 0x8000fa24 +inl 0xcfc +outl 0xcf8 0x8000fa24 +outl 0xcfc 0xe0001000 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000fa04 +outw 0xcfc 0x7 +outl 0xcf8 0x8000fa04 +inw 0xcfc +outl 0xcf8 0x8000ea20 +outl 0xcfc 0x625f69a0 +outb 0xc040 0x46 +outb 0xc040 0x69 +inb 0xc000 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x0 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outl 0xcf8 0x8000ef76 +outw 0xcfc 0x6563 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +inb 0xc000 +clock_step +write 0x4 0x4 0x64657669 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +write 0xff000000 0x8 0x000000ff6c6f6766 +write 0xff000008 0x8 0x8d6c65652d736400 +outb 0xc040 0x69 +outw 0xc003 0x6769 +outb 0xc040 0x69 +readq 0xe0000074 +outb 0xc040 0x46 +clock_step +outb 0xc040 0x69 +clock_step +write 0x8 0x4 0x00000100 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +clock_step +write 0xc 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +outw 0xc003 0x6f00 +outb 0xc040 0x69 +outl 0xc053 0x6378616d +clock_step +write 0x10 0x4 0x000000ff +write 0xff000000 0x8 0x6465766963656d69 +write 0xff000008 0x8 0x740d00699b652d63 +write 0x69766560 0x8 0x000000ff6c46f228 +write 0x69766568 0x8 0x2d323334319c6c65 +outb 0xc051 0x6d +outb 0xc04f 0x61 +outb 0xc040 0x69 +clock_step +write 0x14 0x4 0x000000ff +write 0xff000000 0x8 0x0000010000000069 +write 0xff000008 0x8 0x636c395f61707269 +write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +EOF +``` + +# Additional information +The crash report triggered by the reproducer is: + +``` +[R +0.033173] outl 0xcf8 0x8000e900 +[S +0.033189] [R +0.033195] inw 0xcfc +[S +0.033205] [R +0.033212] outl 0xcf8 0x8000e920 +[S +0.033218] [R +0.033222] outl 0xcfc 0xffffffff +[S +0.033231] [R +0.033235] outl 0xcf8 0x8000e920 +[S +0.033241] [R +0.033245] inl 0xcfc +[S +0.033250] [R +0.033255] outl 0xcf8 0x8000e920 +[S +0.033261] [R +0.033265] outl 0xcfc 0xc001 +[S +0.033271] [R +0.033275] outl 0xcf8 0x8000e904 +[S +0.033281] [R +0.033285] inw 0xcfc +[S +0.033290] [R +0.033295] outl 0xcf8 0x8000e904 +[S +0.033300] [R +0.033306] outw 0xcfc 0x7 +[S +0.033755] [R +0.033767] outl 0xcf8 0x8000e904 +[S +0.033774] [R +0.033779] inw 0xcfc +[S +0.033785] [R +0.033792] outl 0xcf8 0x8000ef00 +[S +0.033798] [R +0.033802] inw 0xcfc +[S +0.033808] [R +0.033813] outl 0xcf8 0x8000ef10 +[S +0.033818] [R +0.033840] outl 0xcfc 0xffffffff +[S +0.033848] [R +0.033853] outl 0xcf8 0x8000ef10 +[S +0.033859] [R +0.033864] inl 0xcfc +[S +0.033870] [R +0.033875] outl 0xcf8 0x8000ef10 +[S +0.033880] [R +0.033884] outl 0xcfc 0xe0000000 +[S +0.033891] [R +0.033895] outl 0xcf8 0x8000ef04 +[S +0.033901] [R +0.033904] inw 0xcfc +[S +0.033909] [R +0.033916] outl 0xcf8 0x8000ef04 +[S +0.033922] [R +0.033926] outw 0xcfc 0x7 +[S +0.034381] [R +0.034389] outl 0xcf8 0x8000ef04 +[S +0.034395] [R +0.034399] inw 0xcfc +[S +0.034405] [R +0.034412] outl 0xcf8 0x8000ea00 +[S +0.034417] [R +0.034421] inw 0xcfc +[S +0.034427] [R +0.034431] outl 0xcf8 0x8000ea20 +[S +0.034437] [R +0.034441] outl 0xcfc 0xffffffff +[S +0.034448] [R +0.034452] outl 0xcf8 0x8000ea20 +[S +0.034457] [R +0.034463] inl 0xcfc +[S +0.034469] [R +0.034474] outl 0xcf8 0x8000ea20 +[S +0.034480] [R +0.034484] outl 0xcfc 0xc021 +[S +0.034490] [R +0.034494] outl 0xcf8 0x8000ea04 +[S +0.034500] [R +0.034504] inw 0xcfc +[S +0.034509] [R +0.034515] outl 0xcf8 0x8000ea04 +[S +0.034521] [R +0.034525] outw 0xcfc 0x7 +[S +0.034948] [R +0.034955] outl 0xcf8 0x8000ea04 +[S +0.034961] [R +0.034965] inw 0xcfc +[S +0.034971] [R +0.034989] outl 0xcf8 0x8000e800 +[S +0.034996] [R +0.035000] inw 0xcfc +[S +0.035005] [R +0.035010] outl 0xcf8 0x8000e820 +[S +0.035016] [R +0.035020] outl 0xcfc 0xffffffff +[S +0.035027] [R +0.035033] outl 0xcf8 0x8000e820 +[S +0.035039] [R +0.035043] inl 0xcfc +[S +0.035048] [R +0.035053] outl 0xcf8 0x8000e820 +[S +0.035059] [R +0.035065] outl 0xcfc 0xc041 +[S +0.035071] [R +0.035075] outl 0xcf8 0x8000e804 +[S +0.035081] [R +0.035084] inw 0xcfc +[S +0.035089] [R +0.035094] outl 0xcf8 0x8000e804 +[S +0.035100] [R +0.035103] outw 0xcfc 0x7 +[S +0.035525] [R +0.035532] outl 0xcf8 0x8000e804 +[S +0.035538] [R +0.035542] inw 0xcfc +[S +0.035548] [R +0.035553] outl 0xcf8 0x8000fa00 +[S +0.035558] [R +0.035562] inw 0xcfc +[S +0.035567] [R +0.035572] outl 0xcf8 0x8000fa20 +[S +0.035578] [R +0.035581] outl 0xcfc 0xffffffff +[S +0.035589] [R +0.035594] outl 0xcf8 0x8000fa20 +[S +0.035600] [R +0.035604] inl 0xcfc +[S +0.035609] [R +0.035613] outl 0xcf8 0x8000fa20 +[S +0.035618] [R +0.035623] outl 0xcfc 0xc061 +[S +0.035629] [R +0.035633] outl 0xcf8 0x8000fa24 +[S +0.035638] [R +0.035642] outl 0xcfc 0xffffffff +[S +0.035648] [R +0.035652] outl 0xcf8 0x8000fa24 +[S +0.035658] [R +0.035664] inl 0xcfc +[S +0.035669] [R +0.035673] outl 0xcf8 0x8000fa24 +[S +0.035679] [R +0.035683] outl 0xcfc 0xe0001000 +[S +0.035689] [R +0.035696] outl 0xcf8 0x8000fa04 +[S +0.035702] [R +0.035706] inw 0xcfc +[S +0.035711] [R +0.035716] outl 0xcf8 0x8000fa04 +[S +0.035722] [R +0.035725] outw 0xcfc 0x7 +[S +0.036402] [R +0.036412] outl 0xcf8 0x8000fa04 +[S +0.036418] [R +0.036422] inw 0xcfc +[S +0.036434] [R +0.036442] outl 0xcf8 0x8000ea20 +[S +0.036448] [R +0.036463] outl 0xcfc 0x625f69a0 +[S +0.036906] [I +0.036981] CLOSED +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x0 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xcf8 0x8000ef76 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xcfc 0x6563 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] inb 0xc000 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x4 0x4 0x64657669 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x000000ff6c6f6766 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x8d6c65652d736400 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6769 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] readq 0xe0000074 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x46 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x8 0x4 0x00000100 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xc 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outw 0xc003 0x6f00 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outl 0xc053 0x6378616d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x6465766963656d69 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x740d00699b652d63 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766560 0x8 0x000000ff6c46f228 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x69766568 0x8 0x2d323334319c6c65 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc051 0x6d +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc04f 0x61 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] outb 0xc040 0x69 +x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] clock_step +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x14 0x4 0x000000ff +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000000 0x8 0x0000010000000069 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0xff000008 0x8 0x636c395f61707269 +[DMA] x86_64: GLib: g_timer_elapsed: assertion 'timer != NULL' failed +[R +0.000000] write 0x10000 0x10 0x000000ff6c46f2282d00363939333336 +qemu-fuzz-x86_64: ../hw/usb/core.c:744: struct USBEndpoint *usb_ep_get(USBDevice *, int, int): Assertion `pid == USB_TOKEN_IN || pid == USB_TOKEN_OUT' failed. +==892641== ERROR: libFuzzer: deadly signal + #0 0x557dd985fc41 in __sanitizer_print_stack_trace (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x20b2c41) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #1 0x557dd97cfa58 in fuzzer::PrintStackTrace() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2022a58) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #2 0x557dd97b5ae3 in fuzzer::Fuzzer::CrashCallback() (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2008ae3) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #3 0x7fd7e623c45f (/lib/x86_64-linux-gnu/libc.so.6+0x3c45f) (BuildId: d320ce4e63925d698610ed423fc4b1f0e8ed51f1) + #4 0x7fd7e629152a in __pthread_kill_implementation nptl/pthread_kill.c:43:17 + #5 0x7fd7e629152a in __pthread_kill_internal nptl/pthread_kill.c:78:10 + #6 0x7fd7e629152a in pthread_kill nptl/pthread_kill.c:89:10 + #7 0x7fd7e623c3b5 in raise signal/../sysdeps/posix/raise.c:26:13 + #8 0x7fd7e622287b in abort stdlib/abort.c:79:7 + #9 0x7fd7e622279a in __assert_fail_base assert/assert.c:92:3 + #10 0x7fd7e6233b65 in __assert_fail assert/assert.c:101:3 + #11 0x557dda3b67c6 in usb_ep_get /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/core.c:744:5 + #12 0x557dda3d8820 in uhci_handle_td /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:819:14 + #13 0x557dda3d41ed in uhci_process_frame /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1022:15 + #14 0x557dda3cbf7e in uhci_frame_timer /home/hypervisor/qemu_fuzz/qemu/build2/../hw/usb/hcd-uhci.c:1121:9 + #15 0x557ddb90c0ff in timerlist_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:576:9 + #16 0x557ddb90d3e8 in qemu_clock_run_timers /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:590:12 + #17 0x557ddb90d3e8 in qemu_clock_advance_virtual_time /home/hypervisor/qemu_fuzz/qemu/build2/../util/qemu-timer.c:696:9 + #18 0x557dda67fa2f in qtest_process_command /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:722:9 + #19 0x557dda67b3bb in qtest_process_inbuf /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:776:9 + #20 0x557dda67acf6 in qtest_server_inproc_recv /home/hypervisor/qemu_fuzz/qemu/build2/../system/qtest.c:907:9 + #21 0x557ddb5fa3e2 in qtest_sendf /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:640:5 + #22 0x557ddb5fa4f4 in qtest_clock_step_next /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/libqtest.c:1009:5 + #23 0x557ddb67c2ef in generic_fuzz /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/generic_fuzz.c:667:13 + #24 0x557ddb66e807 in LLVMFuzzerTestOneInput /home/hypervisor/qemu_fuzz/qemu/build2/../tests/qtest/fuzz/fuzz.c:158:5 + #25 0x557dd97b6f52 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2009f52) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #26 0x557dd97a1080 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff4080) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #27 0x557dd97a6d07 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1ff9d07) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #28 0x557dd97d0292 in main (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x2023292) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) + #29 0x7fd7e6223a8f in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 + #30 0x7fd7e6223b48 in __libc_start_main csu/../csu/libc-start.c:360:3 + #31 0x557dd979b884 in _start (/home/hypervisor/qemu_fuzz/qemu/build2/qemu-fuzz-x86_64+0x1fee884) (BuildId: 1208fb4c12f2da2381e7763dabbbdabaf2db65e5) +``` diff --git a/results/classifier/zero-shot/108/KVM/2573 b/results/classifier/zero-shot/108/KVM/2573 new file mode 100644 index 00000000..7b49e088 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2573 @@ -0,0 +1,24 @@ +KVM: 0.980 +device: 0.873 +vnc: 0.789 +graphic: 0.704 +performance: 0.700 +files: 0.670 +boot: 0.559 +semantic: 0.555 +permissions: 0.540 +PID: 0.485 +socket: 0.455 +debug: 0.429 +network: 0.376 +other: 0.303 + +RISC-V: Executing floating point instruction in VS mode under KVM acceleration leads to crash +Description of problem: +Executing `fcvt.d.w fa5,a5` in VS mode leads to crash. +Steps to reproduce: +1. Download the Ubuntu 24.10 image https://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/oracular-preinstalled-server-riscv64.img.xz +2. On your amd64 system launch a VM using -accel tcg +3. Inside the VM launch a new VM using -accel kvm with the payload mentioned above +Additional information: +For more details see https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2077731 diff --git a/results/classifier/zero-shot/108/KVM/2658 b/results/classifier/zero-shot/108/KVM/2658 new file mode 100644 index 00000000..8f6d88e4 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2658 @@ -0,0 +1,16 @@ +KVM: 0.953 +device: 0.743 +performance: 0.566 +network: 0.452 +graphic: 0.307 +boot: 0.287 +debug: 0.282 +semantic: 0.183 +vnc: 0.048 +permissions: 0.017 +other: 0.016 +PID: 0.013 +socket: 0.007 +files: 0.006 + +How to simulate the L2MERRSR_EL1 register in KVM mode？ diff --git a/results/classifier/zero-shot/108/KVM/2692 b/results/classifier/zero-shot/108/KVM/2692 new file mode 100644 index 00000000..c6fd32c7 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/2692 @@ -0,0 +1,16 @@ +KVM: 0.980 +device: 0.799 +network: 0.635 +socket: 0.570 +performance: 0.556 +debug: 0.337 +graphic: 0.319 +semantic: 0.290 +files: 0.261 +PID: 0.246 +boot: 0.219 +other: 0.129 +vnc: 0.128 +permissions: 0.074 + +Using the ldp instruction to access the I/O address space in KVM mode causes an exception diff --git a/results/classifier/zero-shot/108/KVM/391880 b/results/classifier/zero-shot/108/KVM/391880 new file mode 100644 index 00000000..a187192b --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/391880 @@ -0,0 +1,29 @@ +KVM: 0.922 +graphic: 0.908 +device: 0.825 +performance: 0.791 +network: 0.622 +vnc: 0.573 +semantic: 0.547 +other: 0.475 +socket: 0.474 +files: 0.428 +boot: 0.381 +debug: 0.366 +PID: 0.353 +permissions: 0.273 + +migrate exec hangs for several minutes if the pipe is closed before all its data is written + +Binary package hint: kvm + +Using + + migrate "exec:true" + +in the monitor hangs the VM for several minutes. What I expect is that the VM stops attempting to migrate after the pipe has been closed. + +Indicating a background migrate with -d doesn't help. Presumably the migration is not backgrounded until a certain amount of data is written to the pipe, or the migration times out What I expect is that the migration is backgrounded immediately. + +I can reproduce this in Lucid. Like the other related bug report, I don't have a strong opinion on the feature request, though it seems reasonable. We will defer to Upstream's decision on this one. Thanks! + diff --git a/results/classifier/zero-shot/108/KVM/528 b/results/classifier/zero-shot/108/KVM/528 new file mode 100644 index 00000000..c8e2e9d2 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/528 @@ -0,0 +1,16 @@ +KVM: 0.969 +device: 0.816 +performance: 0.677 +debug: 0.583 +files: 0.493 +graphic: 0.490 +vnc: 0.424 +PID: 0.392 +boot: 0.366 +semantic: 0.360 +other: 0.165 +network: 0.131 +permissions: 0.076 +socket: 0.068 + +arm: trying to use KVM with an EL3-enabled CPU hits an assertion failure diff --git a/results/classifier/zero-shot/108/KVM/563 b/results/classifier/zero-shot/108/KVM/563 new file mode 100644 index 00000000..37d0b984 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/563 @@ -0,0 +1,16 @@ +KVM: 0.998 +device: 0.974 +performance: 0.813 +boot: 0.597 +graphic: 0.404 +semantic: 0.316 +permissions: 0.300 +socket: 0.262 +vnc: 0.239 +network: 0.203 +PID: 0.166 +files: 0.138 +debug: 0.046 +other: 0.037 + +KVM ubuntu 20 VPS on Ryzen 9 5950X diff --git a/results/classifier/zero-shot/108/KVM/73 b/results/classifier/zero-shot/108/KVM/73 new file mode 100644 index 00000000..6fddd597 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/73 @@ -0,0 +1,16 @@ +KVM: 0.971 +device: 0.860 +debug: 0.667 +performance: 0.549 +other: 0.486 +boot: 0.392 +graphic: 0.365 +semantic: 0.250 +PID: 0.194 +vnc: 0.147 +network: 0.145 +socket: 0.087 +files: 0.044 +permissions: 0.020 + +KVM Windows 98 sound card passthrough is not working for DOS programs.. diff --git a/results/classifier/zero-shot/108/KVM/735 b/results/classifier/zero-shot/108/KVM/735 new file mode 100644 index 00000000..fc6f0a00 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/735 @@ -0,0 +1,41 @@ +KVM: 0.962 +graphic: 0.944 +debug: 0.908 +device: 0.737 +performance: 0.732 +vnc: 0.631 +PID: 0.515 +semantic: 0.495 +network: 0.489 +socket: 0.483 +files: 0.456 +permissions: 0.438 +boot: 0.329 +other: 0.238 + +softmmu 'at' not behaving +Description of problem: +This looks like a bug to me, please correct if I'm wrong. The execution context is EL2 here and we run KVM vms on top of the system emulation. Anyway, here we have stopped in the EL2 and want to translate a virtual address '0' with 'at'. While the '0' itself is not mapped, something in the first gigabyte is, and the softmmu refuses to walk to it: + +0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0 +0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1 + +(gdb) info registers x0 x1 +x0 0x0 0 +x1 0x809 2057 + +So that would be translation fault level 0, stage 1 if I'm not mistaken. + +(gdb) info all-registers TCR_EL1 VTCR_EL2 TTBR1_EL1 +TCR_EL1 0x400035b5503510 18014629184681232 +VTCR_EL2 0x623590 6436240 +TTBR1_EL1 0x304000041731001 217298683118686209 + +(gdb) p print_table(0x41731000) +000:0x000000ffff9803 256:0x000000fffff803 507:0x00000041fbc803 +508:0x000000ff9ef803 + +The first gigabyte is populated, yet the 'at' knows nothing about it. Did I miss something? This seems to be working fine on the hardware. +Steps to reproduce: +1. Stop in the EL2 while the linux is running (GDB) +2. Use something along the lines of this function to translate any kernel virtual address: https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74 diff --git a/results/classifier/zero-shot/108/KVM/797905 b/results/classifier/zero-shot/108/KVM/797905 new file mode 100644 index 00000000..5b061613 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/797905 @@ -0,0 +1,67 @@ +KVM: 0.990 +other: 0.962 +performance: 0.959 +PID: 0.927 +permissions: 0.925 +files: 0.916 +semantic: 0.913 +device: 0.909 +graphic: 0.889 +network: 0.874 +debug: 0.822 +vnc: 0.818 +socket: 0.767 +boot: 0.710 + +virsh live migration + +Hi, +i do not manage to do a virsh migrate live command. +Using Ubuntu Server 10.04 x64 + +root@svr50abl:~# virsh list + Id Nome Estado +---------------------------------- + 18 Winxp executando + 19 teste executando + +root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system +root@10.1.5.1's password: +erro: unable to set user and group to '116:127' on '/var/lib/libvirt/images/teste.img': No such file or directory + +teste.img has root:root (xrw) + +10.1.5.1 is a functional kvm host too + +On Wed, Jun 15, 2011 at 9:35 PM, Marcus Paiva <email address hidden> wrote: +> Public bug reported: +> +> Hi, +> i do not manage to do a virsh migrate live command. +> Using Ubuntu Server 10.04 x64 +> +> root@svr50abl:~# virsh list +> Id Nome Estado +> ---------------------------------- +> 18 Winxp executando +> 19 teste executando +> +> root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system +> root@10.1.5.1's password: +> erro: unable to set user and group to '116:127' on '/var/lib/libvirt/images/teste.img': No such file or directory +> +> teste.img has root:root (xrw) + +The image file should be shared (for example over NFS) and visible on +both hosts. It looks like you are migrating to a host that does not +have /var/lib/libvirt/images/teste.img. + +Please check with libvirt, this is not a QEMU bug. + +Stefan + + +You can try to copy the image file from source to destination before migration. + +Closing, as this is a libvirt issue, not a QEMU bug. + diff --git a/results/classifier/zero-shot/108/KVM/916 b/results/classifier/zero-shot/108/KVM/916 new file mode 100644 index 00000000..88fc3710 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/916 @@ -0,0 +1,26 @@ +KVM: 0.977 +graphic: 0.881 +device: 0.851 +performance: 0.727 +PID: 0.702 +semantic: 0.689 +vnc: 0.607 +debug: 0.585 +socket: 0.514 +network: 0.497 +files: 0.481 +boot: 0.468 +permissions: 0.372 +other: 0.326 + +QEMU system emulators immediately crash on AMD hosts when KVM is used +Description of problem: +``` +$ qemu-system-x86_64 -accel kvm +qemu-system-x86_64: ../target/i386/kvm/kvm-cpu.c:105: kvm_cpu_xsave_init: Assertion `esa->size == eax' failed. +Aborted (core dumped) +``` + +This is a regression introduced in + +https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg04312.html diff --git a/results/classifier/zero-shot/108/KVM/965867 b/results/classifier/zero-shot/108/KVM/965867 new file mode 100644 index 00000000..69c10e95 --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/965867 @@ -0,0 +1,317 @@ +KVM: 0.930 +permissions: 0.895 +other: 0.895 +performance: 0.879 +boot: 0.874 +graphic: 0.870 +files: 0.865 +device: 0.863 +vnc: 0.847 +debug: 0.843 +semantic: 0.843 +socket: 0.840 +network: 0.836 +PID: 0.810 + +9p virtual file system on qemu slow + +Hi, +The 9p virtual file system is slow. Several examples below: +--------------------------------------------------------- +Host for the first time: +$ time ls bam.unsorted/ +........................... +real 0m0.084s +user 0m0.000s +sys 0m0.028s +-------------------------------------------------- +Host second and following: + +real 0m0.009s +user 0m0.000s +sys 0m0.008s +------------------------------------------------------ +VM for the first time: +$ time ls bam.unsorted/ +................................ +real 0m23.141s +user 0m0.064s +sys 0m2.156s +------------------------------------------------------ +VM for the second time +real 0m3.643s +user 0m0.024s +sys 0m0.424s +---------------------------------------------------- + +Copy on host: +$ time cp 5173T.root.bak test.tmp +real 0m30.346s +user 0m0.004s +sys 0m5.324s + +$ ls -lahs test.tmp +2.7G -rw------- 1 oneadmin cloud 2.7G Mar 26 21:47 test.tmp + +--------------------------------------------------- +$ copy on VM for the same file + +time cp 5173T.root.bak test.tmp + +real 5m46.978s +user 0m0.352s +sys 1m38.962s + +Thanks for taking the time to report this bug. Which release are you currently using? Is this performance a regression over past releases? Would it be possible for you to test with upstream qemu to see whether performance has improved? + +Hi Serge, + +Here are info: + +max@s0:/var/lib/one/var$ uname -a +Linux s0 3.2.0-20-generic #33-Ubuntu SMP Tue Mar 27 16:42:26 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux + + +max@s0:/var/lib/one/var$ kvm --version +QEMU emulator version 1.0 (qemu-kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard + + + ps aux| grep kvm | grep one-52 +oneadmin 62687 28.9 0.3 25283292 839204 ? Sl 01:31 2:22 /usr/bin/kvm -S -M pc-1.0 -enable-kvm -m 20040 -smp 60,sockets=60,cores=1,threads=1 -name one-52 -uuid 30c77a47-85c4-65dd-6c21-9d9b3e66cabe -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/one-52.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -drive file=/var/lib/one/var//52/images/disk.0,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/var/lib/one/var//52/images/disk.1,if=none,id=drive-virtio-disk4,format=raw,cache=writeback -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk4,id=virtio-disk4 -fsdev local,security_model=mapped,id=fsdev-fs0,path=/tank/biouml-shared -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=VirtFS,bus=pci.0,addr=0x3 -netdev tap,fd=21,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=02:00:c0:a8:02:1e,bus=pci.0,addr=0x4 -usb -device usb-mouse,id=input0 -vnc 0.0.0.0:52 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -cpu host + + +Thanks. + +I'm posting a new package based on today's git head of upstream at ppa:ubuntu-virt/ppa. When (and if) that builds, is it possible for you to try with that version? Then we will know whether to file this bug upstream, or find and cherrypick the fixes. + +Hi Serge, + +syslogs on host completely clean for all my 3 bugs. No messages at all regarding any errors. + +I just added this repository. I can basically update now daily as I have to reboot server daily to make kvm working. +I installed qemu version: 1.0+noroms-20120220-0ubuntu1. + + + +Quoting max (<email address hidden>): +> Hi Serge, +> +> syslogs on host completely clean for all my 3 bugs. No messages at all +> regarding any errors. + +Thanks. + +> I just added this repository. I can basically update now daily as I have to reboot server daily to make kvm working. +> I installed qemu version: 1.0+noroms-20120220-0ubuntu1. + +1.0+noroms-20120330-0ubuntu1 should now be available, though of course +if the issue is fixed in 1.0+noroms-20120220-0ubuntu1 then that's even +more helpful :) + + +Hi Serge, + +I tried new build. It is not working for me. I got this message: + +max@s0:/var/lib/one/var$ virsh create 52/deployment.0 +error: Failed to create domain from 52/deployment.0 +error: internal error process exited while connecting to monitor: kvm: -fsdev local,security_model=mapped,id=fsdev-fs0,path=/tank/biouml-shared: there is no option group "fsdev" +fsdev is not supported by this qemu build. + + +Drat. + +I'll simply need to try to reproduce. + +Hi Serge, + +qemu build 0330 does not support -fsdev. I was not able to start kvm with 9p at all. + +If you will make another build I will try it too. + +Thanks + +Quoting max (<email address hidden>): +> Hi Serge, +> +> qemu build 0330 does not support -fsdev. I was not able to start kvm +> with 9p at all. +> +> If you will make another build I will try it too. + +Thanks. Sorry about that. I'm hoping I just used an old packaging +tree as my starting base, will re-try, and post here when it has +built. + + +Hi, + +version 1.0+noroms-20120330-0ubuntu3 has been built. Could you verify whether that fixes the issue (as well as your others)? + +Thanks Serge, + +I installed it and now testing. Let's wait for several days. I will write if have any issues. + +Hi Serge, +Stability bugs was fixed in KVM, thanks! +Unfortunately this one still here: + +---------------------------------------------------------------------------- +VM: + + ls -las XXXXX.bam +14537970 -rw-r--r-- 1 10001 cloud 14885246140 Mar 23 12:19 XXXXX.bam + + +time cp XXXX.bam test.tmp + +real 14m45.580s +user 0m0.420s +sys 1m45.823s + +~16 Mb/sec +-------------------------------------------------------------- +Host: +$ ls -las 5173N_sorted_dedup_rg_dd2_kar.chr4.ra.dd.recal.bam +15220278 -rw-r--r-- 1 oneadmin cloud 15583853314 Mar 27 18:53 YYYY.bam + + +time cp YYYYY.bam test.tmp + +real 4m38.525s +user 0m0.048s +sys 1m11.124s + +~53MB/sec + +Thanks, Max. Marked as affecting upstream QEMU per the last comment. + +Can you try with security_model=passthrough? + +One of possible problems could be a block size. In this case I am using ZFS with raidZ 4+1 drives. Each drive has 4Kb block. So optimal block size is 16384 bytes. By optimizing block size it possible to improve performance 10 folds but 9p stably provides 10 folds worse performance than native writes. + +Some extra tests: +--------------------- +VM - mapped + +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 20.7879 s, 2.5 MB/s + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 74.4378 s, 22.0 MB/s +------------------------------------------------------------ +Host: +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 1.60118 s, 32.0 MB/s + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 4.89932 s, 334 MB/s + + +Iggy: I has issue with permission in passthrough mode. Can you give an idea how to setup permissions in this mode? + +>>>Can you try with security_model=passthrough? +It provides the same results, see below: + +$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 19.8581 s, 2.6 MB/s + + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 72.3009 s, 22.7 MB/s + + +Hi Max, + +Could you try passing msize=262144 for 9p mount point and post the results? + +Host: +[root@llm116 media]# ls -lhas file +1.1G -rw-r--r-- 1 root root 1.0G Apr 26 11:05 file + +[root@llm116 media]# dd if=/dev/zero of=file bs=1M count=1024 +1024+0 records in +1024+0 records out +1073741824 bytes (1.1 GB) copied, 0.700828 s, 1.5 GB/s + +[root@llm116 media]# time cp file file2 + +real 0m6.353s +user 0m0.007s +sys 0m1.520s + +VM: + +[root@qemu-img-64 pass]# time cp file 9p_file + +real 0m12.261s +user 0m0.154s +sys 0m2.582s + +[root@qemu-img-64 pass]# dd if=/dev/zero of=file.9 bs=1M count=1024 +1024+0 records in +1024+0 records out +1073741824 bytes (1.1 GB) copied, 2.07335 s, 518 MB/s + +[root@qemu-img-64 pass]# mount +[snip] +v_pass on /pass type 9p (rw,trans=virtio,version=9p2000.L,msize=262144) +[/snip] + +Hi Mohan, +this parameter provide significant improvement in big file access/write: +-------------------------------------------------------------------------------------------- +VirtFS on /srv/shared type 9p (rw,trans=virtio,version=9p2000.L,msize=262144) + +$ dd if=/dev/zero of=test count=100000 bs=16384 +100000+0 records in +100000+0 records out +1638400000 bytes (1.6 GB) copied, 36.3589 s, 45.1 MB/s + +l$ dd if=/dev/zero of=test count=100000 +100000+0 records in +100000+0 records out +51200000 bytes (51 MB) copied, 25.6597 s, 2.0 MB/s + +$ dd if=/dev/zero of=test count=1024 bs=262144 +1024+0 records in +1024+0 records out +268435456 bytes (268 MB) copied, 3.41936 s, 78.5 MB/s + +Speed of copy for large file ~45MB/s (read and write from the same disk). +--------------------------------------------------------------------------------------------- +But Host: +time ls -lahs bam.unsorted/ +many files: +real 0m0.053s +user 0m0.004s +sys 0m0.036s + +VM: +real 0m4.449s +user 0m0.012s +sys 0m0.136s +-------------------------------------------------------- +So we have delays on the first file access. +Is it possible to resolve this issue? + + + +Can you still reproduce this problem with the latest version of QEMU (currently version 2.9.0)? + +[Expired for QEMU because there has been no activity for 60 days.] + +[Expired for qemu-kvm (Ubuntu) because there has been no activity for 60 days.] + diff --git a/results/classifier/zero-shot/108/KVM/966316 b/results/classifier/zero-shot/108/KVM/966316 new file mode 100644 index 00000000..098d637f --- /dev/null +++ b/results/classifier/zero-shot/108/KVM/966316 @@ -0,0 +1,39 @@ +KVM: 0.939 +graphic: 0.893 +semantic: 0.818 +device: 0.785 +other: 0.780 +performance: 0.762 +network: 0.673 +files: 0.610 +PID: 0.601 +socket: 0.591 +vnc: 0.499 +permissions: 0.464 +boot: 0.433 +debug: 0.396 + +Can't load Android VBOX image or even linux test image as well + +Can't load Android X86 ICS 4.0 VBOX image. +It worked with previous version before adding /qemu/hw/pc_sysfw.c file ( tested with version 1.0 ). + +x86_64-softmmu# ./qemu-system-x86_64 ~/kvm-test-image/x86-linux-0.2.img +qemu: PC system firmware (pflash) must be a multiple of 0x1000 + +In QEMU website (http://wiki.qemu.org/Testing), there is a test image for linux +but, new version can't load the image as well because of upper error. +linux-0.2.img.bz2 (8 MB) Small Linux disk image containing a 2.6.20 Linux kernel, X11 and various utilities to test QEMU + +I'm getting this same error with qemu v1.1.1 on a RAW formatted disk image of windows XP that used to work. + +> qemu -m 1024 -hda xp.img -localtime -net user +qemu: PC system firmware (pflash) must be a multiple of 0x1000 + +I've no idea what this error could mean =) + +Triaging old bug tickets ... Can you still reproduce this problem with +the latest version of QEMU? + +[Expired for QEMU because there has been no activity for 60 days.] + |