diff options
Diffstat (limited to '')
| -rw-r--r-- | results/classifier/108/other/1829 | 103 | ||||
| -rw-r--r-- | results/classifier/108/other/1829079 | 50 | ||||
| -rw-r--r-- | results/classifier/108/other/1829242 | 75 | ||||
| -rw-r--r-- | results/classifier/108/other/1829498 | 64 | ||||
| -rw-r--r-- | results/classifier/108/other/1829576 | 91 | ||||
| -rw-r--r-- | results/classifier/108/other/1829696 | 405 | ||||
| -rw-r--r-- | results/classifier/108/other/1829779 | 95 | ||||
| -rw-r--r-- | results/classifier/108/other/1829945 | 64 |
8 files changed, 947 insertions, 0 deletions
diff --git a/results/classifier/108/other/1829 b/results/classifier/108/other/1829 new file mode 100644 index 000000000..35ba11c21 --- /dev/null +++ b/results/classifier/108/other/1829 @@ -0,0 +1,103 @@ +other: 0.886 +vnc: 0.879 +KVM: 0.851 +debug: 0.839 +permissions: 0.831 +performance: 0.826 +network: 0.816 +graphic: 0.801 +socket: 0.778 +semantic: 0.770 +device: 0.745 +PID: 0.738 +files: 0.704 +boot: 0.642 + +DoS via assert failure by guest user +Description of problem: +As root in guest VM user can execute special script, which crashes the whole VM with error + +```plaintext +hw/display/qxl.c:1594 inside of function void qxl_set_mode(PCIQXLDevice *, unsigned int, int): Assertion `qxl_add_memslot(d, 0, devmem, QXL_SYNC) == 0` failed +``` +Steps to reproduce: +1. This bug can be reproduced with: + + ```bash + cat << EOF | ./build/qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio + outl 0xcf8 0x8000101c + outl 0xcfc 0xc000 + outl 0xcf8 0x80001001 + outl 0xcfc 0x01000000 + outl 0xc006 0x00 + EOF + ``` +2. Also, we can execute this python3 script inside guest VM as root (to invoke VM use command: **_qemu-system-x86_64 -vga qxl -hda debian.img -m 2048 -nodefaults_**): + + ```python + import os + f = os.open("/dev/port", os.O_RDWR|os.O_NDELAY) + l = os.lseek(f, 0xcf8, 0) + os.write(f, b'\x80\x00\x10\x1c') + l = os.lseek(f, 0xcfc, 0) + os.write(f, b'\xc0\x00') + l = os.lseek(f, 0xcf8, 0) + os.write(f, b'\x80\x00\x10\x01') + l = os.lseek(f, 0xcfc, 0) + os.write(f, b'\x01\x00\x00\x00') + l = os.lseek(f, 0xc006, 0) + os.write(f, b'\x00') + ``` + + This script causes VM to crash. + + [PoC_qxl-vga_crash.mkv](/uploads/7ee262c20dca69aa9417812f6a93a532/PoC_qxl-vga_crash.mkv) +Additional information: +This issue was found by fuzzing. Here is an auto-generated C source code for a test case that will reproduce the bug. + +```plaintext +/* + * Autogenerated Fuzzer Test Case + * + * Copyright (c) 2023 Artem Nasonov <anasonov@astralinux.ru> + * + * This work is licensed under the terms of the GNU GPL, version 2 or later. + * See the COPYING file in the top-level directory. + */ + +#include "qemu/osdep.h" + +#include "libqtest.h" + +/* + * cat << EOF | qemu-system-x86_64 -vga qxl -hda \ + * ~/Downloads/virtualdebian.img -m 2048 -nodefaults -qtest stdio + * outl 0xcf8 0x8000101c + * outl 0xcfc 0xc000 + * outl 0xcf8 0x80001001 + * outl 0xcfc 0x01000000 + * outl 0xc006 0x00 + * EOF +*/ +static void test_qxl_set_mode(void) +{ +QTestState *s = qtest_init("-vga qxl -m 2048 -nodefaults"); +qtest_outl(s, 0xcf8, 0x8000101c); +qtest_outl(s, 0xcfc, 0xc000); +qtest_outl(s, 0xcf8, 0x80001001); +qtest_outl(s, 0xcfc, 0x01000000); +qtest_outl(s, 0xc006, 0x00); +qtest_quit(s); +}int main(int argc, char **argv) +{ + const char *arch = qtest_get_arch(); + + g_test_init(&argc, &argv, NULL); + + if (strcmp(arch, "x86_64") == 0) { + qtest_add_func("fuzz/test_qxl_set_mode",test_qxl_set_mode); + } + + return g_test_run(); +} +``` diff --git a/results/classifier/108/other/1829079 b/results/classifier/108/other/1829079 new file mode 100644 index 000000000..0a14f0951 --- /dev/null +++ b/results/classifier/108/other/1829079 @@ -0,0 +1,50 @@ +graphic: 0.894 +other: 0.874 +files: 0.858 +semantic: 0.854 +performance: 0.768 +PID: 0.743 +debug: 0.656 +device: 0.644 +vnc: 0.636 +permissions: 0.613 +network: 0.516 +socket: 0.505 +boot: 0.458 +KVM: 0.312 + +Can't build static on ARM (Raspbian) + +I am trying to build static QEMU on Raspbian, chrooted into using systemd-nspawn with QEMU 4.0.0. +This is how my compiling looks: +https://pastebin.com/PYZYeRCN +Just the problematic part: +https://pastebin.com/7LxWPMxA +How I do the compiling: +https://pastebin.com/pYM17A6R (I plan to share this tutorial when it will work) +It is a coincidence, or the build fails because it cannot find lp11-kit. I did some symlinks: +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 /usr/lib/libp11-kit.so.0 +ln -s /usr/lib/arm-linux-gnueabihf/libp11-kit.so /usr/lib/libp11-kit.so +(should I also symlink libp11.so and libp11.so.2? I think I have installed all required p11 packages! + +Git commit hash: git rev-parse HEAD +e329ad2ab72c43b56df88b34954c2c7d839bb373 + +This looks Debian specific. Not sure why you have to install the p11-kit/libp11-dev/libp11-2 packages although. + +I agree with Philippe - if you have to symlink your libraries like this, it is certainly not a bug in QEMU, but a problem of your distro. So please report this issue in your distro bugtracker instead. + +You might find that adding --disable-tools to your configure line also helps in not trying to statically link random binaries you don't really want. + + +Well, the symlinks didn't resolve the issue. I just tried them to see if this will solve the issue. + +And I installed a lot of packages, blindly trying to solve this issue. Using full Raspbian instead of Raspbian Lite was also an attempt to do so. I'm just an advanced Linux user, not a developer! I will cut the list down to the necessary ones when I get it to compile! + +pmaydell: Thank you a lot, it compiles successfully with --disable-tools in configure. I have one question... does it affect how QEMU static binary works in any way? I'm just curious. + + + + +No, --disable-tools won't change the qemu-* binaries that are built. It just stops us trying to build some binaries like the 'ivshmem-client' one that was causing a problem for you. + diff --git a/results/classifier/108/other/1829242 b/results/classifier/108/other/1829242 new file mode 100644 index 000000000..2e39e9a67 --- /dev/null +++ b/results/classifier/108/other/1829242 @@ -0,0 +1,75 @@ +other: 0.924 +semantic: 0.921 +device: 0.916 +debug: 0.913 +PID: 0.909 +performance: 0.908 +network: 0.898 +KVM: 0.896 +graphic: 0.894 +socket: 0.882 +vnc: 0.872 +boot: 0.869 +permissions: 0.867 +files: 0.822 + +qemu on windows host exits after savevm command + +I'm running qemu-system-i386.exe 3.1.0 with this command line: +"C:\Program Files\qemu\qemu-system-i386.exe" -L C:\user\qemu\pc-bios\ -name win7 -m 4G -uuid 564db62e-e031-b5cf-5f34-a75f8cefa98e -rtc base=localtime -accel hax -hdd C:\VirtualMachines\Dev\Win10x64_VS17\swap.qcow "C:\VirtualMachines\qemu\qemu_win7.qcow" +Host OS Windows 10 x64, guest OS Wondows 7 x86. + +Wait till the OS loads, go to compat_monitor0 tab and enter command: +savevm loaded_win +After a few seconds qemu exits, running it another time and entering command: +info snapshots +says "There is no snapshot available". I've tried rinning it with -accel tcg, with same results. I've tried less memory (1G), same results. + +Hi Alex, + I'm not sure we've tried a savevm on a windows host; I don't have one easily available. +When you say 'after a few seconds qemu exits' - does it give any errors or crash or anything? + +Hi Alex, + I'm not sure we've tried a savevm on a windows host; I don't have one easily available. +When you say 'after a few seconds qemu exits' - does it give any errors or crash or anything? + +Hi, +No, no messages, no crash window which appears when windows catches unhandled exceptions in software. Looks as if there was an asynchronous command to exit during savevm which executed in parallel to the command. + +I think you'll have to break out a debugger on it to see why it's exiting; if you can break on any exit paths and get a backtrace we can have some more guesswork. + +To do this I must crosscompile qemu on a linux host and debug on a windows host. Is there a gdb for 64-bit windows, since windows debuggers don't understand DWARF debugging info, and is it possible to give him paths to source files, since paths on the build machine and the debugging machine will be different? + +Sorry, no idea - I don't know windows build/debug. +(I know the migration code that savevm uses, which is why I looked at this bug) + +Running the operation under debugger catches this error: +Critical error detected c0000374 +(2314.a54): Break instruction exception - code 80000003 (first chance) +ntdll!RtlIsNonEmptyDirectoryReparsePointAllowed+0x72: +00007ffe`0780b2d2 cc int 3 + +This error means that a heap corruption was detected. To find the place where the corruption occured, I've ran qemu under appverifier, which is some kind of ASAN\MSAN for windows. +The tool caught an access violation, the callstack seems to be not full, save_snapshot calls qemu_savevm_state_iterate, then a call to ram_save_iterate, then ram_find_and_save_block. But the address of the exception does not correspond to this function. +Disassembling qemu and searching for this address, I've found that it probably corresponds to this snippet in ram_save_host_page: + do { + /* Check the pages is dirty and if it is send it */ + if (!migration_bitmap_clear_dirty(rs, pss->block, pss->page)) { + pss->page++; + continue; + } + +The missing callstack part is probably ram_find_and_save_block calling ram_save_host_page at this place: + if (found) { + pages = ram_save_host_page(rs, &pss, last_stage); + } + +It seems that the compiler inlined several functions to ram_find_and_save_block and that is the reason for the partial stack. +Since I am still unable to see local variable values during debugging, I can't give more info now. +I think the bug can be found when running qemu on linux with ASAN\MSAN. When this does not find the bug, I do more debugging. +I want mention that the caught access violation is due to reading an invalid address. The bug found without appverifier is due to writing to an invalid address, so there may be several bugs. + +that code should be ok; if you can find it with a debug I'd try and figure out what block and page pss is currently pointing to. Is it normal RAM or something special? + +I'm still unable to see all locals, but can output some of them with printf. qemu_savevm_state_iterate is called 35 times, iterates over timer, COLOState, slirp, block and ram entrys, and the error is on handling ram entry. + diff --git a/results/classifier/108/other/1829498 b/results/classifier/108/other/1829498 new file mode 100644 index 000000000..a09e4b8ef --- /dev/null +++ b/results/classifier/108/other/1829498 @@ -0,0 +1,64 @@ +boot: 0.638 +graphic: 0.549 +device: 0.523 +semantic: 0.470 +other: 0.468 +performance: 0.308 +debug: 0.226 +permissions: 0.202 +PID: 0.172 +socket: 0.168 +vnc: 0.166 +network: 0.098 +files: 0.093 +KVM: 0.056 + +window 8 stuck during boot on Qemu + +Description of problem: +I've got windows 8 image(64 bit), installed on Qemu(x86-64_softmmu) and then i'm trying to boot/shutdown it in the same Qemu configuration. Windows 8 has feature - when you click "Shutdown" in UI, windows 8 doesn't actually power off, it goes to "Suspend to disc" ACPI state. After shutdown, i'm trying to boot it again, but it stucks during boot. + +I've discovered, that it hangs when windows 8 writes to AHCI's command register, AHCI triggers irq, but windows 8 sends EOI, don't accessing AHCI register,so irq line stills in high state, and irq will be injected again and again, while windows will send EOI on each AHCI interrupt. Strange thing is that it happens only on TCG mode or +with option "kernel-irqchip=off/split", with "kernel-irqchip=on" everything works ok(windows 8 accesses AHCI register and line goes to low state). + +Version-Release number of selected component (if applicable): +Qemu revision: d8276573da58e8ce78dab8c46dd660efd664bcb7 + + +Steps to Reproduce: +1. Install Windows 8 on QEMU(qemu command line: "-enable-kvm -m 1G -hda <image> -serial stdio -cpu core2duo -machine q35,kernel-irqchip=off" +2. Click shutdown in UI. +3. Try to boot again(it will stuck) +4. Kill Qemu and boot again, it will boot, now go to 2) :) + +What host kernel are you using? This sounds like a bug we used to have in KVM a while ago. Maybe it's back. + +The same problem was also alleviated by a guest driver update, are you using the initial release of Windows 8? + + + +My host kernel is 4.15.0-47. Windows 8 version is 6.3.9600. About KVM, i've got same problem in TCG mode. + +Drats, okay. I will investigate. (I can always hope for the easy answer...) + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/436 + + diff --git a/results/classifier/108/other/1829576 b/results/classifier/108/other/1829576 new file mode 100644 index 000000000..66cc8dee4 --- /dev/null +++ b/results/classifier/108/other/1829576 @@ -0,0 +1,91 @@ +permissions: 0.881 +vnc: 0.864 +other: 0.847 +semantic: 0.836 +device: 0.828 +KVM: 0.801 +boot: 0.796 +graphic: 0.791 +performance: 0.786 +debug: 0.780 +PID: 0.773 +socket: 0.755 +files: 0.739 +network: 0.725 + +QEMU-SYSTEM-PPC64 Regression QEMU-4.0.0 + +I have been using QEMU-SYSTEM-PPC64 v3.1.0 to run CentOS7 PPC emulated system. It stopped working when I upgraded to QEMU-4.0.0 . I downgraded back to QEMU-3.1.0 and it started working again. The problem is that my CentOS7 image will not boot up udner QEMU-4.0.0, but works fine under QEMU-3.1.0. + +I have an QCOW2 image available at https://www.mediafire.com/file/d8dda05ro85whn1/linux-centos7-ppc64.qcow2/file . NOTE: It is 15GB. Kind of large. + +I run it as follows: + + qemu-system-ppc64 \ + -name "CENTOS7-PPC64" \ + -cpu POWER7 -machine pseries \ + -m 4096 \ + -netdev bridge,id=netbr0,br=br0 \ + -device e1000,netdev=netbr0,mac=52:54:3c:13:21:33 \ + -hda "./linux-centos7-ppc64.qcow2" \ + -monitor stdio + +HOST: I am using Manjaro Linux on an Intel i7 machine with the QEMU packages installed via the package manager of the distribution. + +[jsantiago@jlsws0 ~]$ uname -a +Linux jlsws0.haivision.com 4.19.42-1-MANJARO #1 SMP PREEMPT Fri May 10 20:52:43 UTC 2019 x86_64 GNU/Linux + +jsantiago@jlsws0 ~]$ cpuinfo +Intel(R) processor family information utility, Version 2019 Update 3 Build 20190214 (id: b645a4a54) +Copyright (C) 2005-2019 Intel Corporation. All rights reserved. + +===== Processor composition ===== +Processor name : Intel(R) Core(TM) i7-6700K +Packages(sockets) : 1 +Cores : 4 +Processors(CPUs) : 8 +Cores per package : 4 +Threads per core : 2 + +===== Processor identification ===== +Processor Thread Id. Core Id. Package Id. +0 0 0 0 +1 0 1 0 +2 0 2 0 +3 0 3 0 +4 1 0 0 +5 1 1 0 +6 1 2 0 +7 1 3 0 +===== Placement on packages ===== +Package Id. Core Id. Processors +0 0,1,2,3 (0,4)(1,5)(2,6)(3,7) + +===== Cache sharing ===== +Cache Size Processors +L1 32 KB (0,4)(1,5)(2,6)(3,7) +L2 256 KB (0,4)(1,5)(2,6)(3,7) +L3 8 MB (0,1,2,3,4,5,6,7) + +I suspect that this may be related to the VSR register conversion. Can you try applying all of the patches below on top of 4.0 to see if they resolve the issue? + +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01254.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01256.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01257.html +https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg01260.html + + +I applied the four patches you indicated and the image boots up and runs. Everything seems to be working now. Thank You. + +I also have a regression issue between 3.1.0 and 4.0.0 (actually latest git) on qemu-system-ppc64 but it involves an AIX guest instead (fail to boot). Should I open a new ticket or hop on this one ? + +David has already queued the patches in his ppc-for-4.1 branch at https://github.com/dgibson/qemu/commits/ppc-for-4.1 so they will get merged soon. If you're working with git then I'd try testing the queued branch first and see if that resolves the issue. + +Once the patches have been applied to master we'll add a CC to the stable list so the fixes will be included in the next 4.0 update. + +Same thing here using https://github.com/dgibson/qemu/commits/ppc-for-4.1 ... It might be a completely different problem (athough it looks like a MMU problem). + +Is this fixed now? Can we mark as fix committed? + +It is fixed with the 4.1.0 release. Thank you. + diff --git a/results/classifier/108/other/1829696 b/results/classifier/108/other/1829696 new file mode 100644 index 000000000..38cceec3a --- /dev/null +++ b/results/classifier/108/other/1829696 @@ -0,0 +1,405 @@ +performance: 0.830 +KVM: 0.826 +permissions: 0.812 +vnc: 0.810 +graphic: 0.783 +other: 0.778 +device: 0.773 +PID: 0.732 +boot: 0.706 +semantic: 0.704 +socket: 0.702 +network: 0.688 +debug: 0.675 +files: 0.653 + +qemu-kvm takes 100% CPU when running redhat/centos 7.6 guest VM OS + +Description +=========== +When running redhat or centos 7.6 guest os on vm, +the cpu usage is very low on vm(100% idle), but on host, +qemu-kvm reports 100% cpu busy usage. + +After searching some related bugs report, +I suspect that it is due to the clock settings in vm's domain xml. +My Openstack cluster uses the default clock settings as follow: + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> +And in this report, https://bugs.launchpad.net/qemu/+bug/1174654 +it claims that <timer name='rtc' track='guest'/> can solve the 100% cpu usage problem when using Windows Image Guest OS, +but I makes some tests, the solusion dose not work for me. + + +Steps to reproduce +================== +* create a vm using centos or redhat 7.6 image +* using sar tool inside vm and host to check the cpu usage, and compare them + + +Expected result +=============== +host's cpu usage report should be same with vm's cpu usage + + +Actual result +============= +vm's cpu usage is 100% idle, host's cpu usage is 100% busy + + +Environment +=========== +1. Exact version of OpenStack you are running. +# rpm -qa | grep nova +openstack-nova-compute-13.1.2-1.el7.noarch +python2-novaclient-3.3.2-1.el7.noarch +python-nova-13.1.2-1.el7.noarch +openstack-nova-common-13.1.2-1.el7.noarch + +2. Which hypervisor did you use? + (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...) + What's the version of that? +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +# /usr/libexec/qemu-kvm --version +QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + + +Logs & Configs +============== +The VM xml: +<domain type='kvm' id='29'> + <name>instance-00005022</name> + <uuid>7f5a66a5-****-****-****-75dec****bbb</uuid> + <metadata> + <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0"> + <nova:package version="13.1.2-1.el7"/> + <nova:name>*******</nova:name> + <nova:creationTime>2019-05-20 03:08:46</nova:creationTime> + <nova:flavor name="2d2dab36-****-****-****-246e9****110"> + <nova:memory>2048</nova:memory> + <nova:disk>12</nova:disk> + <nova:swap>2048</nova:swap> + <nova:ephemeral>0</nova:ephemeral> + <nova:vcpus>1</nova:vcpus> + </nova:flavor> + <nova:owner> + <nova:user uuid="********************">****</nova:user> + <nova:project uuid="********************">****</nova:project> + </nova:owner> + <nova:root type="image" uuid="4496a420-****-****-****-b50f****ada3"/> + </nova:instance> + </metadata> + <memory unit='KiB'>2097152</memory> + <currentMemory unit='KiB'>2097152</currentMemory> + <vcpu placement='static'>1</vcpu> + <cputune> + <shares>1024</shares> + <vcpupin vcpu='0' cpuset='27'/> + <emulatorpin cpuset='27'/> + </cputune> + <numatune> + <memory mode='strict' nodeset='1'/> + <memnode cellid='0' mode='strict' nodeset='1'/> + </numatune> + <resource> + <partition>/machine</partition> + </resource> + <sysinfo type='smbios'> + <system> + <entry name='manufacturer'>Fedora Project</entry> + <entry name='product'>OpenStack Nova</entry> + <entry name='version'>13.1.2-1.el7</entry> + <entry name='serial'>64ab0e89-****-****-****-05312ef66983</entry> + <entry name='uuid'>7f5a66a5-****-****-****-75decaf82bbb</entry> + <entry name='family'>Virtual Machine</entry> + </system> + </sysinfo> + <os> + <type arch='x86_64' machine='pc-i440fx-rhel7.3.0'>hvm</type> + <boot dev='hd'/> + <smbios mode='sysinfo'/> + </os> + <features> + <acpi/> + <apic/> + </features> + <cpu mode='custom' match='exact' check='full'> + <model fallback='forbid'>IvyBridge</model> + <topology sockets='1' cores='1' threads='1'/> + <feature policy='require' name='hypervisor'/> + <feature policy='require' name='arat'/> + <feature policy='require' name='xsaveopt'/> + <numa> + <cell id='0' cpus='0' memory='2097152' unit='KiB'/> + </numa> + </cpu> + <clock offset='utc'> + <timer name='pit' tickpolicy='delay'/> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk'/> + <backingStore/> + <target dev='vda' bus='virtio'/> + <alias name='virtio-disk0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </disk> + <disk type='file' device='disk'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.swap'/> + <backingStore/> + <target dev='vdb' bus='virtio'/> + <alias name='virtio-disk1'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> + </disk> + <disk type='file' device='cdrom'> + <driver name='qemu' type='raw' cache='none'/> + <source file='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/disk.config'/> + <backingStore/> + <target dev='hdd' bus='ide'/> + <readonly/> + <alias name='ide0-1-1'/> + <address type='drive' controller='0' bus='1' target='0' unit='1'/> + </disk> + <controller type='usb' index='0' model='piix3-uhci'> + <alias name='usb'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'> + <alias name='pci.0'/> + </controller> + <controller type='ide' index='0'> + <alias name='ide'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <interface type='bridge'> + <mac address='fa:16:3e:a6:ea:4f'/> + <source bridge='brq52c66dc3-64'/> + <bandwidth> + <inbound average='102400'/> + <outbound average='102400'/> + </bandwidth> + <target dev='tapa29e94e5-42'/> + <model type='virtio'/> + <alias name='net0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </interface> + <serial type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + <alias name='serial0'/> + </serial> + <serial type='pty'> + <source path='/dev/pts/10'/> + <target type='isa-serial' port='1'> + <model name='isa-serial'/> + </target> + <alias name='serial1'/> + </serial> + <console type='file'> + <source path='/data/instances/7f5a66a5-****-****-****-75decaf82bbb/console.log'/> + <target type='serial' port='0'/> + <alias name='serial0'/> + </console> + <input type='tablet' bus='usb'> + <alias name='input0'/> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'> + <alias name='input1'/> + </input> + <input type='keyboard' bus='ps2'> + <alias name='input2'/> + </input> + <graphics type='vnc' port='5910' autoport='yes' listen='0.0.0.0' keymap='en-us'> + <listen type='address' address='0.0.0.0'/> + </graphics> + <video> + <model type='cirrus' vram='16384' heads='1' primary='yes'/> + <alias name='video0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> + </video> + <memballoon model='virtio'> + <stats period='10'/> + <alias name='balloon0'/> + <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> + </memballoon> + </devices> + <seclabel type='dynamic' model='dac' relabel='yes'> + <label>+107:+107</label> + <imagelabel>+107:+107</imagelabel> + </seclabel> +</domain> + +CPU Usage Report inside VM: +# sar -u -P 0 1 5 +Linux 3.10.0-957.el7.x86_64 (******) 05/20/2019 _x86_64_ (1 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:42 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:43 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:44 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +11:34:45 AM 0 0.00 0.00 0.00 0.00 0.00 100.00 +Average: 0 0.00 0.00 0.00 0.00 0.00 100.00 + +CPU Usage Report ON HOST(the vm's cpu is pinned on host's no.27 physic cpu): +# sar -u -P 27 1 5 +Linux 3.10.0-862.el7.x86_64 (******) 05/20/2019 _x86_64_ (48 CPU) + +11:34:40 AM CPU %user %nice %system %iowait %steal %idle +11:34:41 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:42 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:43 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:44 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +11:34:45 AM 27 100.00 0.00 0.00 0.00 0.00 0.00 +Average: 27 100.00 0.00 0.00 0.00 0.00 0.00 + +clocksource inside VM: +# cat /sys/devices/system/clocksource/clocksource0/current_clocksource +kvm_clock + +It shows that only the version 7.6 of redhat or centos affected by this bug, +in my cluster, it is OK for versions from 6.8 to 7.5, but 7.6 is not normal. + +> # libvirtd -V +> libvirtd (libvirt) 3.9.0 +> +> # /usr/libexec/qemu-kvm --version +> QEMU emulator version 2.6.0 (qemu-kvm-ev-2.6.0-28.el7_3.6.1), Copyright (c) 2003-2008 Fabrice Bellard + +This looks like the host is running CentOS, with packages dating from approx 7.3. This is very outdated given current version is 7.6. So I don't think it is worth spending time to debug until the host OS is upgraded to the latest QEMU/libvirt/kernel packages at least to see if the problem still reproduces. + + +I tested two newest QEMU versions these days, and sadly, the problem still happens. + +I tried to find the reason why the qemu process take 100% usage of cpu, and collected some facts about it. +I compared the facts with other normal vm's qemu process(who's cpu usage is normal) and didn't turn out any interesting result. + +Please give me some guides to debug this problem if you could, thanks very much. + + + +(The full content of facts is in the attachment) +1. +======the command line to start a VM====== +# ps -ef |grep 1567284 | cat +qemu 1567284 1 99 Jun21 ? 2-18:09:33 /usr/libexec/qemu-kvm -name guest=instance-0000530a,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-instance-0000530a/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=off -cpu IvyBridge -m 2048 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -object memory-backend-ram,id=ram-node0,size=2147483648,host-nodes=1,policy=bind -numa node,nodeid=0,cpus=0,memdev=ram-node0 -uuid 60d3ad85-1004-47e7-b2cb-5cf1a029ab47 -smbios type=1,manufacturer=Fedora Project,product=OpenStack Nova,version=13.1.2-1.el7,serial=c0700413-4a28-4e97-85c4-66fe3ec367dc,uuid=60d3ad85-1004-47e7-b2cb-5cf1a029ab47,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-1-instance-0000530a/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk,format=raw,if=none,id=drive-virtio-disk0,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.swap,format=raw,if=none,id=drive-virtio-disk1,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/data/instances/60d3ad85-1004-47e7-b2cb-5cf1a029ab47/disk.config,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:21:2c:70,bus=pci.0,addr=0x3 -add-fd set=2,fd=31 -chardev file,id=charserial0,path=/dev/fdset/2,append=on -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0 -k en-us -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on +root 1567288 2 0 Jun21 ? 00:00:01 [vhost-1567284] +root 1567291 2 0 Jun21 ? 00:00:00 [kvm-pit/1567284] + +2. +===version of QEMU=== +# /usr/libexec/qemu-kvm --version +QEMU emulator version 4.0.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +===version of libvirt=== +# libvirtd -V +libvirtd (libvirt) 3.9.0 + +===version of kernal=== +# uname -a +Linux txyz_40_92 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux +Red Hat Enterprise Linux Server (3.10.0-862.el7.x86_64) 7.5 (Maipo) +# modinfo kvm +filename: /lib/modules/3.10.0-862.el7.x86_64/kernel/arch/x86/kvm/kvm.ko.xz +license: GPL +author: Qumranet +retpoline: Y +rhelversion: 7.5 +srcversion: 8A3372406CDF0ACF69A0E58 +depends: irqbypass +intree: Y +vermagic: 3.10.0-862.el7.x86_64 SMP mod_unload modversions +signer: Red Hat Enterprise Linux kernel signing key +sig_key: 51:73:02:3B:F8:16:37:D7:BF:3C:51:50:13:4E:EC:84:1B:96:FD:0B +sig_hashalgo: sha256 +parm: ignore_msrs:bool +parm: min_timer_period_us:uint +parm: kvmclock_periodic_sync:bool +parm: tsc_tolerance_ppm:uint +parm: lapic_timer_advance_ns:uint +parm: vector_hashing:bool +parm: halt_poll_ns:uint +parm: halt_poll_ns_grow:uint +parm: halt_poll_ns_shrink:uint + +3. +===threads=== +# ps -Lp 1567284 + PID LWP TTY TIME CMD +1567284 1567284 ? 00:00:12 qemu-kvm +1567284 1567286 ? 00:00:00 call_rcu +1567284 1567289 ? 00:00:00 IO mon_iothread +1567284 1567290 ? 2-19:07:09 CPU 0/KVM +1567284 1567293 ? 00:00:00 vnc_worker +1567284 1637413 ? 00:00:00 worker + +===top=== +# top -H -p 1567284 +top - 13:02:07 up 164 days, 21:53, 2 users, load average: 1.00, 1.01, 1.05 +Threads: 6 total, 1 running, 5 sleeping, 0 stopped, 0 zombie +%Cpu(s): 2.1 us, 0.0 sy, 0.0 ni, 97.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +KiB Mem : 26353241+total, 25289752+free, 2771140 used, 7863752 buff/cache +KiB Swap: 8388604 total, 8388604 free, 0 used. 25926534+avail Mem + scroll coordinates: y = 1/6 (tasks), x = 1/12 (fields) + PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +1567290 qemu 20 0 6683072 647416 8336 R 99.7 0.2 4028:04 CPU 0/KVM +1567284 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:12.93 qemu-kvm +1567286 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 call_rcu +1567289 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 IO mon_iothread +1567293 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.27 vnc_worker +1637464 qemu 20 0 6683072 647416 8336 S 0.0 0.2 0:00.00 worker + +===htop=== +.... + +===vmstat on the host=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 2 0 0 252897184 366768 7497768 0 0 0 0 0 0 0 0 100 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1394 367 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1442 387 2 0 98 0 0 + 1 0 0 252896752 366768 7497768 0 0 0 0 1479 470 2 0 98 0 0 + 1 0 0 252896752 366776 7497768 0 0 0 12 1373 371 2 0 98 0 0 + +===vmstat on the VM=== +# vmstat 1 5 +procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 1 0 0 1490564 81708 238688 0 0 1 2 14 30 0 0 99 1 0 + 0 0 0 1490564 81708 238688 0 0 0 0 29 55 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 26 56 0 0 100 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 17 31 0 0 99 0 0 + 0 0 0 1490564 81708 238688 0 0 0 0 19 41 0 0 100 0 0 + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/108/other/1829779 b/results/classifier/108/other/1829779 new file mode 100644 index 000000000..e9cdcb070 --- /dev/null +++ b/results/classifier/108/other/1829779 @@ -0,0 +1,95 @@ +permissions: 0.874 +socket: 0.849 +semantic: 0.821 +other: 0.818 +performance: 0.810 +graphic: 0.788 +debug: 0.772 +device: 0.767 +PID: 0.754 +boot: 0.726 +vnc: 0.717 +files: 0.693 +KVM: 0.662 +network: 0.575 + +qemu-system-arm and qemu-system-aarch64 QMP hangs after kernel boots + +After booting a Linux kernel on both arm and aarch64, the QMP sockets gets unresponsive. Initially, this was thought to be limited to "quit" commands, but it reproduced with others (such as in this +reproducer). This is a partial log output: + + >>> {'execute': 'qmp_capabilities'} + <<< {'return': {}} + Booting Linux on physical CPU 0x0000000000 [0x410fd034] + Linux version 4.18.16-300.fc29.aarch64 (<email address hidden>) (gcc version 8.2.1 20180801 (Red Hat 8.2.1-2) (GCC)) #1 SMP Sat Oct 20 23:12:22 UTC 2018 + ... + Policy zone: DMA32 + Kernel command line: printk.time=0 console=ttyAMA0 + >>> {'execute': 'stop'} + <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470173}, 'event': 'STOP'} + <<< {'return': {}} + >>> {'execute': 'cont'} + <<< {'timestamp': {'seconds': 1558370331, 'microseconds': 470849}, 'event': 'RESUME'} + <<< {'return': {}} + >>> {'execute': 'stop'} + +Sometimes it takes just the first "stop" command. Overall, I was able to reproduce 100% of times when applied on top of 6d8e75d41c58892ccc5d4ad61c4da476684c1c83. + +The reproducer test can be seen/fetched at: + - https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df + +And test results from Travis CI can be seen at: + - https://travis-ci.org/clebergnu/qemu/jobs/534915669 + +For convenience purposes, here's qemu-system-aarch64 launching and hanging on the first "stop": + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3615 + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3645 + +And here's qemu-system-arm hanging the very same way: + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3780 + - https://travis-ci.org/clebergnu/qemu/jobs/534915669#L3800 + +I have an update on this. Eric and myself attempted to zero in the +exact cause. A few things we discovered: + + 1) It has nothing to do with having a kernel running + 2) It has to do with having a chardev that is a server socket. This + test produces command line arguments such as: + + -chardev socket,id=console,path=<path>.sock,server,nowait \ + -serial chardev:console + + 3) It doesn't seem to have a connection to the test infrastructure code + (python/qemu/qmp/*), as a I made a number of experiments which + yielded no differences in behavior. + +So, the reproducer given at: + + https://github.com/clebergnu/qemu/commit/c778e28c24030c4a36548b714293b319f4bf18df + +Continues to be be valid (and continues to be limited to arm and aarch64). +Now, after a number of experiments, the following was found to be a 100% +reproducible *workaround*: + + https://github.com/clebergnu/qemu/commit/e1713f3b91972ad57c089f276c54db3f3fa63423 + +That basically shutdowns the *console* socket before proceeding with further QMP +interaction. The effectiveness of the workaround can be seen here: + + aarch64 command line: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3633 + aarch64 QMP interaction: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3663 + + arm command line: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3747 + arm QMP interaction: + - https://travis-ci.org/clebergnu/qemu/jobs/535459499#L3767 + +I hope this provides a few more hints into the real issue. + + +A patch for this bug has been merged here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=085809670201c6d3a33e3 +... can we close this ticket now? + diff --git a/results/classifier/108/other/1829945 b/results/classifier/108/other/1829945 new file mode 100644 index 000000000..18faa1883 --- /dev/null +++ b/results/classifier/108/other/1829945 @@ -0,0 +1,64 @@ +socket: 0.843 +graphic: 0.790 +device: 0.762 +PID: 0.715 +performance: 0.706 +KVM: 0.697 +other: 0.686 +network: 0.645 +files: 0.644 +boot: 0.619 +vnc: 0.594 +permissions: 0.545 +debug: 0.535 +semantic: 0.445 + +SDL support missing from qemu-1:3.1+dfsg-2ubuntu3.1 + +qemu support is missing from qemu-1:3.1+dfsg-2ubuntu3.1 on Disco. This is dispite qemu --help saying its available. SDL support is needed to use Packer(https://www.packer.io/) in graphical mode. + +# qemu-system-x86_64 -cpu host -smp 2,sockets=2,cores=1,threads=1 -machine type=pc,accel=kvm -display sdl -cdrom ubuntu.iso +qemu-system-x86_64: Display 'sdl' is not available. + +# qemu-system-x86_64 --help | grep sdl +-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off] +-sdl shorthand for -display sdl + +Hi Lee, +TL;DR: there will be no sdl support anymore for newer qemu's. (make it) Use "-display gtk" instead. + +Details: +#1 SDL 1.2 vs SDL 2.0 vs working fine +1.2 was in main all the time and worked, but got unsupportable over time. +SDL2 was tried, but failed badly in quite some experiments for Debain and +Ubuntu. That led to the choice of both distributions to go with the more +modern GTK backend instead. +Ubuntu (at Bionic staying at SDL1.2): +- sdl2 is yet too unstable for the LTS Ubuntu release given the reports + we still see upstream and in Debian - furthermore sdl2 isn't in main yet, + so we revert related changes to stick with the proven for now: +Debian then followed for #839695, #886671, #879536, #879534, #879532, #879193, #894852 +That also matches upstream where GTK backend for graphics is the #1 thing. + +#2 Supportability +The reason everyone wanted to get off SDL was maintainability as I mentioned. And as of today you'll find that none of the SDL libs is in main anymore (since Cosmic). +*sdl* is universe nowadays. +And we can't make a good case for it (to MIR it) as GTK solves it - at least from the qemu POV. + +#3 About the man page, this isn't patched for features enabled/disabled by the upstream build system. For example it also contains "pvrdma" which is disabled for security reasons (and many other things). + +I must conclude that as-is I won't enable sdl, but then why does it insist on `-display sdl` in the first place. `-display gtk` is just as good or better. Is that our package of packer.io that we'd want to adapt or a PR for upstream maybe? + +Also misfiled against upstream's Qemu - this clearly was meant for Ubuntu's Qemu as technically upstream is still fine enabling sdl (if the package builder wants to). + +Changing the bug tasks ... + +Ha, Thomas beat me to re-target the bug while I was checking my inbox - thanks :-) + +Thanks for the explanation. MAAS is starting to use Packer to create custom images so we may be packaging this soon. I will filed an upstream bug[1] and created a patch[2] to fix the issue. + +[1] https://github.com/hashicorp/packer/issues/7675 +[2] https://github.com/hashicorp/packer/pull/7676 + +Thanks, I subscribed there and already participate in the discussion + |