diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/performance')
102 files changed, 2330 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/performance/1004 b/results/classifier/deepseek-r1:14b/output/performance/1004 new file mode 100644 index 000000000..0708a6390 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1004 @@ -0,0 +1,10 @@ + +qemu-system-i386 peggs 100% host CPU +Description of problem: +Before the guest OS even starts up, the host CPU eggs at 100%. +Steps to reproduce: +1. Start any VM using qemu-system-i386 +2. On Ubuntu use Virt Manager or command line. +3. On macOS use UTM. +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/performance/1036987 b/results/classifier/deepseek-r1:14b/output/performance/1036987 new file mode 100644 index 000000000..5ecf63ce7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1036987 @@ -0,0 +1,26 @@ + +compilation error due to bug in savevm.c + +Since + +302dfbeb21fc5154c24ca50d296e865a3778c7da + +Add xbzrle_encode_buffer and xbzrle_decode_buffer functions + + For performance we are encoding long word at a time. + For nzrun we use long-word-at-a-time NULL-detection tricks from strcmp(): + using ((lword - 0x0101010101010101) & (~lword) & 0x8080808080808080) test + to find out if any byte in the long word is zero. + + Signed-off-by: Benoit Hudzia <email address hidden> + Signed-off-by: Petter Svard <email address hidden> + Signed-off-by: Aidan Shribman <email address hidden> + Signed-off-by: Orit Wasserman <email address hidden> + Signed-off-by: Eric Blake <email address hidden> + + Reviewed-by: Luiz Capitulino <email address hidden> + Reviewed-by: Eric Blake <email address hidden> + + commit arrived into master barnch, I can't compile qemu at all: + +savevm.c:2476:13: error: overflow in implicit constant conversion [-Werror=overflow] \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1056 b/results/classifier/deepseek-r1:14b/output/performance/1056 new file mode 100644 index 000000000..01237034a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1056 @@ -0,0 +1,2 @@ + +Bad Performance of Windows 11 ARM64 VM on Windows 11 Qemu 7.0 Host System diff --git a/results/classifier/deepseek-r1:14b/output/performance/1070 b/results/classifier/deepseek-r1:14b/output/performance/1070 new file mode 100644 index 000000000..db6f4fda8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1070 @@ -0,0 +1,11 @@ + +gdbstub XML generation for ARM is done for every CPU +Description of problem: +- As arm_cpu_register_gdb_regs_for_features is called from the device + realize stage for each vCPU in user mode we end up uselessly + regenerating the XML for every new thread. Once you get up to 100 + threads this starts exceeding the large maps done for QHT and PageDesc +Steps to reproduce: +See above command line, valgrind picks it up +Additional information: +See also #866, #967 diff --git a/results/classifier/deepseek-r1:14b/output/performance/1094 b/results/classifier/deepseek-r1:14b/output/performance/1094 new file mode 100644 index 000000000..90084f7d9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1094 @@ -0,0 +1,9 @@ + +Ubuntu's 22.04 Qemu high RAM usage (memory leak maybe) +Description of problem: +After starting/using my VM for a while, RAM fills up to the 32gb maximum, and firefox starts closing tabs and etc. This didn't happen in ubuntu 21.10 or earlier ubuntus. I've been using virt-manager + qemu for years and only had this after upgrading to ubuntu 22.04. +Steps to reproduce: +1. Launch virt-manager ubuntu VM with 12gb ram maximum (as an example) +2. RAM entire 32gb gets filled but nothing in gnome-system-monitor shows what is using all that RAM +3. Firefox starts closing tabs because RAM is full. Remember that only a 12gb RAM vm and firefox with a few tabs are running, and it fills all 32gb of RAM. Ram starts filling slowly and in 1 hour it fills the entire 32gb. For some reason htop shows a smaller usage, but I'm pretty sure all 32gb are being used as the computer starts freezing and almost crashing (I think swap is being used so it slows down but do not crash) +4. have to restart the computer for RAM to get normal again diff --git a/results/classifier/deepseek-r1:14b/output/performance/1126369 b/results/classifier/deepseek-r1:14b/output/performance/1126369 new file mode 100644 index 000000000..fa3c107d9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1126369 @@ -0,0 +1,15 @@ + +qemu-img snapshot -c is unreasonably slow + +Something fishy is going on with qcow2 internal snapshot creation times. I don't know if this is a regression because I haven't used internal snapshots in the past. + +QEMU 1.4-rc2: +$ qemu-img create -f qcow2 test.qcow2 -o size=50G,preallocation=metadata +$ time qemu-img snapshot -c new test.qcow2 +real 3m39.147s +user 0m10.748s +sys 0m26.165s + +(This is on an SSD) + +I expect snapshot creation to take under 1 second. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1129957 b/results/classifier/deepseek-r1:14b/output/performance/1129957 new file mode 100644 index 000000000..d2d34a890 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1129957 @@ -0,0 +1,24 @@ + +Performance issue running quest image on qemu compiled for Win32 platform + +I'm seeing performance issues when booting a guest image on qemu 1.4.0 compiled for the Win32 platform. +The same image boots a lot faster on the same computer running qemu/linux on Fedora via VmWare, and even running the Win32 exectuable via Wine performs better than running qemu natively on Win32. + +Although I'm not the author of the image, it is located here: +http://people.freebsd.org/~wpaul/qemu/vxworks.img + +All testing has been done on QEMU 1.4.0. + +I'm also attaching a couple of gprof logs. For these I have disabled ssp in qemu by removing "-fstack-protector-all" and "-D_FORTIFY_SOURCE=2" from the qemu configure script. + +qemu-perf-linux.txt +================ +Machine - Windows XP - VmWare - Fedora - QEMU + +qemu-perf-win32.txt +================= +Machine - Windows XP - QEMU + +qemu-perf-wine.txt +================ +Machine - Windows XP - VmWare - Fedora - Wine - QEMU \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1174654 b/results/classifier/deepseek-r1:14b/output/performance/1174654 new file mode 100644 index 000000000..a38672244 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1174654 @@ -0,0 +1,6 @@ + +qemu-system-x86_64 takes 100% CPU after host machine resumed from suspend to ram + +I have Windows XP SP3 inside qemu VM. All works fine in 12.10. But after upgraiding to 13.04 i have to restart the VM each time i resuming my host machine, because qemu process starts to take CPU cycles and OS inside VM is very slow and sluggish. However it's still controllable and could be shutdown by itself. + +According to the taskmgr any active process takes 99% CPU. It's not stucked on some single process. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1253563 b/results/classifier/deepseek-r1:14b/output/performance/1253563 new file mode 100644 index 000000000..23c7ac45f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1253563 @@ -0,0 +1,35 @@ + +bad performance with rng-egd backend + + +1. create listen socket +# cat /dev/random | nc -l localhost 1024 + +2. start vm with rng-egd backend + +./x86_64-softmmu/qemu-system-x86_64 --enable-kvm -mon chardev=qmp,mode=control,pretty=on -chardev socket,id=qmp,host=localhost,port=1234,server,nowait -m 2000 -device virtio-net-pci,netdev=h1,id=vnet0 -netdev tap,id=h1 -vnc :0 -drive file=/images/RHEL-64-virtio.qcow2 \ +-chardev socket,host=localhost,port=1024,id=chr0 \ +-object rng-egd,chardev=chr0,id=rng0 \ +-device virtio-rng-pci,rng=rng0,max-bytes=1024000,period=1000 + +(guest) # dd if=/dev/hwrng of=/dev/null + +note: cancelling dd process by Ctrl+c, it will return the read speed. + +Problem: the speed is around 1k/s + +=================== + +If I use rng-random backend (filename=/dev/random), the speed is about 350k/s). + +It seems that when the request entry is added to the list, we don't read the data from queue list immediately. +The chr_read() is delayed, the virtio_notify() is delayed. the next request will also be delayed. It effects the speed. + +I tried to change rng_egd_chr_can_read() always returns 1, the speed is improved to (about 400k/s) + +Problem: we can't poll the content in time currently + + +Any thoughts? + +Thanks, Amos \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1307 b/results/classifier/deepseek-r1:14b/output/performance/1307 new file mode 100644 index 000000000..6094097ff --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1307 @@ -0,0 +1,73 @@ + +query-named-block-nodes, without flat=true, is massively slow as number of block nodes increases +Description of problem: +The query-named-block-nodes command is insanely slow with deep backing chains when the flat=true arg is NOT given. + +``` +qemu-img create demo0.qcow2 1g +j=0 +for i in `seq 1 199` +do + qemu-img create -f qcow2 -o backing_file=demo$j.qcow2 -o backing_fmt=qcow2 demo$i.qcow2 + j=$i +done +``` + +Now configure libvirt with + +``` + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2' discard='unmap'/> + <source file='/var/lib/libvirt/images/demo199.qcow2'/> + <target dev='vdb' bus='virtio'/> + <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> + </disk> +``` + +This results in `-blockdev` args + +``` +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo0.qcow2","node-name":"libvirt-201-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-201-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-201-storage","backing":null}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo1.qcow2","node-name":"libvirt-200-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-200-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-200-storage","backing":"libvirt-201-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo2.qcow2","node-name":"libvirt-199-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-199-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-199-storage","backing":"libvirt-200-format"}' \ +...snip... +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo197.qcow2","node-name":"libvirt-4-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-4-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-4-storage","backing":"libvirt-5-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo198.qcow2","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-3-format","read-only":true,"discard":"unmap","driver":"qcow2","file":"libvirt-3-storage","backing":"libvirt-4-format"}' \ +-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/demo199.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ +-blockdev '{"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"}' \ +-device '{"driver":"virtio-blk-pci","bus":"pci.7","addr":"0x0","drive":"libvirt-1-format","id":"virtio-disk1"}' \ +``` + +Now stop libvirt + +``` +systemctl stop libvirtd +``` + +And speak directly to QMP + +``` +$ time socat UNIX:/var/lib/libvirt/qemu/domain-158-fedora38/monitor.sock - > /dev/null +{ "execute": "qmp_capabilities", "arguments": { "enable": ["oob"] } } +{ "execute": "query-named-block-nodes"} +{ "execute": "quit" } + +real 2m19.276s +user 0m0.006s +sys 0m0.014s +``` + +If we save the 'query-named-block-nodes' output instead of sending it to /dev/null, we get a 86 MB file for the QMP response. This will break all known client apps since they limit QMP reply size. + +It appears to have a combinatorial expansion of block nodes in the output. + +Blocking the main event loop for 2 minutes is obviously not good either. + +If we use '"flat": true' parameter to query-named-block-nodes, the command completes in just 15 seconds, and produces a large, but more manageable 2.7 MB + +Since the non-flat query-named-block-nodes output is so incredibly non-scalable, I think we should deprecate non-flat mode, and eventually make flat the mandatory option. diff --git a/results/classifier/deepseek-r1:14b/output/performance/1321 b/results/classifier/deepseek-r1:14b/output/performance/1321 new file mode 100644 index 000000000..43cfc48fd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1321 @@ -0,0 +1,9 @@ + +qemu-system-i386 runs slow after upgrading legacy project from qemu 2.9.0 to 7.1.0 +Description of problem: +Using several custom serial and irq devices including timers. +The same code (after some customisation in order to compile with new 7.1.0 API and meson build system runs about 50% slower. +We had to remove "-icount 4" switch which worked fine with 2.9.0 just to get to this point. +Even running with multi-threaded tcg did not help. +We don't use the new ptimer API but rather the old QEMUTimer. +Any suggestions to why we encounter this vast performance degradation? diff --git a/results/classifier/deepseek-r1:14b/output/performance/1321464 b/results/classifier/deepseek-r1:14b/output/performance/1321464 new file mode 100644 index 000000000..d808cde13 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1321464 @@ -0,0 +1,26 @@ + +qemu/block/qcow2.c:1942: possible performance problem ? + +I just ran static analyser cppcheck over today (20140520) qemu source code. + +It said many things, including + +[qemu/block/qcow2.c:1942] -> [qemu/block/qcow2.c:1943]: (performance) Buffer 'pad_buf' is being writ +ten before its old content has been used. + +Source code is + + memset(pad_buf, 0, s->cluster_size); + memcpy(pad_buf, buf, nb_sectors * BDRV_SECTOR_SIZE); + +Worth tuning ? + +Similar problem here + +[qemu/block/qcow.c:815] -> [qemu/block/qcow.c:816]: (performance) Buffer 'pad_buf' is being written +before its old content has been used. + +and + +[qemu/hw/i386/acpi-build.c:1265] -> [qemu/hw/i386/acpi-build.c:1267]: (performance) Buffer 'dsdt' is + being written before its old content has been used. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1331334 b/results/classifier/deepseek-r1:14b/output/performance/1331334 new file mode 100644 index 000000000..ac9a66334 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1331334 @@ -0,0 +1,4 @@ + +driftfix=none and migration on Win7 guest causes time to go 10 times as fast + +With -rtc base=localtime,clock=host,driftfix=none on a Win7 guest, stopping it with migration and then starting it again about 1 hour later makes the guest time go 10 times as fast as real time until Windows is rebooted. I have tried qith qemu-2.0.0 and the problem still exists there. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1338 b/results/classifier/deepseek-r1:14b/output/performance/1338 new file mode 100644 index 000000000..d93eb31ee --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1338 @@ -0,0 +1,2 @@ + +Remove gprof diff --git a/results/classifier/deepseek-r1:14b/output/performance/1370585 b/results/classifier/deepseek-r1:14b/output/performance/1370585 new file mode 100644 index 000000000..81eb0c1c9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1370585 @@ -0,0 +1,8 @@ + +qemu-img cannot create fixed vhdx + +When trying to create a fixed vhdx image, qemu-img fails with the following error: + + qemu-img: test.vhdx: Could not create image: Cannot allocate memory + +This happens because of a incorrect check in vhdx.c \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1399939 b/results/classifier/deepseek-r1:14b/output/performance/1399939 new file mode 100644 index 000000000..14207912c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1399939 @@ -0,0 +1,5 @@ + +Qemu build with -faltivec and maltivec support in + +if is possible add the build support for qemu for have the -faltivec -maltivec in CPPFLAGS for make the emulation more faster on PPC equiped machine . +Thank you \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1462949 b/results/classifier/deepseek-r1:14b/output/performance/1462949 new file mode 100644 index 000000000..b0c84388b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1462949 @@ -0,0 +1,28 @@ + +vmdk files cause qemu-img to consume lots of time and memory + +The two attached files cause 'qemu-img info' to consume lots of time and memory. Around 10-12 seconds of CPU time, and around 3-4 GB of heap. + +$ /usr/bin/time ~/d/qemu/qemu-img info afl10.img +qemu-img: Can't get size of device 'image': File too large +0.40user 11.57system 0:12.03elapsed 99%CPU (0avgtext+0avgdata 4197804maxresident)k +56inputs+0outputs (0major+1045672minor)pagefaults 0swaps + +$ /usr/bin/time ~/d/qemu/qemu-img info afl11.img +image: afl11.img +file format: vmdk +virtual size: 12802T (14075741666803712 bytes) +disk size: 4.0K +cluster_size: 65536 +Format specific information: + cid: 4294967295 + parent cid: 4294967295 + create type: monolithicSparse + extents: + [0]: + virtual size: 14075741666803712 + filename: afl11.img + cluster size: 65536 + format: +0.29user 9.10system 0:09.43elapsed 99%CPU (0avgtext+0avgdata 3297360maxresident)k +8inputs+0outputs (0major+820507minor)pagefaults 0swaps \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1481272 b/results/classifier/deepseek-r1:14b/output/performance/1481272 new file mode 100644 index 000000000..bcff6dc94 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1481272 @@ -0,0 +1,12 @@ + +main-loop: WARNING: I/O thread spun for 1000 iterations + +I compile the latest qemu to launch a VM but the monitor output the "main-loop: WARNING: I/O thread spun for 1000 iterations". + +# /usr/local/bin/qemu-system-x86_64 -name rhel6 -S -no-kvm -m 1024M -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid c9dd2a5c-40f2-fd3d-3c54-9cd84f8b9174 -rtc base=utc -drive file=/home/samba-share/ubuntu.img,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=disk,serial=425618d4-871f-4021-bc5d-bcd7f1b5ca9c,bootindex=0 -vnc :1 -boot menu=on -monitor stdio +QEMU 2.3.93 monitor - type 'help' for more information +(qemu) c +(qemu) main-loop: WARNING: I/O thread spun for 1000 iterations <----------------------- + +qemu]# git branch -v +* master e95edef Merge remote-tracking branch 'remotes/sstabellini/tags/xen-migration-2.4-tag' into staging \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1505041 b/results/classifier/deepseek-r1:14b/output/performance/1505041 new file mode 100644 index 000000000..ebff5c84b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1505041 @@ -0,0 +1,58 @@ + +Live snapshot revert times increases linearly with snapshot age + +The WineTestBot (https://testbot.winehq.org/) uses QEmu live snapshots to ensure the Wine tests are always run in a pristine Windows environment. However the revert times keep increasing linearly with the age of the snapshot, going from tens of seconds to thousands. While the revert takes place the qemu process takes 100% of a core and there is no disk activity. Obviously waiting over 20 minutes before being able to run a 10 second test is not viable. + +Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following <timer> tags: + + <clock offset='localtime'> + <timer name='rtc' tickpolicy='delay'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + +Where the unaffected VMs have the following clock definition instead: + + <clock offset='localtime'/> + +Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds). + +Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest). + + +To reproduce this problem do the following: +* Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10. +* That VM will have the <timer> tags shown above, with the possible addition of an hypervclock timer. +* Shut down the VM. +* date -s "2014/04/01" +* Start the VM. +* Take a live snapshot. +* Shut down the VM. +* date -s "<your current date>" +* Revert to the live snapshot. + +If the revert takes more than 2 minutes then there is a problem. + + +A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented? + * It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated. + * It setting track='guest' the revert is fast and the clock in the guest is not updated. + + +I found three past mentions of this issue but as far as I can tell none of them got anywhere: + +* [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions + https://lists.gnu.org/archive/html/qemu-discuss/2013-02/msg00000.html + +* The above post references another one from 2011 wrt qemu 0.14: + https://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02645.html + +* Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However + the bug was really about another issue so this was not followed on. + https://bugs.launchpad.net/qemu/+bug/1174654/comments/9 + + +I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along. +1:2.1+dfsg-12+deb8u2 qemu-kvm +1:2.1+dfsg-12+deb8u2 qemu-system-common +1:2.1+dfsg-12+deb8u2 qemu-system-x86 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1520 b/results/classifier/deepseek-r1:14b/output/performance/1520 new file mode 100644 index 000000000..11b2d806e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1520 @@ -0,0 +1,50 @@ + +x86 TCG acceleration running on s390x with -smp > host cpus slowed down by x10 +Description of problem: +This boots up a trivial guest using OVMF, when the conditions below are given it runs ~10x slower. + +I have found this breaking our tests of qemu 7.2 [(which due to Debian adding the offending change as backport is affected)](https://salsa.debian.org/qemu-team/qemu/-/blob/master/debian/patches/master/acpi-cpuhp-fix-guest-visible-maximum-access-size-to-.patch) by runnig an order of magnitude slower. + + +I was tracing it down (insert a long strange trip here) and found that it occurs: +- only with patch dab30fb "acpi: cpuhp: fix guest-visible maximum access size to the legacy reg block" applied + - latest master is still affetced +- only with s390x running emulation of x86 + - emulating x86 on ppc64 didn't show the same behavior +- only with -smp > host cpus + - smp 2 with 1 host cpu => slow + - smp 4 with 2 host cpu => slow + - any case where host cpu >= smp => fast + +On average good cases are on a 2964 s390x machine taking ~5-6 seconds for the good case. +The bad case is close to 60s which is the timeout of the automated tests. + +We all know -smp shouldn't be >host-cpus, and I totally admit that this is the definition of an edge case. +But I do not know what else might be affected and this just happened to be what the test does by default - and a slowdown by x10 seems too much even for edge cases to be just ignored. +And while we could just bump up the timeout (and probably will as an interim workaround) I wanted to file it here for your awareness. +Steps to reproduce: +You can recreate the same by using the commandline above and timing things on your own. + +Or you can use the [autopkgtest of edk2 in Ubuntu](https://git.launchpad.net/ubuntu/+source/edk2/tree/debian/tests/shell.py#n214) which have [shown this](https://autopkgtest.ubuntu.com/results/autopkgtest-lunar/lunar/s390x/e/edk2/20230224_094012_c95f4@/log.gz) first. +Additional information: +Only signed OVMF cases are affected, while aavmf and other OVMF are more or less on the same speed. + +``` +1 CPU / 1GB Memory +7.0 7.2 +6.54s 58.32s test_ovmf_ms +6.72s 56.96s test_ovmf_4m_ms +7.54s 55.47s test_ovmf_4m_secboot +7.56s 49.88s test_ovmf_secboot +7.01s 39.79s test_ovmf32_4m_secboot +7.38s 7.43s test_aavmf32 +7.27s 7.30s test_aavmf +7.26s 7.26s test_aavmf_snakeoil +5.83s 5.95s test_ovmf_4m +5.61s 5.81s test_ovmf_q35 +5.51s 5.64s test_ovmf_pc +5.26s 5.42s test_ovmf_snakeoil +``` + +Highlighting @cborntra since it is somewhat s390x related and @mjt0k as the patch is applied as backport in Debian. +I didn't find the handle of Laszlo (Author) to highlight him as well. diff --git a/results/classifier/deepseek-r1:14b/output/performance/1529173 b/results/classifier/deepseek-r1:14b/output/performance/1529173 new file mode 100644 index 000000000..29a0e1d7d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1529173 @@ -0,0 +1,32 @@ + +Absolutely slow Windows XP SP3 installation + +Host: Linux 4.3.3 vanilla x86-64/Qemu 2.5 i686 (mixed env) +Guest: Windows XP Professional SP3 (i686) + +This is my launch string: + +$ qemu-system-i386 \ +-name "Windows XP Professional SP3" \ +-vga std \ +-net nic,model=pcnet \ +-cpu core2duo \ +-smp cores=2 \ +-cdrom /tmp/en_winxp_pro_with_sp3_vl.iso \ +-hda Windows_XP.qcow \ +-boot d \ +-net nic \ +-net user \ +-m 1536 \ +-localtime + +Console output: + +warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm|i64 [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:EDX.vme [bit 1] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.syscall [bit 11] +warning: TCG doesn't support requested feature: CPUID.80000001H:EDX.lm|i64 [bit 29] + +After hitting 35% installation more or less stalls (it actually doesn't but it progresses 1% a minute which is totally unacceptable). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1569491 b/results/classifier/deepseek-r1:14b/output/performance/1569491 new file mode 100644 index 000000000..8ea59c09c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1569491 @@ -0,0 +1,6 @@ + +qemu system i386 poor performance on e5500 core + +I had been tested with generic core net building or with mtune e5500 but i have the same result: performances +are extremly low compared with other classes of powerpc cpu. +The strange is the 5020 2ghz in all emulators been tested by me is comparable with a 970MP 2.7 ghz in speed and benchmarks but im facing the half of performance in i386-soft-mmu compared with a 2.5 ghz 970MP. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1578 b/results/classifier/deepseek-r1:14b/output/performance/1578 new file mode 100644 index 000000000..2e21adc60 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1578 @@ -0,0 +1,4 @@ + +Send all the SVQ control commands in parallel instead of serialized +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/performance/1652373 b/results/classifier/deepseek-r1:14b/output/performance/1652373 new file mode 100644 index 000000000..a4bb1ec70 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1652373 @@ -0,0 +1,8 @@ + +User-mode QEMU is not deterministic + +QEMU in user-mode (linux-user or bsd-user) has no way to get the equivalent of the "-icount" argument found in softmmu mode. + +It is true that some system calls in user-mode can prevent deterministic execution, but it would be very simple to patch time-related syscalls to return a number based on icount when in deterministic mode. + +Putting both changes together (icount + time-related syscalls) would cover the needs for deterministic execution of most benchmarks (i.e., those not interacting with the network or other programs in the system). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1689499 b/results/classifier/deepseek-r1:14b/output/performance/1689499 new file mode 100644 index 000000000..b1244eeda --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1689499 @@ -0,0 +1,30 @@ + +copy-storage-all/inc does not easily converge with load going on + +Hi, +for now this is more a report to discuss than a "bug", but I wanted to be sure if there are things I might overlook. + +I'm regularly testing the qemu's we have in Ubuntu which currently are 2.0, 2.5, 2.6.1, 2.8 plus a bunch of patches. And for all sorts of verification upstream every now and then. + +I recently realized that the migration options around --copy-storage-[all/inc] seem to have got worse at converging on migration. Although it is not a hard commit that is to be found, it just seems more likely to occur the newer the qemu versions is. I assume that is partially due to guest performance optimization that keep it busy. +To a user it appears as a hanging migration being locked up. + +But let me outline what actually happens: +- Setup without shared storage +- Migration using --copy-storage-all/--copy-storage-inc +- Working fine with idle guests +- If the guests is busy the migration does take like forever (1 vCPU that are busy with 1 CPU, 1 memory and one disk hogging processes) +- statistically seems to trigger more likely on newer qemu's (might be a red herring) + +The background workloads are most trivial burners: +- cpu: md5sum /dev/urandom +- memory: stress-ng -m 1 --vm-keep --vm-bytes 256M +- disk: while /bin/true; do dd if=/dev/urandom of=/var/tmp/mjb.1 bs=4M count=100; done + +We are talking about ~1-2 minutes on qemu 2.5 (4 tries x 3 architectures) and 2-10+ hours on >=qemu 2.6.1. + +I say it is likely not a bug, but more a discussion as I can easily avoid hanging via either: +- timeouts (--timeout, ...) to abort or suspend to migrate it +- --auto-converge ( I had only one try, but it seemed to help by slowing down the load generators) + +So you might say "that is all as it should be, and the users can use the further options to mitigate" and I'm all fine with that. In that case the bug still serves as a "searchable" document of some kind for others triggering the same case. But if anything comes to your mind that need better handling around this case lets start to discuss more deeply about it. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1720969 b/results/classifier/deepseek-r1:14b/output/performance/1720969 new file mode 100644 index 000000000..83ff667b1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1720969 @@ -0,0 +1,10 @@ + +qemu/memory.c:206: pointless copies of large structs ? + +[qemu/memory.c:206]: (performance) Function parameter 'a' should be passed by reference. +[qemu/memory.c:207]: (performance) Function parameter 'b' should be passed by reference. + +Source code is + +static bool memory_region_ioeventfd_equal(MemoryRegionIoeventfd a, + MemoryRegionIoeventfd b) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1734810 b/results/classifier/deepseek-r1:14b/output/performance/1734810 new file mode 100644 index 000000000..117e1778f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1734810 @@ -0,0 +1,22 @@ + +Windows guest virtual PC running abnormally slow + +Guest systems running Windows 10 in a virtualized environment run unacceptably slow, with no option in Boxes to offer the virtual machine more (or less) cores from my physical CPU. + +ProblemType: Bug +DistroRelease: Ubuntu 17.10 +Package: gnome-boxes 3.26.1-1 +ProcVersionSignature: Ubuntu 4.13.0-17.20-lowlatency 4.13.8 +Uname: Linux 4.13.0-17-lowlatency x86_64 +ApportVersion: 2.20.7-0ubuntu3.5 +Architecture: amd64 +CurrentDesktop: ubuntu:GNOME +Date: Tue Nov 28 00:37:11 2017 +ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR=<set> + LANG=en_US.UTF-8 + SHELL=/bin/bash +SourcePackage: gnome-boxes +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1740219 b/results/classifier/deepseek-r1:14b/output/performance/1740219 new file mode 100644 index 000000000..84c708fe4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1740219 @@ -0,0 +1,60 @@ + +static linux-user ARM emulation has several-second startup time + +static linux-user emulation has several-second startup time + +My problem: I'm a Parabola packager, and I'm updating our +qemu-user-static package from 2.8 to 2.11. With my new +statically-linked 2.11, running `qemu-arm /my/arm-chroot/bin/true` +went from taking 0.006s to 3s! This does not happen with the normal +dynamically linked 2.11, or the old static 2.8. + +What happens is it gets stuck in +`linux-user/elfload.c:init_guest_space()`. What `init_guest_space` +does is map 2 parts of the address space: `[base, base+guest_size]` +and `[base+0xffff0000, base+0xffff0000+page_size]`; where it must find +an acceptable `base`. Its strategy is to `mmap(NULL, guest_size, +...)` decide where the first range is, and then check if that ++0xffff0000 is also available. If it isn't, then it starts trying +`mmap(base, ...)` for the entire address space from low-address to +high-address. + +"Normally," it finds an accaptable `base` within the first 2 tries. +With a static 2.11, it's taking thousands of tries. + +---- + +Now, from my understanding, there are 2 factors working together to +cause that in static 2.11 but not the other builds: + + - 2.11 increased the default `guest_size` from 0xf7000000 to 0xffff0000 + - PIE (and thus ASLR) is disabled for static builds + +For some reason that I don't understand, with the smaller +`guest_size` the initial `mmap(NULL, guest_size, ...)` usually +returns an acceptable address range; but larger `guest_size` makes it +consistently return a block of memory that butts right up against +another already mapped chunk of memory. This isn't just true on the +older builds, it's true with the 2.11 builds if I use the `-R` flag to +shrink the `guest_size` back down to 0xf7000000. That is with +linux-hardened 4.13.13 on x86-64. + +So then, it it falls back to crawling the entire address space; so it +tries base=0x00001000. With ASLR, that probably succeeds. But with +ASLR being disabled on static builds, the text segment is at +0x60000000; which is does not leave room for the needed +0xffff1000-size block before it. So then it tries base=0x00002000. +And so on, more than 6000 times until it finally gets to and passes +the text segment; calling mmap more than 12000 times. + +---- + +I'm not sure what the fix is. Perhaps try to mmap a continuous chunk +of size 0xffff1000, then munmap it and then mmap the 2 chunks that we +actually need. The disadvantage to that is that it does not support +the sparse address space that the current algorithm supports for +`guest_size < 0xffff0000`. If `guest_size < 0xffff0000` *and* the big +mmap fails, then it could fall back to a sparse search; though I'm not +sure the current algorithm is a good choice for it, as we see in this +bug. Perhaps it should inspect /proc/self/maps to try to find a +suitable range before ever calling mmap? \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1751264 b/results/classifier/deepseek-r1:14b/output/performance/1751264 new file mode 100644 index 000000000..67e97718e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1751264 @@ -0,0 +1,26 @@ + +qemu-img convert issue in a tmpfs partition + +qemu-img convert command is slow when the file to convert is located in a tmpfs formatted partition. + +v2.1.0 on debian/jessie x64, ext4: 10m14s +v2.1.0 on debian/jessie x64, tmpfs: 10m15s + +v2.1.0 on debian/stretch x64, ext4: 11m9s +v2.1.0 on debian/stretch x64, tmpfs: 10m21.362s + +v2.8.0 on debian/jessie x64, ext4: 10m21s +v2.8.0 on debian/jessie x64, tmpfs: Too long + +v2.8.0 on debian/stretch x64, ext4: 10m42s +v2.8.0 on debian/stretch x64, tmpfs: Too long + +It seems that the issue is caused by this commit : https://github.com/qemu/qemu/commit/690c7301600162421b928c7f26fd488fd8fa464e + +In order to reproduce this bug : + +1/ mount a tmpfs partition : mount -t tmpfs tmpfs /tmp +2/ get a vmdk file (we used a 15GB image) and put it on /tmp +3/ run the 'qemu-img convert -O qcow2 /tmp/file.vmdk /path/to/destination' command + +When we trace the process, we can see that there's a lseek loop which is very slow (compare to outside a tmpfs partition). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1756807 b/results/classifier/deepseek-r1:14b/output/performance/1756807 new file mode 100644 index 000000000..fc79fd7e7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1756807 @@ -0,0 +1,68 @@ + +performance regression in qemu-user + proot + +To reproduce: + +1. Install qemu-user-static and proot +2. Enter some arm chroot using them: + + proot -0 -q qemu-arm-static -w / -r chroot/ /bin/bash + +3. Run a command which normally takes a short but measurable amount of time: + + cd /usr/share/doc && time grep -R hello + +Result: + +This is over 100 times slower on 18.04 than it was on 16.04. I am not sure if proot or qemu is causing the problem, but proot version has not changed. Also note that on 16.04 I am using the cloud repo version of qemu, which is newer than 16.04 stock, but still older than 18.04. + +Although system 2 is lower spec than system 1, it should not be this much slower. No other software seems to be affected. + +If required I can supply a chroot tarball. It is essentially just a Debian bootstrap though. + +Logs: + + + +System 1: i7-6700 3.4GHz, 32GB RAM, 512GB Crucial MX100 SSD, Ubuntu 16.04 +qemu-arm version 2.10.1(Debian 1:2.10+dfsg-0ubuntu3.4~cloud0) +proot 5.1.0 + +al@al-desktop:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-desktop:/# cd /usr/share/doc +root@al-desktop:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m0.066s +user 0m0.040s +sys 0m0.008s + + + + + +System 2: i5-5300U 2.30GHz, 8GB RAM, 256GB Crucial MX300 SSD, Ubuntu 18.04 +qemu-arm version 2.11.1(Debian 1:2.11+dfsg-1ubuntu4) +proot 5.1.0 + +al@al-thinkpad:~/rpi-ramdisk/raspbian$ proot -0 -q qemu-arm-static -w / -r root/ /bin/bash +root@al-thinkpad:/# cd /usr/share/doc +root@al-thinkpad:/usr/share/doc# time grep -R hello +dash/copyright:Debian GNU/Linux hello source package as the file COPYING. If not, + +real 0m24.176s +user 0m0.366s +sys 0m11.352s + +ProblemType: Bug +DistroRelease: Ubuntu 18.04 +Package: qemu (not installed) +ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7 +Uname: Linux 4.15.0-12-generic x86_64 +ApportVersion: 2.20.8-0ubuntu10 +Architecture: amd64 +Date: Mon Mar 19 07:13:25 2018 +InstallationDate: Installed on 2018-03-18 (0 days ago) +InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180318) +SourcePackage: qemu +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1770859 b/results/classifier/deepseek-r1:14b/output/performance/1770859 new file mode 100644 index 000000000..952fc6625 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1770859 @@ -0,0 +1,4 @@ + +qemu-img compare -m option is missing + +Comparing images using multiple streams (like qemu-img convert) maybe effectively sped up when one of the images (or both) is RBD. qemu-img convert does it's job perfectly while converting. Please implement the same for image comparison. Since operations are read-only, -W is useless, but may be introduced as well for debugging/performance purposes. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1774677 b/results/classifier/deepseek-r1:14b/output/performance/1774677 new file mode 100644 index 000000000..5be3bb3d7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1774677 @@ -0,0 +1,21 @@ + +-icount increases boot time by >10x + +When I specify the -icount option, some guest operations such as booting a Linux kernel take more than 10 times longer than otherwise. For example, the following will boot Aboriginal Linux to the login prompt about 6 seconds on my system (using TCG, not KVM): + +wget http://landley.net/aboriginal/downloads/old/binaries/1.4.5/system-image-i686.tar.gz +gunzip <system-image-i686.tar.gz | tar xfv - +cd system-image-i686 +sh run-emulator.sh + +If I replace the last line with + +QEMU_EXTRA="-icount shift=auto" sh run-emulator.sh + +booting to the login prompt takes about 1 minute 20 seconds. + +I have tried different values for "shift" other than the "auto" used above, but have not been able to find one that gives reasonable performance. Specifying "sleep=off" also did not help. + +During the slow boots, qemu appears to spend most of its time sleeping, not using the host CPU. + +I see this with multiple versions of qemu, including current git sources (c181ddaa176856b3cd2dfd12bbcf25fa9c884a97), and on multiple host OSes, including Debian 9 on x86_64. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1775702 b/results/classifier/deepseek-r1:14b/output/performance/1775702 new file mode 100644 index 000000000..8d01f0810 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1775702 @@ -0,0 +1,12 @@ + +High host CPU load and slower guest after upgrade guest OS Windows 10 to ver 1803 + +After upgrading Windows 10 guest to version 1803, guests VM runs slower and there is high host CPU load even when guest is almost idle. Did not happened with windows 10 up to version 1709. + +See my 1st report here: +https://askubuntu.com/questions/1033985/kvm-high-host-cpu-load-after-upgrading-vm-to-windows-10-1803 + +Another user report is here: +https://lime-technology.com/forums/topic/71479-windows-10-vm-cpu-usage/ + +Tested on: Ubuntu 16.04 with qemu 2.5.0 and i3-3217U, Arch with qemu 2.12 i5-7200U, Ubuntu 18.04 qemu 2.11.1 AMD FX-4300. All three platform showing the same slowdown and higher host cpu load with windows 10 1803 VM compared to windows 10 1709 VM. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1790460 b/results/classifier/deepseek-r1:14b/output/performance/1790460 new file mode 100644 index 000000000..4d109d4f7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1790460 @@ -0,0 +1,26 @@ + +-icount,sleep=off mode is broken (target slows down or hangs) + +QEMU running with options "-icount,sleep=off -rtc clock=vm" doesn't execute emulation at maximum possible speed. +Target virtual clock may run faster or slower than realtime clock by N times, where N value depends on various unrelated conditions (i.e. random from the user point of view). The worst case is when target hangs (hopefully, early in booting stage). +Example scenarios I've described here: http://lists.nongnu.org/archive/html/qemu-discuss/2018-08/msg00102.html + +QEMU process just sleeps most of the time (polling, waiting some condition, etc.). I've tried to debug issue and came to 99% conclusion that there are racing somewhere in qemu internals. + +The feature is broken since v2.6.0 release. +Bad commit is 281b2201e4e18d5b9a26e1e8d81b62b5581a13be by Pavel Dovgalyuk, 03/10/2016 05:56 PM: + + icount: remove obsolete warp call + + qemu_clock_warp call in qemu_tcg_wait_io_event function is not needed + anymore, because it is called in every iteration of main_loop_wait. + + Reviewed-by: Paolo Bonzini <email address hidden> + + Signed-off-by: Pavel Dovgalyuk <email address hidden> + Message-Id: <20160310115603.4812.67559.stgit@PASHA-ISP> + Signed-off-by: Paolo Bonzini <email address hidden> + +I've reverted commit to all major releases and latest git master branch. Issue was fixed for all of them. My adaptation is trivial: just restoring removed function call before "qemu_cond_wait(...)" line. + +I'm sure following bugs are just particular cases of the issue: #1774677, #1653063 . \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1794285 b/results/classifier/deepseek-r1:14b/output/performance/1794285 new file mode 100644 index 000000000..c49dbfbff --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1794285 @@ -0,0 +1,101 @@ + +100% Host CPU usage while guest idling + +Hi, + +We have an appliance that runs a FreeBSD guest on a Yocto-based host via qemu-system-x86_64. +Everything functions fine however the host uses n00% of the CPU (where n = #smp) and RAM allocated to it whilst the 1 guest is sat nearing idle. + +Host: +PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND +4406 root 20 0 16.7g 16g 26m S 500 53.0 17958:38 qemu-system-x86 + +Guest: +CPU 0: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle +CPU 1: 0.0% user, 0.0% nice, 0.4% system, 0.0% interrupt, 99.6% idle +CPU 2: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle +CPU 3: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle +CPU 4: 0.4% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.6% idle +Mem: 43M Active, 4783M Inact, 1530M Wired, 911M Buf, 9553M Free +Swap: 3072M Total, 3072M Free + +I have logged this with the appliance vendor and received the response: +"This is expected behaviour and you will see the same in any case where a Guest OS runs over a Host OS. +Host here has 5 CPUs and it has assigned all of them to Guest. +Since the Host is not being shared by any Guest OS; you will always see the 500% (or the 5 CPUs) given to qemu-system-x86. +I do see the same in lab and is very much expected" + +This feels fundamentally wrong to me. +I'm somewhat limited by what can be tested due to the nature of this being an appliance rather than a mainstream distro. + +I'm looking for feedback that I can use to push the vendor into investigating this issue. + +Versions below. + +Many thanks, +Gareth + + + +Host: +Linux 204a-node 3.10.100-ovp-rt110-WR6.0.0.31_preempt-rt #1 SMP Fri +Aug 3 01:59:01 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux + +Qemu: +QEMU emulator version 1.7.2, Copyright (c) 2003-2008 Fabrice Bellard + +Command: +(Vendor identifying information has been removed) + +/usr/bin/qemu-system-x86_64 \ +-name REMOVED \ +-S \ +-machine pc-i440fx-1.7,accel=kvm,usb=off \ +-m 16384 \ +-realtime mlock=on \ +-smp 5,sockets=5,cores=1,threads=1 \ +-uuid 76277b29-3bd4-4dd4-a705-ed34d6449d6d \ +-nographic \ +-no-user-config \ +-nodefaults \ +-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/REMOVED.monitor,server,nowait \ +-mon chardev=charmonitor,id=monitor,mode=control \ +-rtc base=utc \ +-no-shutdown \ +-boot strict=on \ +-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \ +-device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x17 \ +-netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 \ +-device virtio-net-pci,netdev=hostnet0,id=net0,mac=REMOVED,bus=pci.0,addr=0x11 \ +-netdev tap,ifname=tap1,script=/etc/vehostd/XXX-em3-ifup,id=hostnet1,vhost=on,vhostfd=24 \ +-device virtio-net-pci,netdev=hostnet1,id=net1,mac=REMOVED,bus=pci.0,addr=0x12 \ +-netdev tap,ifname=tap2,script=/etc/vehostd/REMOVED-em4-ifup-SUMMIT,id=hostnet2,vhost=on,vhostfd=25 \ +-device virtio-net-pci,netdev=hostnet2,id=net2,mac=REMOVED,bus=pci.0,addr=0x1c \ +-netdev tap,ifname=tap3,script=/etc/vehostd/REMOVED-em4-re-re-ifup,id=hostnet3,vhost=on,vhostfd=26 \ +-device virtio-net-pci,netdev=hostnet3,id=net3,mac=REMOVED,bus=pci.0,addr=0x1d \ +-chardev pty,id=charserial0 \ +-device isa-serial,chardev=charserial0,id=serial0 \ +-chardev tty,id=charserial1,path=/dev/ttyS1 \ +-device isa-serial,chardev=charserial1,id=serial1 \ +-chardev tty,id=charserial2,path=/dev/ttyS2 \ +-device isa-serial,chardev=charserial2,id=serial2 \ +-chardev tty,id=charserial3,path=/dev/ttyS3 \ +-device isa-serial,chardev=charserial3,id=serial3 \ +-device i6300esb,id=watchdog0,bus=pci.0,addr=0x10 \ +-watchdog-action reset \ +-object rng-random,id=rng0,filename=/dev/random \ +-device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x1e \ +-smbios type=0,vendor="INSYDE Corp.",version=REMOVED,date=11/03/2017,release=1.00 \ +-smbios type=1,manufacturer=REMOVED,product=REMOVED,version=REMOVED,serial=VF-NET \ +-device REMOVED-pci,host=0000:1c:00.0 \ +-device kvm-pci-assign,host=0000:00:14.0 \ +-device pci-hgcommdev,vmindex=0,bus=pci.0,addr=0x16 \ +-drive file=/REMOVED/REMOVED-current.img,if=none,id=drive-virtio-disk0,format=raw,cache=directsync,aio=native \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x13,drive=drive-virtio-disk0,id=virtio-disk0,config-wce=off,x-data-plane=on,bootindex=1 \ +-drive file=/REMOVED/REMOVED-var-config.img,if=none,id=drive-virtio-disk1,format=raw,cache=directsync,aio=native \ +-device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x15,drive=drive-virtio-disk1,id=virtio-disk1,config-wce=off,x-data-plane=on,bootindex=-1 \ +-drive file=/REMOVED/REMOVED-aux-disk.img,if=none,id=drive-ide0-0-1,format=raw,cache=directsync,discard=unmap \ +-device ide-hd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1,bootindex=-1 \ +-drive file=/REMOVED/images/0/REMOVED-platform.img,if=none,id=drive-ide1-0-1,format=raw,cache=directsync,discard=unmap \ +-device ide-hd,bus=ide.1,unit=1,drive=drive-ide1-0-1,id=ide1-0-1,bootindex=-1 \ +-msg timestamp=on \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1801933 b/results/classifier/deepseek-r1:14b/output/performance/1801933 new file mode 100644 index 000000000..9f6ccc976 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1801933 @@ -0,0 +1,25 @@ + +default memory parameter too small on x86_64 today + +Launching a centos7 VM today does not work anymore on x86_64 without increasing the size of the memory parameter. For example with this command : + +$ /opt/qemu-3.0.0/bin/qemu-system-x86_64 --curses -enable-kvm -drive file=file.dd,index=0,media=disk -drive file=centos-x86_64.iso,index=1,media=cdrom + +[ 3.047614] Failed to execute /init +[ 3.048315] Kernel panic - not syncing: No init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. +[ 3.049258] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-693.21.1.el7.x86 + + + +Increasing the size from the default 128MiB to 512MiB let the VM works without problem. +So, ok, it's not a qemu problem, it's more a "User problem" and interface problem for me. +But it push me in the end to launch VirtualBox instead of qemu, because the default parameter does not work anymore... And I had no time to investigate why it does not work because the message is not visible. +Debian iso with the same command line for example show a message to tell me that there is not enough memory, so it help me to track the real issue behind. + +But... In the end, I think today, the default memory parameter on x86_64 is too small and it can lead some people like me to switch to VirtualBox. +VirtualBox, in the wizard is set by default to 4MiB Ram size, which tell you... Ok I need to put more. But, you know that 4MiB is not enough in the end. + + +Regards, + +Johann \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1812694 b/results/classifier/deepseek-r1:14b/output/performance/1812694 new file mode 100644 index 000000000..cc90ecbb6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1812694 @@ -0,0 +1,6 @@ + +qemu-system-x86_64 version 3.0+ is 20 times slower than version 2.12 + +version 3.0+ is 20 times slower than version 2.12 +I wrote a small 64-bit operating system (SIGMAOS) in which I use the lzma decoder. unpacking the file takes 20 times slower than in version 2.12. +You can download it from https://drive.google.com/drive/folders/0B_wEiYjzVkC0ZGtkbENENzF1Nms \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1820 b/results/classifier/deepseek-r1:14b/output/performance/1820 new file mode 100644 index 000000000..54126d9d7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1820 @@ -0,0 +1,11 @@ + +whpx is slower than tcg +Description of problem: +I find whpx much slower than tcg, which is rather odd. +Steps to reproduce: +1. Enable Hyper-V +2. run qemu with **-accel whpx,kernel-irqchip=off** +Additional information: +my cpu: intel i7 6500u +memory: 8go +my gpu: intel graphics 520 hd diff --git a/results/classifier/deepseek-r1:14b/output/performance/1821 b/results/classifier/deepseek-r1:14b/output/performance/1821 new file mode 100644 index 000000000..2be09da52 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1821 @@ -0,0 +1,54 @@ + +snapshot-save very slow in 8.1-rc2 +Description of problem: +Before commit 813cd61669 ("migration: Use migration_transferred_bytes() to calculate rate_limit") the above script will take about 1.5 seconds to execute, after the commit, 1 minute 30 seconds. More RAM makes it take longer still. +Steps to reproduce: +1. Execute the script given as the command line above. +Additional information: +Creating the issue here, so it doesn't get lost and is documented. + +The following series by @juan.quintela would've avoided the regression, but seems like it never landed: https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg07971.html + +Logs: + +Before commit 813cd61669 +``` +root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh +Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +{"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 8}, "package": "v8.0.0-967-g3db9c05a90-dirty"}, "capabilities": ["oob"]}} +VNC server running on ::1:5900 +{"return": {}} +{"timestamp": {"seconds": 1691572701, "microseconds": 708660}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}} +{"timestamp": {"seconds": 1691572701, "microseconds": 708731}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572701, "microseconds": 709239}, "event": "STOP"} +{"timestamp": {"seconds": 1691572702, "microseconds": 939059}, "event": "RESUME"} +{"timestamp": {"seconds": 1691572702, "microseconds": 939565}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939605}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939638}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572702, "microseconds": 939730}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}} +{"timestamp": {"seconds": 1691572702, "microseconds": 941746}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}} +~/save-snap.sh 1.18s user 0.09s system 85% cpu 1.476 total +``` + +After commit 813cd61669 +``` +root@pve8a1 /home/febner/repos/qemu/build # time ~/save-snap.sh +Formatting '/tmp/test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16 +{"QMP": {"version": {"qemu": {"micro": 92, "minor": 0, "major": 8}, "package": "v8.1.0-rc2-102-ga8fc5165aa"}, "capabilities": ["oob"]}} +VNC server running on ::1:5900 +{"return": {}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944026}, "event": "JOB_STATUS_CHANGE", "data": {"status": "created", "id": "save0"}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944115}, "event": "JOB_STATUS_CHANGE", "data": {"status": "running", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572864, "microseconds": 944631}, "event": "STOP"} +{"timestamp": {"seconds": 1691572954, "microseconds": 697523}, "event": "RESUME"} +{"timestamp": {"seconds": 1691572954, "microseconds": 697962}, "event": "JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "save0"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 697996}, "event": "JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "save0"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 698020}, "event": "JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "save0"}} +{"return": {}} +{"timestamp": {"seconds": 1691572954, "microseconds": 698089}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}} +{"timestamp": {"seconds": 1691572954, "microseconds": 701263}, "event": "JOB_STATUS_CHANGE", "data": {"status": "null", "id": "save0"}} +~/save-snap.sh 31.81s user 41.69s system 81% cpu 1:30.03 total +``` diff --git a/results/classifier/deepseek-r1:14b/output/performance/1826401 b/results/classifier/deepseek-r1:14b/output/performance/1826401 new file mode 100644 index 000000000..230d3a4e3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1826401 @@ -0,0 +1,39 @@ + +qemu-system-aarch64 has a high cpu usage on windows + +Running qemu-system-aarch64 leads to a high CPU consumption on windows 10. + +Tested with qemu: 4.0.0-rc4 & 3.1.0 & 2.11.0 + +Command: qemu_start_command = [ + qemu-system-aarch64, + "-pidfile", + target_path + "/qemu" + str(instance) + ".pid", + "-machine", + "virt", + "-cpu", + "cortex-a57", + "-nographic", + "-smp", + "2", + "-m", + "2048", + "-kernel", + kernel_path, + "--append", + "console=ttyAMA0 root=/dev/vda2 rw ipx=" + qemu_instance_ip + "/64 net.ifnames=0 biosdevname=0", + "-drive", + "file=" + qemu_instance_img_path + ",if=none,id=blk", + "-device", + "virtio-blk-device,drive=blk", + "-netdev", + "socket,id=mynet0,udp=127.0.0.1:2000,localaddr=127.0.0.1:" + qemu_instance_port, + "-device", + "virtio-net-device,netdev=mynet0", + "-serial", + "file:" + target_path + "/qemu" + str(instance) + ".log" + ] + +*The cpu consumption is ~70%. +*No acceleration used. +*This CPU consumption is obtained only by running the above command. No workload on the guest OS. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1844 b/results/classifier/deepseek-r1:14b/output/performance/1844 new file mode 100644 index 000000000..65013e540 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1844 @@ -0,0 +1,23 @@ + +qemu process memory usage greater than windows guest memory usage +Description of problem: +The Windows Guest internal memory usage is low,but is very high on host of qemu progress. But the linux guest is no such case.Is there any way to trigger the host to reclaim virtual machine memory? +Steps to reproduce: +1.install a windows guest with 128GB of memory and start it. + +2.When the machine is stable, the VM internal memory usage is low,but is very high on host of qemu progress. + +3.on host,use "free -g" to query,the memory used is also very high + +4.when migrate or dormancy,it can recovery,but I want to know is there any way to trigger the host to reclaim virtual machine memory? + + +host: + + + + + +guest: + + diff --git a/results/classifier/deepseek-r1:14b/output/performance/1847525 b/results/classifier/deepseek-r1:14b/output/performance/1847525 new file mode 100644 index 000000000..d64d03d16 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1847525 @@ -0,0 +1,83 @@ + +qemu-system-i386 eats a lot of cpu after just few hours, with sdl,gl=on + +I already send this email to <email address hidden> , but I can't see it arriving in archives, so here is copy. + +Hello, all! + +I use qemu-system-i386/qemu-system_x86_64 for rebuilding Slax-like live cd/dvd. +Usually guests (with various self-compiled kernels and X stack with kde3 on top of them) +boot up normally, but if I left them to run in GUI mode for few hours - qemu process on host +started to eat more and more cpu for itself - more notiecable if I set host cpu to lowest possible +frequency via trayfreq applet (1400Mhz in my case). + +Boot line a bit complicated, but I really prefer to have sound and usb inside VM. +qemu-system-i386 -cdrom /dev/shm/CDROM-4.4.194_5.iso -m 1.9G -enable-kvm -soundhw es1370 -smp 2 -display sdl,gl=on -usb -cpu host -rtc clock=vm + +rtc clock=vm was taken from https://bugs.launchpad.net/qemu/+bug/1174654 but apparently not helping. +After just 3 hours of uptime (copied line from 'top' on host) + +31943 guest 20 0 2412m 791m 38m R 51 6.7 66:36.51 qemu-system-i38 + +I use Xorg 1.19.7 on host, with mesa git/nouveau as GL driver. But my card has not very big amount of VRAM - only 384Mb. +May be this limitation is playing some role .. but 'end-user' result was after 1-2 day of guest uptime I run into completely frozen guest +(may be when qemu was hitting 100 one core usage on host some internal timer just made guest kernel too upset/froze? + I was sleeping or doing other things on host for all this time, with VM just supposedly running at another virtual desktop - +in KDE3 + built-in compositor ....) + +I wonder if more mainstream desktop users (on GNOME, Xfce, etc) and/or users of other distros (I use self-re-compiled Slackware) +actually can see same problem? + +qemu-system-i386 --version +QEMU emulator version 4.1.50 (v4.1.0-1188-gc6f5012ba5-dirty) +but I saw same behavior for quite some time .. just never reported it in hope it will go away. + +cat /proc/cpuinfo +processor : 0 +vendor_id : AuthenticAMD +cpu family : 21 +model : 2 +model name : AMD FX(tm)-4300 Quad-Core Processor +stepping : 0 +microcode : 0x6000852 +cpu MHz : 1399.977 +cache size : 2048 KB +physical id : 0 +siblings : 4 +core id : 0 +cpu cores : 2 +apicid : 16 +initial apicid : 0 +fpu : yes +fpu_exception : yes +cpuid level : 13 +wp : yes +flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate ssbd vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold +bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass +bogomips : 7600.06 +TLB size : 1536 4K pages +clflush size : 64 +cache_alignment : 64 +address sizes : 48 bits physical, 48 bits virtual +power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro + +[and 3x more of the same, for 3 remaining cores] + +Gcc is Slackware 14.2's gcc 5.5.0, but I saw this with 4.9.2 too. +This might be 32-bit host problem. But may be just no-one tried to run qemu with GUI guest for literaly days? + +Host kernel is + uname -a +Linux slax 5.1.12-x64 #1 SMP PREEMPT Wed Jun 19 12:31:05 MSK 2019 x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux + +I was trying newish 5.3.2 but my compilation was not as stable as this one +(I tend to change few things, like max cpu count, preemption mode, numa support .... +for more distribution-like, yet most stable and performant for me kernel) + +Kernel world is moving fast, so I'll try to recompile new 5.3.x too .... + + +I guess I should provide perf/profiler output, but for this I need to recompile qemu. +I'll try to come back with more details soon. + +Thanks for your attention and possible feedback! \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1853042 b/results/classifier/deepseek-r1:14b/output/performance/1853042 new file mode 100644 index 000000000..b9e0ae11d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1853042 @@ -0,0 +1,82 @@ + +Ubuntu 18.04 - vm disk i/o performance issue when using file system passthrough + +== Comment: #0 - I-HSIN CHUNG <email address hidden> - 2019-11-15 12:35:05 == +---Problem Description--- +Ubuntu 18.04 - vm disk i/o performance issue when using file system passthrough + +Contact Information = <email address hidden> + +---uname output--- +Linux css-host-22 4.15.0-1039-ibm-gt #41-Ubuntu SMP Wed Oct 2 10:52:25 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux (host) Linux ubuntu 4.15.0-65-generic #74-Ubuntu SMP Tue Sep 17 17:08:54 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux (vm) + +Machine Type = p9/ac922 + +---Debugger--- +A debugger is not configured + +---Steps to Reproduce--- + 1. Env: Ubuntu 18.04.3 LTS?Genesis kernel linux-ibm-gt - 4.15.0-1039.41?qemu 1:2.11+dfsg-1ubuntu7.18 ibmcloud0.3 or 1:2.11+dfsg-1ubuntu7.19 ibm-cloud1?fio-3.15-4-g029b + +2. execute run.sh to run fio benchmark: + +2.1) run.sh: +#!/bin/bash + +for bs in 4k 16m +do + +for rwmixread in 0 25 50 75 100 +do + +for numjobs in 1 4 16 64 +do +echo ./fio j1.txt --bs=$bs --rwmixread=$rwmixread --numjobs=$numjobs +./fio j1.txt --bs=$bs --rwmixread=$rwmixread --numjobs=$numjobs + +done +done +done + +2.2) j1.txt: + +[global] +direct=1 +rw=randrw +refill_buffers +norandommap +randrepeat=0 +ioengine=libaio +iodepth=64 +runtime=60 + +allow_mounted_write=1 + +[job2] +new_group +filename=/dev/vdb +filesize=1000g +cpus_allowed=0-63 +numa_cpu_nodes=0 +numa_mem_policy=bind:0 + +3. performance profile: +device passthrough performance for the nvme: +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm/20191011-112156/html/#/measurement/vm/ubuntu (I/O bandwidth achieved inside VM in GB/s range) + +file system passthrough +http://css-host-22.watson.ibm.com/rundir/nvme_vm_perf_vm/20191106-123613/html/#/measurement/vm/ubuntu (I/o bandwidth achieved inside the VM is very low) + +desired performance when using file system passthrough should be similar to the device passthrough + +Userspace tool common name: fio + +The userspace tool has the following bit modes: should be 64 bit + +Userspace rpm: ? + +Userspace tool obtained from project website: na + +*Additional Instructions for <email address hidden>: +-Post a private note with access information to the machine that the bug is occuring on. +-Attach ltrace and strace of userspace application. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1857 b/results/classifier/deepseek-r1:14b/output/performance/1857 new file mode 100644 index 000000000..dc542eb71 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1857 @@ -0,0 +1,53 @@ + +Major qemu-aarch64 performance slowdown since commit 59b6b42cd3 +Description of problem: +I have observed a major performance slowdown between qemu 8.0.0 and 8.1.0: + + +qemu 8.0.0: 0.8s + +qemu 8.1.0: 6.8s + + +After bisecting the commits between 8.0.0 and 8.1.0, the offending commit is 59b6b42cd3: + + +commit 59b6b42cd3446862567637f3a7ab31d69c9bef51 +Author: Richard Henderson <richard.henderson@linaro.org> +Date: Tue Jun 6 10:19:39 2023 +0100 + + target/arm: Enable FEAT_LSE2 for -cpu max + + Reviewed-by: Peter Maydell <peter.maydell@linaro.org> + Signed-off-by: Richard Henderson <richard.henderson@linaro.org> + Message-id: 20230530191438.411344-21-richard.henderson@linaro.org + Signed-off-by: Peter Maydell <peter.maydell@linaro.org> + + +Reverting the commit in latest master fixes the problem: + +qemu 8.0.0: 0.8s + +qemu 8.1.0: 6.8s + +qemu master + revert 59b6b42cd3: 0.8s + +Alternatively, specify `-cpu cortex-a35` to disable LSE2: + +`time ./qemu-aarch64 -cpu cortex-a35`: 0.8s + +`time ./qemu-aarch64`: 6.77s + +The slowdown is also observed when running qemu-aarch64 on aarch64 machine: + +`time ./qemu-aarch64 /usr/bin/node -e 1`: 2.91s + +`time ./qemu-aarch64 -cpu cortex-a35 /usr/bin/node -e 1`: 1.77s + +The slowdown on x86_64 machine is small: 362ms -> 378ms. +Steps to reproduce: +1. Run `time ./qemu-aarch64 node-aarch64 -e 1` (node-aarch64 is NodeJS v16 built for AArch64) +2. Using qemu master, the output says `0.8s` +3. Using qemu master with commit 59b6b42cd3 reverted, the output says `6.77s` +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/performance/1860610 b/results/classifier/deepseek-r1:14b/output/performance/1860610 new file mode 100644 index 000000000..a07e88390 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1860610 @@ -0,0 +1,8 @@ + +cap_disas_plugin leaks memory + +Looking at origin/master head, the function cap_disas_plugin leaks memory. + +per capstone's examples using their ABI, cs_free(insn, count); needs to called just before cs_close. + +I discovered this running qemu under valgrind. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1873032 b/results/classifier/deepseek-r1:14b/output/performance/1873032 new file mode 100644 index 000000000..f33941e51 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1873032 @@ -0,0 +1,17 @@ + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +Description of problem: + +After upgrade qemu to 5.0.0-0.3.rc2.fc33 the virtual machine with Windows 10 after a while starts to work very slowly + +I created the virtual machine with Windows 10 with the following config: +- 1 CPU +- 2GB RAM +- With network access + +I launch there a web browser there with flash content. +And usually, the system (Windows 10) does not work there for more than an hour. +When the system starts to work very slowly it doesn't respond to "Reboot" and "Shut Down" commands. Only works "Force Reset" and "Force Off". But when I reboot the system with "Force Reset" it usually stuck at boot at the Windows splash screen. https://imgur.com/yGyacDG + +The last version of qemu which not contain this issue is 5.0.0-0.2.rc0.fc33 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1875762 b/results/classifier/deepseek-r1:14b/output/performance/1875762 new file mode 100644 index 000000000..bfd41f503 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1875762 @@ -0,0 +1,12 @@ + +Poor disk performance on sparse VMDKs + +Found in QEMU 4.1, and reproduced on master. + +QEMU appears to suffer from remarkably poor disk performance when writing to sparse-extent VMDKs. Of course it's to be expected that allocation takes time and sparse VMDKs peform worse than allocated VMDKs, but surely not on the orders of magnitude I'm observing. On my system, the fully allocated write speeds are approximately 1.5GB/s, while the fully sparse write speeds can be as low as 10MB/s. I've noticed that adding "cache unsafe" reduces the issue dramatically, bringing speeds up to around 750MB/s. I don't know if this is still slow or if this perhaps reveals a problem with the default caching method. + +To reproduce the issue I've attached two 4GiB VMDKs. Both are completely empty and both are technically sparse-extent VMDKs, but one is 100% pre-allocated and the other is 100% unallocated. If you attach these VMDKs as second and third disks to an Ubuntu VM running on QEMU (with KVM) and measure their write performance (using dd to write to /dev/sdb and /dev/sdc for example) the difference in write speeds is clear. + +For what it's worth, the flags I'm using that relate to the VMDK are as follows: + +`-drive if=none,file=sparse.vmdk,id=hd0,format=vmdk -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd0` \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1877137 b/results/classifier/deepseek-r1:14b/output/performance/1877137 new file mode 100644 index 000000000..b9ced62b3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1877137 @@ -0,0 +1,17 @@ + +32-bit Arm emulation spins at 100% during emacs build + +This test case exposes a QEMU bug when crossbuilding to arm32. The bug is only +exposed on amd64 architecture or aarch64 hosts that can *only* execute +64 bit applications. + +Usage: + +./setup.sh # installs docker and tweaks sysctl +./qemu.sh # register qemu so you are able to run containers from other +architectures +./build.sh # try to build the docker image. Process should get stuck +in a 100% CPU loop after a while + +Originally reported by, and test case developed by, +Philippe Vaucher. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1877716 b/results/classifier/deepseek-r1:14b/output/performance/1877716 new file mode 100644 index 000000000..7fbba82e0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1877716 @@ -0,0 +1,14 @@ + +Win10 guest unusable after a few minutes + +On Arch Linux, the recent qemu package update seems to misbehave on some systems. In my case, my Windows 10 guest runs fine for around 5 minutes and then start to get really sluggish, even unresponsive. It needs to be forced off. I could reproduce this on a minimal VM with no passthrough, although my current testing setup involves an nvme pcie passthrough. + +I bisected it to the following commit which rapidly starts to run sluggishly on my setup: +https://github.com/qemu/qemu/commit/73fd282e7b6dd4e4ea1c3bbb3d302c8db51e4ccf + +I've ran the previous commit ( https://github.com/qemu/qemu/commit/b321051cf48ccc2d3d832af111d688f2282f089b ) for the entire night without an issue so far. + +I believe this might be a duplicate of https://bugs.launchpad.net/qemu/+bug/1873032 , although I'm not sure. + +Linux cc 5.6.10-arch1-1 #1 SMP PREEMPT Sat, 02 May 2020 19:11:54 +0000 x86_64 GNU/Linux +AMD Ryzen 7 2700X Eight-Core Processor \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1882497 b/results/classifier/deepseek-r1:14b/output/performance/1882497 new file mode 100644 index 000000000..ef5ac3973 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1882497 @@ -0,0 +1,8 @@ + +Missing 'cmp' utility makes build take 10 times as long + +I have been doing some work cross compiling qemu for Windows using a minimal Fedora container. Recently I started hitting some timeouts on the CI service and noticed a build of all targets was going over 1 hour. + +It seems like the 'cmp' utility from diffutils is used somewhere in the process and if it's missing, either a configure or a make gets run way too many times - I'll try to pull logs from the CI system at some stage soon. + +Could a warning or error be added if cmp is missing? \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1883400 b/results/classifier/deepseek-r1:14b/output/performance/1883400 new file mode 100644 index 000000000..93a79d099 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1883400 @@ -0,0 +1,19 @@ + +Windows 10 extremely slow and unresponsive + +Hi, + +Fedora 32, x64 +qemu-5.0.0-2.fc32.x86_64 + +https://www.microsoft.com/en-us/software-download/windows10ISO +Win10_2004_English_x64.iso + +Windows 10 is excruciatingly slow since upgrading to 5.0.0-2.fc32. Disabling your repo and downgrading to 2:4.2.0-7.fc32 and corrects the issue (the package in the Fedora repo). + +You can duplicate this off of the Windows 10 ISO (see above) and do not even have to install Windows 10 itself. + +Please fix, + +Many thanks, +-T \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1886306 b/results/classifier/deepseek-r1:14b/output/performance/1886306 new file mode 100644 index 000000000..ed2e5fd8d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1886306 @@ -0,0 +1,10 @@ + +qemu running slow when the window is in background + +Reported by <jedinix> on IRC: + +QEMU almost freezes when running with `GDK_BACKEND=x11` set and the parameter `gl=on` added to the `-display` option. + +GDK_BACKEND=x11 qemu-system-x86_64 -nodefaults -no-user-config -enable-kvm -machine q35 -cpu host -m 4G -display gtk,gl=on -vga std -usb -device usb-kbd -drive file=/tmp/Win10.qcow2,media=disk,format=qcow2 -drive file=~/Downloads/Win10_2004_EnglishInternational_x64.iso,media=cdrom + +Leaving out `GDK_BACKEND=x11` or `gl=on` fixes the issue. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1886602 b/results/classifier/deepseek-r1:14b/output/performance/1886602 new file mode 100644 index 000000000..082c88e1f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1886602 @@ -0,0 +1,13 @@ + +Windows 10 very slow with OVMF + +Debian Buster + +Kernel 4.19.0-9-amd64 +qemu-kvm 1:3.1+dfsg-8+deb10u5 +ovmf 0~20181115.85588389-3+deb10u1 + +Machine: Thinkpad T470, i7-7500u, 20GB RAM +VM: 4 CPUs, 8GB RAM, Broadwell-noTSX CPU Model + +Windows 10, under this VM, seems to be exceedingly slow with all operations. This is a clean install with very few services running. Task Manager can take 30% CPU looking at an idle system. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1892081 b/results/classifier/deepseek-r1:14b/output/performance/1892081 new file mode 100644 index 000000000..d7d166397 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1892081 @@ -0,0 +1,15 @@ + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions + +Attached below is a matrix multiplication program for double data +types. The program performs the casting operation "(double)rand()" +when generating random numbers. + +This operation calls the integer to float softfloat conversion +function "int32_to_float_64". + +Adding the "QEMU_FLATTEN" attribute to the function definition +decreases the instructions per call of the function by about 63%. + +Attached are before and after performance screenshots from +KCachegrind. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1895703 b/results/classifier/deepseek-r1:14b/output/performance/1895703 new file mode 100644 index 000000000..0bfcbaccf --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1895703 @@ -0,0 +1,19 @@ + +performance degradation in tcg since Meson switch + +The buildsys conversion to Meson (1d806cef0e3..7fd51e68c34) +introduced a degradation in performance in some TCG targets: + +-------------------------------------------------------- +Test Program: matmult_double +-------------------------------------------------------- +Target Instructions Previous Latest + 1d806cef 7fd51e68 +---------- -------------------- ---------- ---------- +alpha 3 233 957 639 ----- +7.472% +m68k 3 919 110 506 ----- +18.433% +-------------------------------------------------------- + +Original report from Ahmed Karaman with further testing done +by Aleksandar Markovic: +https://<email address hidden>/msg740279.html \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1896298 b/results/classifier/deepseek-r1:14b/output/performance/1896298 new file mode 100644 index 000000000..2781f258b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1896298 @@ -0,0 +1,20 @@ + +TCG memory leak with FreeDOS 'edit' + +qemu trunk as of today leaks memory FAST when freedos' edit is running. + +To reproduce, download: + +https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/cdrom.iso + +Then run: + +$ qemu-system-i386 -cdrom cdrom.iso + +select your language then select "return to DOS", then type + +> edit + +it will consume memory at ~10MB/s + +This does NOT happen when adding -enable-kvm \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1896754 b/results/classifier/deepseek-r1:14b/output/performance/1896754 new file mode 100644 index 000000000..5be9f3567 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1896754 @@ -0,0 +1,6 @@ + +Performance degradation for WinXP boot time after b55f54bc + +Qemu 5.1 loads Windows XP in TCG mode 5-6 times slower (~2 minutes) than 4.2 (25 seconds), I git bisected it, and it appears that commit b55f54bc965607c45b5010a107a792ba333ba654 causes this issue. Probably similar to an older fixed bug https://bugs.launchpad.net/qemu/+bug/1672383 + +Command line is trivial: qemu-system-x86_64 -nodefaults -vga std -m 4096M -hda WinXP.qcow2 -monitor stdio -snapshot \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1910505 b/results/classifier/deepseek-r1:14b/output/performance/1910505 new file mode 100644 index 000000000..381a4f8f8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1910505 @@ -0,0 +1,68 @@ + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts + +As of commit 50536341b47, using --enable-sanitizers on 32-bit Linux host: +- displays various warnings +- fails linking + +Using Ubuntu 18.04 (release 20201211.1) and Clang10 on i386: + +[139/675] Compiling C object softmmu.fa.p/softmmu_icount.c.o +In file included from ../softmmu/icount.c:31: +In file included from include/exec/exec-all.h:23: +In file included from ../target/mips/cpu.h:4: +In file included from ../target/mips/cpu-qom.h:23: +In file included from include/hw/core/cpu.h:23: +In file included from include/hw/qdev-core.h:5: +In file included from include/qemu/bitmap.h:16: +In file included from include/qemu/bitops.h:17: +include/qemu/atomic.h:463:12: warning: misaligned atomic operation may +incur significant performance penalty [-Watomic-alignment] + return qatomic_read__nocheck(ptr); + ^ +include/qemu/atomic.h:129:5: note: expanded from macro +'qatomic_read__nocheck' + __atomic_load_n(ptr, __ATOMIC_RELAXED) + ^ +include/qemu/atomic.h:473:5: warning: misaligned atomic operation may +incur significant performance penalty [-Watomic-alignment] + qatomic_set__nocheck(ptr, val); + ^ +include/qemu/atomic.h:138:5: note: expanded from macro +'qatomic_set__nocheck' + __atomic_store_n(ptr, i, __ATOMIC_RELAXED) + ^ +2 warnings generated. +[...] + +[850/2216] Linking target tests/test-hbitmap +FAILED: tests/test-hbitmap +clang -o tests/test-hbitmap tests/test-hbitmap.p/test-hbitmap.c.o +tests/test-hbitmap.p/iothread.c.o -Wl,--as-needed -Wl,--no-undefined +-pie -Wl,--whole-archive libblock.fa libcrypto.fa libauthz.fa libqom.fa +libio.fa -Wl,--no-whole-archive -Wl,--warn-common -fsanitize=undefined +-fsanitize=address -Wl,-z,relro -Wl,-z,now -m32 -ggdb +-fstack-protector-strong -Wl,--start-group libqemuutil.a +subprojects/libvhost-user/libvhost-user-glib.a +subprojects/libvhost-user/libvhost-user.a libblock.fa libcrypto.fa +libauthz.fa libqom.fa libio.fa @block.syms -lgio-2.0 -lgobject-2.0 +-lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -pthread -lutil -lgnutls +-lm -lgthread-2.0 -lglib-2.0 /usr/lib/i386-linux-gnu/libglib-2.0.so +-liscsi -lgthread-2.0 -lglib-2.0 -laio -lcurl +/usr/lib/i386-linux-gnu/libz.so -lrbd -lrados -lnettle -lgnutls +-Wl,--end-group +libblock.fa(block_io.c.o): In function `stat64_max': +include/qemu/stats64.h:58: undefined reference to `__atomic_load_8' +include/qemu/stats64.h:60: undefined reference to +`__atomic_compare_exchange_8' +libblock.fa(block_qapi.c.o): In function `stat64_get': +include/qemu/stats64.h:40: undefined reference to `__atomic_load_8' +libqemuutil.a(util_qsp.c.o): In function `qatomic_set_u64': +include/qemu/atomic.h:478: undefined reference to `__atomic_store_8' +libqemuutil.a(util_qsp.c.o): In function `qatomic_read_u64': +include/qemu/atomic.h:468: undefined reference to `__atomic_load_8' +clang: error: linker command failed with exit code 1 (use -v to see +invocation) + +Issue previously reported on the list here: +https://<email address hidden>/msg770128.html \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1913505 b/results/classifier/deepseek-r1:14b/output/performance/1913505 new file mode 100644 index 000000000..7e362a32d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1913505 @@ -0,0 +1,13 @@ + +Windows XP slow on Apple M1 + +Qemu installed by using brew install qemu -s on M1 + +QEMU emulator version 5.2.0 +XP image from: https://archive.org/details/WinXPProSP3x86 + +Commands run: +$ qemu-img create -f qcow2 xpsp3.img 10G +$ qemu-system-i386 -m 512 -hda xpsp3.img -cdrom WinXPProSP3x86/en_windows_xp_professional_with_service_pack_3_x86_cd_vl_x14-73974.iso -boot d + +It's taken 3 days now with qemu running at around 94% CPU and installation hasn't finished. The mouse pointer moves and occasionally changes between the pointer and hourglass so it doesn't seem to have frozen. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1914667 b/results/classifier/deepseek-r1:14b/output/performance/1914667 new file mode 100644 index 000000000..461602bb4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1914667 @@ -0,0 +1,21 @@ + +High cpu usage when guest is idle on qemu-system-i386 + +When running Windows XP in qemu-system-i386, the cpu usage of QEMU is about 100% even when the guest CPU usage is close to 2%. The host cpu usage should be low when the guest cpu usage is low. + +Command: qemu-system-i386 -hda <Windows XP HD image> + +Using this command also shows around 100% host CPU usage: +qemu-system-i386 -m 700 -hda <Windows XP HD image> -usb -device usb-audio -net nic,model=rtl8139 -net user -hdb mountable.img -soundhw pcspk + +Using the Penryn CPU option also saw this problem: +qemu-system-i386 -hda <Windows XP HD image> -m 700 -cpu Penryn-v1 + +Using "-cpu pentium2" saw the same high host cpu usage. + + +My Info: +M1 MacBook Air +Mac OS 11.1 +qemu-system-i386 version 5.2 (1ba089f2255bfdb071be3ce6ac6c3069e8012179) +Windows XP SP3 Build 2600 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1917542 b/results/classifier/deepseek-r1:14b/output/performance/1917542 new file mode 100644 index 000000000..9d2ca4506 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1917542 @@ -0,0 +1,139 @@ + +qemu-img crash on M1 Mac + +1. Symptom +$ qemu-img create -f qcow2 disk.qcow2 10G +[1] 72373 killed qemu-img create -f qcow2 disk.qcow2 10G + +2. System environment +CPU: Apple M1 +OS: Big Sur 11.2.2 +qemu: stable 5.2.0 (Binary installed by homebrew) + +3. Kernel logs +$ sudo log show --predicate ‘eventMessage LIKE “qemu”’ --debug +ntID Dirty: 1 Event: com.apple.stability.crash {“appVersion”:"???",“exceptionType”:1,“logwritten”:1,“process”:“qemu-img”,“responsibleApp”:“iTerm2”,“timestamp”:1614666875993238} +2021-03-02 15:36:52.728210+0900 0xfb308 Default 0x0 0 0 kernel: CODE SIGNING: cs_invalid_page(0x102930000): p=72373[qemu-img] final status 0x23000200, denying page sending SIGKILL +2021-03-02 15:36:52.728222+0900 0xfb308 Default 0x0 0 0 kernel: CODE SIGNING: process 72373[qemu-img]: rejecting invalid page at address 0x102930000 from offset 0x0 in file “/opt/homebrew/Cellar/libssh/0.9.5_1/lib/libssh.4.8.6.dylib” (cs_mtime:1614297740.413435328 == mtime:1614297740.413435328) (signed:1 validated:1 tainted:1 nx:0 wpmapped:0 dirty:0 depth:0) +2021-03-02 15:36:52.728477+0900 0xfab09 Default 0x0 919 0 ReportCrash: Parsing corpse data for process qemu-img [pid 72373] +2021-03-02 15:36:52.884736+0900 0xfab09 Default 0x0 919 0 ReportCrash: (CrashReporterSupport) Saved crash report for qemu-img[72373] version 0 to qemu-img_2021-03-02-153652_.crash + +4. Crash logs +$ sudo cat /Users//Library/Logs/DiagnosticReports/qemu-img_2021-03-02-153652_.crash +Process: qemu-img [72373] +Path: /opt/homebrew/*/qemu-img +Identifier: qemu-img +Version: 0 +Code Type: ARM-64 (Native) +Parent Process: zsh [67484] +Responsible: iTerm2 [556] +User ID: 501 + +Date/Time: 2021-03-02 15:36:52.710 +0900 +OS Version: macOS 11.2.2 (20D80) +Report Version: 12 +Anonymous UUID: AF87D5F0-2BED-EB72-1DC8-26F63A24DA7C + +Sleep/Wake UUID: 3862EA39-132E-42BD-A4BB-5A36F36607F1 + +Time Awake Since Boot: 89000 seconds +Time Since Wake: 520 seconds + +System Integrity Protection: enabled + +Crashed Thread: 0 + +Exception Type: EXC_BAD_ACCESS (Code Signature Invalid) +Exception Codes: 0x0000000000000032, 0x0000000102930000 +Exception Note: EXC_CORPSE_NOTIFY + +Termination Reason: Namespace CODESIGNING, Code 0x2 + +kernel messages: + +VM Regions Near 0x102930000: +__LINKEDIT 102908000-102930000 [ 160K] r–/r-- SM=COW /opt/homebrew/* +→ mapped file 102930000-102934000 [ 16K] r–/r-x SM=PRV Object_id=fc8cc3db +__TEXT 1029bc000-102a38000 [ 496K] r-x/r-x SM=COW /usr/lib/dyld + +Application Specific Information: +dyld: launch, loading dependent libraries +/opt/homebrew/opt/libssh/lib/libssh.4.dylib + +Thread 0 Crashed: +0 dyld 0x0000000102a18780 bcmp + 16 +1 dyld 0x00000001029d9408 ImageLoaderMachO::validateFirstPages(linkedit_data_command const*, int, unsigned char const*, unsigned long, long long, ImageLoader::LinkContext const&) + 136 +2 dyld 0x00000001029e03b8 ImageLoaderMachOCompressed::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, unsigned int, unsigned int, linkedit_data_command const*, encryption_info_command const*, ImageLoader::LinkContext const&) + 268 +3 dyld 0x00000001029d7ffc ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char const*, unsigned long, unsigned long long, unsigned long long, stat const&, ImageLoader::LinkContext const&) + 172 +4 dyld 0x00000001029c0290 dyld::loadPhase6(int, stat const&, char const*, dyld::LoadContext const&) + 668 +5 dyld 0x00000001029c8dd8 dyld::loadPhase5(char const*, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >) + 1328 +6 dyld 0x00000001029c8824 dyld::loadPhase4(char const, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >) + 208 +7 dyld 0x00000001029c8530 dyld::loadPhase3(char const, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >) + 1100 +8 dyld 0x00000001029c7cf0 dyld::loadPhase1(char const, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >) + 212 +9 dyld 0x00000001029bfe0c dyld::loadPhase0(char const, char const*, dyld::LoadContext const&, unsigned int&, std::__1::vector<char const*, std::__1::allocator<char const*> >) + 468 +10 dyld 0x00000001029bf9b0 dyld::load(char const, dyld::LoadContext const&, unsigned int&) + 196 +11 dyld 0x00000001029c977c dyld::libraryLocator(char const*, bool, char const*, ImageLoader::RPathChain const*, unsigned int&) + 56 +12 dyld 0x00000001029d39d4 ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&, bool, ImageLoader::RPathChain const&, char const*) + 344 +13 dyld 0x00000001029d21ac ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&, char const*) + 160 +14 dyld 0x00000001029c25f4 dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&, unsigned int) + 328 +15 dyld 0x00000001029c4928 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6764 +16 dyld 0x00000001029bd258 dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 476 +17 dyld 0x00000001029bd038 _dyld_start + 56 + +Thread 0 crashed with ARM Thread State (64-bit): +x0: 0x0000000102930000 x1: 0x000000016d6297c0 x2: 0x0000000000000850 x3: 0x0000000000040001 +x4: 0x0000000000000003 x5: 0x0000000000000000 x6: 0x0000000102a40280 x7: 0x0000000000000000 +x8: 0x0000000000000000 x9: 0x000000016d629ea8 x10: 0x0000000000000001 x11: 0x0001803000000000 +x12: 0x0000000000000032 x13: 0x0004000000000000 x14: 0x0000000000062530 x15: 0x000000016d629e28 +x16: 0x00000000000000c5 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000102a45cc0 +x20: 0x0000000000000860 x21: 0x000000016d6297c0 x22: 0x0000000102930000 x23: 0x0000000000000003 +x24: 0x000000016d62a010 x25: 0x000000016d6318d8 x26: 0x00000001027cc970 x27: 0x000000016d6297c0 +x28: 0x0000000000000004 fp: 0x000000016d6291c0 lr: 0x00000001029d9408 +sp: 0x000000016d629180 pc: 0x0000000102a18780 cpsr: 0x20000000 +far: 0x0000000102930000 esr: 0x92000007 + +Binary Images: +0x1027cc000 - 0x1028ebfff +qemu-img (0) /opt/homebrew//qemu-img +0x1029bc000 - 0x102a37fff dyld (832.7.3) <4AB185B3-DC20-3C03-A193-67C0E6C589D7> /usr/lib/dyld +0x102ac0000 - 0x102bbffff +libglib-2.0.0.dylib (0) /opt/homebrew//libglib-2.0.0.dylib +0x102bf4000 - 0x102d1bfff +libgnutls.30.dylib (0) <74A67886-3907-3E35-B0A3-8A5798F97283> /opt/homebrew/*/libgnutls.30.dylib +0x191db9000 - 0x192262fff com.apple.CoreFoundation (6.9 - 1774.101) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x1944af000 - 0x194579fff com.apple.framework.IOKit (2.0.2 - 1845.81.1) <516911DA-18D7-3D17-8646-BBF7C75CD070> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit +0x19b3b6000 - 0x19b3b7fff libSystem.B.dylib (1292.60.1) /usr/lib/libSystem.B.dylib +0x19b635000 - 0x19b639fff libpam.2.dylib (28.40.1) /usr/lib/libpam.2.dylib + +External Modification Summary: +Calls made by other processes targeting this process: +task_for_pid: 0 +thread_create: 0 +thread_set_state: 0 +Calls made by this process: +task_for_pid: 0 +thread_create: 0 +thread_set_state: 0 +Calls made by all processes on this machine: +task_for_pid: 81731 +thread_create: 0 +thread_set_state: 8 + +VM Region Summary: +ReadOnly portion of Libraries: Total=489.5M resident=0K(0%) swapped_out_or_unallocated=489.5M(100%) +Writable regions: Total=8400K written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=8400K(100%) + + VIRTUAL REGION +REGION TYPE SIZE COUNT (non-coalesced) +=========== ======= ======= +STACK GUARD 56.0M 1 +Stack 8176K 1 +__AUTH 7K 2 +__AUTH_CONST 926K 4 +__DATA 371K 10 +__DATA_CONST 2209K 7 +__DATA_DIRTY 32K 2 +__LINKEDIT 480.3M 6 +__OBJC_CONST 28K 2 +__TEXT 9472K 8 +__UNICODE 588K 1 +mapped file 16K 1 +=========== ======= ======= +TOTAL 557.6M 45 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1920767 b/results/classifier/deepseek-r1:14b/output/performance/1920767 new file mode 100644 index 000000000..de9d4f25b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1920767 @@ -0,0 +1,8 @@ + +build-tools-and-docs-debian job waste cycles building pointless things + +The build-tools-and-docs-debian job waste CI cycles building softfloat: +https://gitlab.com/qemu-project/qemu/-/jobs/1117005759 + +Possible fix suggested on the list: +https://<email address hidden>/msg793872.html \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/1923648 b/results/classifier/deepseek-r1:14b/output/performance/1923648 new file mode 100644 index 000000000..ba5362bea --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/1923648 @@ -0,0 +1,26 @@ + +macOS App Nap feature gradually freezes QEMU process + +macOS version: 10.15.2 +QEMU versions: 5.2.0 (from MacPorts) + 5.2.92 (v6.0.0-rc2-23-g9692c7b037) + +If the QEMU window is not visible (hidden, minimized or another application is in full screen mode), the QEMU process gradually freezes: it still runs, but the VM does not respond to external requests such as Telnet or SSH until the QEMU window is visible on the desktop. + +This behavior is due to the work of the macOS App Nap function: +https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/AppNap.html#//apple_ref/doc/uid/TP40013929-CH2-SW1 + +It doesn't matter how the process is started -- as a background job or as a foreground shell process in case QEMU has a desktop window. + +My VM does not have a display output, only a serial line, most likely if the VM was using OpenGL, or playing sound (or any other App Nap triggers), then the problem would never have been detected. + +In my case only one starting way without this problem: +sudo qemu-system-x86_64 -nodefaults \ +-cpu host -accel hvf -smp 1 -m 384 \ +-device virtio-blk-pci,drive=flash0 \ +-drive file=/vios-adventerprisek9-m.vmdk.SPA.156-1.T.vmdk,if=none,format=vmdk,id=flash0 \ +-device e1000,netdev=local -netdev tap,id=local,ifname=tap0,script=no,downscript=no \ +-serial stdio -display none + +The typical way from the internet to disable App Nap doesn't work: +defaults write NSGlobalDomain NSAppSleepDisabled -bool YES \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/2137 b/results/classifier/deepseek-r1:14b/output/performance/2137 new file mode 100644 index 000000000..a3b4befea --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2137 @@ -0,0 +1,2 @@ + +RISC-V Vector Slowdowns diff --git a/results/classifier/deepseek-r1:14b/output/performance/2162 b/results/classifier/deepseek-r1:14b/output/performance/2162 new file mode 100644 index 000000000..4ae2f7400 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2162 @@ -0,0 +1,2 @@ + +Some subtests have over-optimistic timeouts and time out on the s390 runner diff --git a/results/classifier/deepseek-r1:14b/output/performance/2181 b/results/classifier/deepseek-r1:14b/output/performance/2181 new file mode 100644 index 000000000..b74ec2124 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2181 @@ -0,0 +1,4 @@ + +-icount mips/gips/kips options on QEMU for more advanced icount option +Additional information: +Changing IPS in QEMU affects the frequency of VGA updates, the duration of time before a key starts to autorepeat, and the measurement of BogoMips and other benchmarks. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2183 b/results/classifier/deepseek-r1:14b/output/performance/2183 new file mode 100644 index 000000000..acb77a9a4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2183 @@ -0,0 +1,21 @@ + +aarch-64 emulation much slower since release 8.1.5 (issue also present on 8.2.1) +Description of problem: +Since QEMU 8.1.5 our aarch64 based emulation got much slower. We use a linux 5.4 kernel which we cross-compile with the ARM toolchain. Things that are noticable: +- Boot time got a lot longer +- All memory accesses seem to take 3x longer (can be verified by e.g. executing below script, address does not matter): +``` +date +for i in $(seq 0 1000); do + devmem 0x200000000 2>/dev/null +done +date +``` +Steps to reproduce: +Just boot an ARM based kernel on the virt machine and execute above script. +Additional information: +I've tried reproducing the issue on the master branch. There the issue is not present. It only seems to be present on releases 8.1.5 and 8.2.1. + +I've narrowed the problem down to following commit on the 8.2 branch (@bonzini): ef74024b76bf285e247add8538c11cb3c7399a1a accel/tcg: Revert mapping of PCREL translation block to multiple virtual addresses. + +Let me know if any other information / tests are required. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2193 b/results/classifier/deepseek-r1:14b/output/performance/2193 new file mode 100644 index 000000000..350ec9fd0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2193 @@ -0,0 +1,31 @@ + +qemu-system-mips64el 70 times slower than qemu -ppc64, -riscv64, -s390x +Description of problem: +I installed Debian 12 inside a `qemu-system-mips64el` virtual machine. The performances are awfully slow, roughly 70 times slower than other qemu targets on the same host, namely ppc64, riscv64, s390x. + +The idea is to recompile and test an open source project on various platforms. + +Using a command such as `time make path/to/bin/file.o`, I compiled one single source file on the host and within qemu for various targets. The same source file, inside the same project, is used in all cases. + +The results are shown below (the "x" number between parentheses is the time factor compared to the compilation on the host). + +- Host (native): 0m1.316s +- qemu-system-ppc64: 0m31.622s (x24) +- qemu-system-riscv64: 0m40.691s (x31) +- qemu-system-s390x: 0m43.459s (x33) +- qemu-system-mips64el: 48m33.587s (x2214) + +The compilation of the same source is 24 to 33 times slower on the first three emulated targets, compared to the same compilation on the host, which is understandable. However, the same compilation on the mips64el target is 2214 time slower than the host, roughly 70 times slower than other emulated targets. + +Why do we have such a tremendous difference between qemu mips64el and other targets? +Additional information: +For reference, here are the other qemu to boot the other targets. Guest OS are Debian 12 or Ubuntu 22. +``` +qemu-system-ppc64 -smp 8 -m 8192 -nographic ... +qemu-system-riscv64 -machine virt -smp 8 -m 8192 -nographic ... +qemu-system-s390x -machine s390-ccw-virtio -cpu max,zpci=on -smp 8 -m 8192 -nographic ... +``` + +The other targets use `-smp 8` while qemu-system-mips64el does not support smp. However, the test compiles one single source file and does not (or marginally) use more than one CPU. + +Arguably, each compilation addresses a different target, uses a different backend, and the compilation time is not necessarily identical. OK, but 70 times slower seems way too much for this. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2216 b/results/classifier/deepseek-r1:14b/output/performance/2216 new file mode 100644 index 000000000..d3cc3cc90 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2216 @@ -0,0 +1,4 @@ + +Incresaed artifacts generation speed with paralleled process +Additional information: +`parallel-jobs` was referenced `main` diff --git a/results/classifier/deepseek-r1:14b/output/performance/229 b/results/classifier/deepseek-r1:14b/output/performance/229 new file mode 100644 index 000000000..5cf54b2ac --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/229 @@ -0,0 +1,2 @@ + +build-tools-and-docs-debian job waste cycles building pointless things diff --git a/results/classifier/deepseek-r1:14b/output/performance/2298 b/results/classifier/deepseek-r1:14b/output/performance/2298 new file mode 100644 index 000000000..a76928ef5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2298 @@ -0,0 +1,13 @@ + +Invariant result in opts-visitor.c +Description of problem: +Expressions: +1) val2 <= INT64_MAX +2) INT64_MIN <= val2 +in line [431](https://github.com/qemu/qemu/blob/62dbe54c24dbf77051bafe1039c31ddc8f37602d/qapi/opts-visitor.c#L431) are always true. + +Seems like this checks are redundant. + +Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE. + +Author A. Burke. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2460 b/results/classifier/deepseek-r1:14b/output/performance/2460 new file mode 100644 index 000000000..7118b90e1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2460 @@ -0,0 +1,9 @@ + +Significant performance degradation of qemu-x86_64 starting from version 3 on aarch64 +Description of problem: +When I ran CoreMark with different qemu user-mode versions，guest x86-64-> host arm64, I found that the performance was highest with QEMU 2.x versions, and there was a significant performance degradation starting from QEMU version 3. What is the reason? + +| | | | | | | | | | | | | +|------------------------------------------|-------------|-------------|-------------|-------------|-------------|-------------|------------|-------------|-------------|-------------|-------------| +| qemu version | 2.5.1 | 2.8.0 | 2.9.0 | 2.9.1 | 3.0.0 | 4.0.0 | 5.2.0 | 6.2.0 | 7.2.13 | 8.2.6 | 9.0.1 | +| coremark score | 3905.995703 | 4465.947153 | 4534.119247 | 4538.577912 | 1167.337886 | 1163.399453 | 928.348384 | 1327.051954 | 1301.659616 | 1034.714677 | 1085.304971 | diff --git a/results/classifier/deepseek-r1:14b/output/performance/2491 b/results/classifier/deepseek-r1:14b/output/performance/2491 new file mode 100644 index 000000000..cc628c945 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2491 @@ -0,0 +1,16 @@ + +Performance Regression in QEMU (amd64 Emulating LoongArch64) from 8.0.4 to 9.0.2 +Description of problem: +Previous Performance: In May 2023, we were using QEMU 8.0.4 for qemu-user emulation, and the performance was satisfactory. The setup did not include LSX (Loongson SIMD Extensions) support in either the system or QEMU. Performance results are shown in Figure A. + +Current Performance: Recently, we upgraded to QEMU 9.0.2. Both the system and QEMU now support vectorized instruction sets. However, we observed a performance decline to less than 60% of the previous benchmarks. + +We found that the slowdown is not caused by LSX. Disabling LSX compilation in the new version results in even worse performance. However, there are indeed significant differences between the two systems in terms of LSX support. +Additional information: +We use systemd-nspawn and qemu-binfmt for containerized operations. You can get a clean chroot from lcpu release [here](https://github.com/lcpu-club/loongarchlinux-dockerfile/releases/download/20240806/base-devel-loong64-20240806.tar.zst) + +Figure A, performance in May 2023 + + +Figure B, performance nowadays + diff --git a/results/classifier/deepseek-r1:14b/output/performance/2564 b/results/classifier/deepseek-r1:14b/output/performance/2564 new file mode 100644 index 000000000..f86cfdc2a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2564 @@ -0,0 +1,2 @@ + +ubuntu-22.04-s390x-all-system CI job often times out diff --git a/results/classifier/deepseek-r1:14b/output/performance/2565 b/results/classifier/deepseek-r1:14b/output/performance/2565 new file mode 100644 index 000000000..d4032aed9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2565 @@ -0,0 +1,14 @@ + +Bisected: 176e3783f2ab14 results in a heavy performance regression with the SDL interface +Description of problem: +With the patch 176e3783f2ab14 a significant 3D performance regression was introduced when using the SDL gui and VirGL. Before the patch glxgears runs at about 4000 FPS on my machine, with the patch this drops to about 150 FPS, and if one moves the mouse the reported frame rate drops even more. +Steps to reproduce: +1. Run the qemu like given above with a current Debian-SID guest +2. Start glxgears from a terminal +3. Move the mouse continuously to see the extra drop in frame rate +Additional information: +* (Guest) OpenGL Renderer string: virgl (AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 18.1.8 ...) +* Reverting the commit 176e3783f2ab14 fixes the problem on SDL +* I don't think the host kernel version is an issue here (namely the KVM patches that are required to run Venus on discrete graphics cards) +* I've seen a similar issue when using GTK, but other that with SDL it's already present in version 7.2.11 (the one I used as a "good" base when I was bisecting the regression) - so I was not able to bisect yet. +* I've looked around in the code and I'm aware the that commit *shouldn't* have the impact it seems to have. I can only assume that there is some unexpected side effect when creating the otherwise unused renderer. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2572 b/results/classifier/deepseek-r1:14b/output/performance/2572 new file mode 100644 index 000000000..75c594829 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2572 @@ -0,0 +1,31 @@ + +Guest os=Windows , qemu. Shutdown very slow. Memory allocation issue. +Description of problem: +simplifiying - libvirt config: +``` +<memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>131072</currentMemory> +``` +when use `<currentMemory>` less than `<memory>` - at/after shutdown of guest os cpu hangs on 100% and lasts long- approximately 3-5 minutes +if change to +``` +<memory unit='KiB'>33554432</memory> + <currentMemory unit='KiB'>33554432</currentMemory> +``` +then shutdown takes less some seconds + +problem occurs not (shutdown of VM takes some seconds) in cases when not used balloon device: +1 `<currentMemory>` equal to `<memory>` +2 memballoon driver disabled in windows +3 memballoon disabled on libvirt with "model=none" (and therefore not passed to qemu command line) +Additional information: +on the guest : + * used drivers from virtio-win-0.1.262.iso - membaloon ver 100.95.104.26200 + * possible combination of all or some components + +monitored next: +`virsh dommemstat VMName` at shutdown time there grows "rss" till MaxMem, but very slowly. +aLso on `virsh setmem VMName --live --size 32G` +rss grows slow - but takes 2 times less than at simple shutdown time ( = at shutdown seems occurs memory allocation and deallocation at the same time) + +so something with some or all libvirt/qemu/balloon parts not so nice diff --git a/results/classifier/deepseek-r1:14b/output/performance/2821 b/results/classifier/deepseek-r1:14b/output/performance/2821 new file mode 100644 index 000000000..1bd60379e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2821 @@ -0,0 +1,24 @@ + +Emulated newer x86 chipsets are noticably slower on cpu-bound loads than "-cpu qemu64" +Description of problem: +I noticed that "-cpu qemu64" is much faster than "-cpu max" or "-cpu Icelake-Server-noTSX" for cpu bound loads, and with more than one cpu under load. +Steps to reproduce: +1. Run a guest as per "qemu-system-x86_64 -cpu max [..]" command from above. Any linux distro should do. +2. run through the setup questions if you use Fedora-Server-KVM-41-1.4.x86_64.qcow2 from the example command line above +3. log into the guest via ssh, i.e. "ssh chris@amd64" here +4. cd /dev/shm; wget http://archive.apache.org/dist/httpd/httpd-2.4.57.tar.bz2; wget https://fluxcoil.net/files/tmp/job_httpd_extract_cpu.sh +6. bash ./job_httpd_extract_cpu.sh 4 300 +8. cat /tmp/counter + +Step 6 is executing a script which simply uses 4 parallel loops, where each loop runs "bzcat httpd-2.4.57.tar.bz2" constantly. After 300sec, the successful uncompressions over all 4 loops are summed up and stored in /tmp/counter. + +- result with "-cpu qemu64": 96 +- result with "-cpu max": 84 +- result with "-cpu Icelake-Server-noTSX": 44 +Additional information: +- For "-cpu Icelake-Server-noTSX" on this Thinkpad T590 I get these warnings, I think they are not relevant: + qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] + qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] + [..] +- I also looked at Broadwell etc, and all of them seem in the same ballpark. + Graph over some emulated architectures: https://fluxcoil.net/files/tmp/gnuplot_cpu-performance-emulated-only.png diff --git a/results/classifier/deepseek-r1:14b/output/performance/2841 b/results/classifier/deepseek-r1:14b/output/performance/2841 new file mode 100644 index 000000000..a4caa8e76 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2841 @@ -0,0 +1,12 @@ + +QEMU is increasing memory swap, the only solution is to reboot after a freeze. +Description of problem: +Swap starts increasing suddenly and gets to around 60GB before laptop freezes and “dies”. +Steps to reproduce: +Seemingly random, didn’t notice any pattern.. it just started happening more often. + + + +age__4_.png) diff --git a/results/classifier/deepseek-r1:14b/output/performance/286 b/results/classifier/deepseek-r1:14b/output/performance/286 new file mode 100644 index 000000000..fd8e3eb7c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/286 @@ -0,0 +1,2 @@ + +Performance degradation for WinXP boot time after b55f54bc diff --git a/results/classifier/deepseek-r1:14b/output/performance/290 b/results/classifier/deepseek-r1:14b/output/performance/290 new file mode 100644 index 000000000..0c82c908d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/290 @@ -0,0 +1,2 @@ + +mmap MAP_NORESERVE of 2^42 bytes consumes 16Gb of actual RAM diff --git a/results/classifier/deepseek-r1:14b/output/performance/2946 b/results/classifier/deepseek-r1:14b/output/performance/2946 new file mode 100644 index 000000000..7fa840ba7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2946 @@ -0,0 +1,11 @@ + +crypto/aes.c (used for emulating aes instructions) has a timing side-channel +Description of problem: +https://gitlab.com/qemu-project/qemu/-/blob/a9cd5bc6399a80fcf233ed0fffe6067b731227d8/crypto/aes.c#L1021 + +much of the code in crypto/aes.c accesses memory arrays where the array index is based on the secret data being encrypted/decrypted. because of cpu caches and other things that can delay memory accesses based on their address, this is a timing side-channel, potentially allowing leaking secrets over a network based on timing how long cryptography operations take. + +compare to openssl which uses an algorithm where its execution time doesn't depend on the data being processed: +https://github.com/openssl/openssl/commit/0051746e03c65f5970d8ca424579d50f58a877e0 + +I initially reported this as a security issue, but was told that since it's only used by TCG, it isn't a security issue, since TCG isn't considered secure. diff --git a/results/classifier/deepseek-r1:14b/output/performance/2964 b/results/classifier/deepseek-r1:14b/output/performance/2964 new file mode 100644 index 000000000..f7a9edaca --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/2964 @@ -0,0 +1,10 @@ + +How to get the icount value after qemu terminal exit +Description of problem: + +Steps to reproduce: +1. +2. +3. +Additional information: +/label ~"kind::Bug" diff --git a/results/classifier/deepseek-r1:14b/output/performance/322602 b/results/classifier/deepseek-r1:14b/output/performance/322602 new file mode 100644 index 000000000..bc21babb0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/322602 @@ -0,0 +1,16 @@ + +Snapshot usage makes qcow2 image unusable due to large tables + +To reproduce with 0.9.1 and svn: +- Create a 20G (or some size much greater than system RAM) qcow2 image +- Inside VM, install some OS, formatting whole drive +- Create snapshot with savevm +- Inside VM, reformat and reinstall OS +- Create snapshot with savevm +[...] + +Eventually, qemu crashes, then neither qemu-img nor qemu can open the image because memory is exhausted. The reason is that the whole refcount_table is loaded into memory, and this refcount_table has now become much bigger than the size of memory. + +The refcount_table really needs to be loaded and used in fixed size chunks to avoid this problem. + +Alternatively, there needs to be a way to "rollback" a snapshot without loading the whole disk image normally, so that a snapshot which has made the image unusable in this way can be reversed. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/334 b/results/classifier/deepseek-r1:14b/output/performance/334 new file mode 100644 index 000000000..307fbf04d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/334 @@ -0,0 +1,2 @@ + +macOS App Nap feature gradually freezes QEMU process diff --git a/results/classifier/deepseek-r1:14b/output/performance/404 b/results/classifier/deepseek-r1:14b/output/performance/404 new file mode 100644 index 000000000..729de88a2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/404 @@ -0,0 +1,2 @@ + +Windows XP takes much longer to boot in TCG mode since 5.0 diff --git a/results/classifier/deepseek-r1:14b/output/performance/466 b/results/classifier/deepseek-r1:14b/output/performance/466 new file mode 100644 index 000000000..57dab00cd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/466 @@ -0,0 +1,2 @@ + +3x 100% host CPU core usage while virtual machine is in idle diff --git a/results/classifier/deepseek-r1:14b/output/performance/568228 b/results/classifier/deepseek-r1:14b/output/performance/568228 new file mode 100644 index 000000000..f528cdc05 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/568228 @@ -0,0 +1,259 @@ + +/home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error + +I get the following error each time I start emulation in QEMU 0.12.3 on a Sun SunFire 280R running Debian Lenny 5.03 for Sparc64: + +/home/qemu-0.12.3/tcg/tcg.c:1367: tcg fatal error + +I had the same problem in Qemu 0.11.1. + +Here are informations about my system, I am not a programmer so I don't know what information to give, if you need more info just ask me: + +sunfire:/home# uname -a +Linux sunfire 2.6.26 #1 Thu Apr 8 17:09:17 EDT 2010 sparc64 GNU/Linux +sunfire:/home# dmesg +nges: +[ 0.000000] Normal 0 -> 130933 +[ 0.000000] Movable zone start PFN for each node +[ 0.000000] early_node_map[7] active PFN ranges +[ 0.000000] 0: 0 -> 129023 +[ 0.000000] 0: 129024 -> 130666 +[ 0.000000] 0: 130796 -> 130803 +[ 0.000000] 0: 130805 -> 130815 +[ 0.000000] 0: 130818 -> 130826 +[ 0.000000] 0: 130828 -> 130916 +[ 0.000000] 0: 130919 -> 130933 +[ 0.000000] On node 0 totalpages: 130792 +[ 0.000000] Normal zone: 896 pages used for memmap +[ 0.000000] Normal zone: 0 pages reserved +[ 0.000000] Normal zone: 129896 pages, LIFO batch:15 +[ 0.000000] Movable zone: 0 pages used for memmap +[ 0.000000] Booting Linux... +[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129896 +[ 0.000000] Kernel command line: root=/dev/sdb2 ro +[ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) +[ 0.000000] clocksource: mult[c80000] shift[16] +[ 0.000000] clockevent: mult[147ae14] shift[32] +[ 380.165881] Console: colour dummy device 80x25 +[ 380.183520] console handover: boot [earlyprom0] -> real [tty0] +[ 380.208131] Dentry cache hash table entries: 131072 (order: 7, 1048576 bytes) +[ 380.210503] Inode-cache hash table entries: 65536 (order: 6, 524288 bytes) +[ 380.235415] Memory: 1022064k available (4952k kernel code, 2064k data, 192k init) [fffff80000000000,000000003feea000] +[ 380.312667] Calibrating delay using timer specific routine.. 9.99 BogoMIPS (lpj=19990) +[ 380.312839] Security Framework initialized +[ 380.312870] SELinux: Disabled at boot. +[ 380.312889] Capability LSM initialized +[ 380.312935] Mount-cache hash table entries: 512 +[ 380.313505] Initializing cgroup subsys ns +[ 380.313524] Initializing cgroup subsys cpuacct +[ 380.313536] Initializing cgroup subsys devices +[ 380.314346] net_namespace: 1208 bytes +[ 380.314892] NET: Registered protocol family 16 +[ 380.325288] PCI: Probing for controllers. +[ 380.325332] /pci@8,700000: SCHIZO PCI Bus Module ver[4:0] +[ 380.325349] /pci@8,700000: PCI IO[7ffef000000] MEM[7fe00000000] +[ 380.329864] /pci@8,600000: SCHIZO PCI Bus Module ver[4:0] +[ 380.329881] /pci@8,600000: PCI IO[7ffed000000] MEM[7fd00000000] +[ 380.334466] PCI: Scanning PBM /pci@8,600000 +[ 380.334976] PCI: Scanning PBM /pci@8,700000 +[ 380.336347] ebus0: [flashprom] [bbc] [ppm] [i2c -> (dimm-fru) (dimm-fru) (dimm-fru) (dimm-fru) (nvram) (idprom)] [i2c -> (cpu-fru) (temperature) (fan-control) (motherboard-fru) (i2c-bridge)] [beep] [rtc] [gpio] [pmc] [floppy] [parallel] [serial] +[ 380.349031] usbcore: registered new interface driver usbfs +[ 380.349274] usbcore: registered new interface driver hub +[ 380.349452] usbcore: registered new device driver usb +[ 380.353275] /pci@8,700000/ebus@5/rtc@1,300070: Clock regs at 000007fe7e300070 +[ 380.354631] NET: Registered protocol family 2 +[ 380.356677] Switched to high resolution mode on CPU 0 +[ 380.388803] IP route cache hash table entries: 8192 (order: 3, 65536 bytes) +[ 380.389510] TCP established hash table entries: 32768 (order: 6, 524288 bytes) +[ 380.391238] TCP bind hash table entries: 32768 (order: 5, 262144 bytes) +[ 380.392036] TCP: Hash tables configured (established 32768 bind 32768) +[ 380.392052] TCP reno registered +[ 380.400796] NET: Registered protocol family 1 +[ 380.401078] checking if image is initramfs... it is +[ 381.658428] Freeing initrd memory: 5829k freed +[ 381.659077] Mini RTC Driver +[ 381.659365] /memory-controller@0,400000: US3 memory controller at 0000040000400000 [ACTIVE] +[ 381.660085] audit: initializing netlink socket (disabled) +[ 381.660134] type=2000 audit(1271905721.644:1): initialized +[ 381.660454] Total HugeTLB memory allocated, 0 +[ 381.660756] VFS: Disk quotas dquot_6.5.1 +[ 381.660865] Dquot-cache hash table entries: 1024 (order 0, 8192 bytes) +[ 381.661363] Installing knfsd (copyright (C) 1996 <email address hidden>). +[ 381.662280] NTFS driver 2.1.29 [Flags: R/W]. +[ 381.662397] msgmni has been set to 2009 +[ 381.662746] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) +[ 381.662775] io scheduler noop registered +[ 381.662788] io scheduler anticipatory registered +[ 381.662801] io scheduler deadline registered +[ 381.662844] io scheduler cfq registered (default) +[ 381.668602] Console: switching to colour frame buffer device 80x30 +[ 381.672374] fb0: TVP4020 frame buffer device, memory = 8192K. +[ 381.681745] [drm] Initialized drm 1.1.0 20060810 +[ 381.683020] f0086398: ttyS0 at MMIO 0x7fe7e400000 (irq = 10) is a SAB82532 V3.2 +[ 381.686005] f0086398: ttyS1 at MMIO 0x7fe7e400040 (irq = 10) is a SAB82532 V3.2 +[ 381.694246] brd: module loaded +[ 381.698234] loop: module loaded +[ 381.700507] sungem.c:v0.98 8/24/03 David S. Miller (<email address hidden>) +[ 381.703764] PHY ID: 18074c1, addr: 0 +[ 381.704753] eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:12:bb:58 +[ 381.707196] eth0: Found Generic MII PHY +[ 381.709903] Uniform Multi-Platform E-IDE driver +[ 381.712557] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx +[ 381.719917] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver +[ 381.719963] ohci_hcd 0000:00:05.3: OHCI Host Controller +[ 381.723674] ohci_hcd 0000:00:05.3: new USB bus registered, assigned bus number 1 +[ 381.731670] ohci_hcd 0000:00:05.3: irq 13, io mem 0x7fe01000000 +[ 381.792942] usb usb1: configuration #1 chosen from 1 choice +[ 381.797235] hub 1-0:1.0: USB hub found +[ 381.801563] hub 1-0:1.0: 4 ports detected +[ 381.909230] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 +[ 381.913796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 +[ 381.923701] usb usb1: Product: OHCI Host Controller +[ 381.928419] usb usb1: Manufacturer: Linux 2.6.26 ohci_hcd +[ 381.933108] usb usb1: SerialNumber: 0000:00:05.3 +[ 381.937761] USB Universal Host Controller Interface driver v3.0 +[ 381.942637] mice: PS/2 mouse device common for all mice +[ 382.164665] usb 1-2: new low speed USB device using ohci_hcd and address 2 +[ 382.331310] usb 1-2: configuration #1 chosen from 1 choice +[ 382.336918] usb 1-2: New USB device found, idVendor=049f, idProduct=000e +[ 382.341070] usb 1-2: New USB device strings: Mfr=4, Product=20, SerialNumber=0 +[ 382.349921] usb 1-2: Product: Compaq Internet Keyboard +[ 382.354146] usb 1-2: Manufacturer: Chicony +[ 382.612663] usb 1-3: new full speed USB device using ohci_hcd and address 3 +[ 382.777825] usb 1-3: configuration #1 chosen from 1 choice +[ 382.783275] usb 1-3: New USB device found, idVendor=058f, idProduct=6387 +[ 382.787329] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 +[ 382.791996] usb 1-3: Product: Mass Storage +[ 382.795814] usb 1-3: Manufacturer: Generic +[ 382.799482] usb 1-3: SerialNumber: 0AC899D6 +[ 383.056664] usb 1-4: new low speed USB device using ohci_hcd and address 4 +[ 383.221349] usb 1-4: configuration #1 chosen from 1 choice +[ 383.226691] usb 1-4: New USB device found, idVendor=045e, idProduct=0039 +[ 383.230537] usb 1-4: New USB device strings: Mfr=1, Product=3, SerialNumber=0 +[ 383.235076] usb 1-4: Product: Microsoft 5-Button Mouse with IntelliEye(TM) +[ 383.238730] usb 1-4: Manufacturer: Microsoft +[ 383.248269] input: Chicony Compaq Internet Keyboard as /class/input/input0 +[ 383.264794] input,hidraw0: USB HID v1.10 Keyboard [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +[ 383.286678] input: Chicony Compaq Internet Keyboard as /class/input/input1 +[ 383.304765] input,hidraw1: USB HID v1.10 Device [Chicony Compaq Internet Keyboard] on usb-0000:00:05.3-2 +[ 383.317738] input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input2 +[ 383.340859] input,hidraw2: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:05.3-4 +[ 383.349107] usbcore: registered new interface driver usbhid +[ 383.353153] usbhid: v2.6:USB HID core driver +[ 383.357245] Advanced Linux Sound Architecture Driver Version 1.0.16. +[ 383.402450] PCI: Enabling device: (0000:00:03.0), cmd 1 +[ 384.100863] eth0: Link is up at 100 Mbps, full-duplex. +[ 384.846600] usbcore: registered new interface driver snd-usb-audio +[ 384.851077] ALSA device list: +[ 384.855394] #0: Ensoniq AudioPCI ENS1371 at 0x7ffef000500, irq 17 +[ 384.861036] TCP cubic registered +[ 384.865480] NET: Registered protocol family 17 +[ 384.870147] RPC: Registered udp transport module. +[ 384.874530] RPC: Registered tcp transport module. +[ 384.879100] registered taskstats version 1 +[ 384.883476] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) +[ 386.429586] SCSI subsystem initialized +[ 386.509039] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[12] MMIO=[7fe00120000-7fe001207ff] Max Packet=[2048] IR/IT contexts=[4/4] +[ 386.596175] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +[ 386.600382] PCI: Enabling device: (0001:00:04.0), cmd 3 +[ 386.602464] qla2xxx 0001:00:04.0: Found an ISP2200, irq 20, iobase 0x000007fd00100000 +[ 386.612339] qla2xxx 0001:00:04.0: Configuring PCI space... +[ 386.616586] qla2xxx 0001:00:04.0: Configure NVRAM parameters... +[ 386.714919] qla2xxx 0001:00:04.0: Inconsistent NVRAM detected: checksum=0x0 id=<4>qla2xxx 0001:00:04.0: Falling back to functioning (yet invalid -- WWPN) defaults. +[ 386.728340] qla2xxx 0001:00:04.0: Verifying loaded RISC code... +[ 386.734153] PCI: Enabling device: (0000:00:06.0), cmd 147 +[ 386.735307] sym0: <875> rev 0x37 at pci 0000:00:06.0 irq 14 +[ 386.826112] sym0: No NVRAM, ID 7, Fast-20, SE, parity checking +[ 386.837235] sym0: SCSI BUS has been reset. +[ 386.841214] scsi1 : sym-2.2.3 +[ 386.847653] PCI: Enabling device: (0000:00:06.1), cmd 147 +[ 386.848824] sym1: <875> rev 0x37 at pci 0000:00:06.1 irq 15 +[ 386.939517] sym1: No NVRAM, ID 7, Fast-20, SE, parity checking +[ 386.950672] sym1: SCSI BUS has been reset. +[ 386.954818] scsi2 : sym-2.2.3 +[ 386.965219] firmware: requesting ql2200_fw.bin +[ 387.039293] Initializing USB Mass Storage driver... +[ 387.043558] scsi3 : SCSI emulation for USB Mass Storage devices +[ 387.050004] usbcore: registered new interface driver usb-storage +[ 387.054012] USB Mass Storage support registered. +[ 387.057924] usb-storage: device found at 3 +[ 387.057930] usb-storage: waiting for device to settle before scanning +[ 388.004887] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0003bafffe12bb58] +[ 391.590521] scsi 1:0:6:0: CD-ROM TOSHIBA DVD-ROM SD-M1401 1009 PQ: 0 ANSI: 2 +[ 391.599122] target1:0:6: Beginning Domain Validation +[ 391.603264] target1:0:6: asynchronous +[ 391.608968] target1:0:6: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16) +[ 391.614104] target1:0:6: Domain Validation skipping write tests +[ 391.618025] target1:0:6: Ending Domain Validation +[ 392.057675] usb-storage: device scan complete +[ 392.063643] scsi 3:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 2 +[ 394.008952] Driver 'sr' needs updating - please use bus_type methods +[ 394.017708] sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray +[ 394.021916] Uniform CD-ROM driver Revision: 3.20 +[ 394.026310] sr 1:0:6:0: Attached scsi CD-ROM sr0 +[ 394.056732] sr 1:0:6:0: Attached scsi generic sg0 type 5 +[ 394.357542] scsi 3:0:0:0: Attached scsi generic sg1 type 0 +[ 394.413753] Driver 'sd' needs updating - please use bus_type methods +[ 394.437062] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +[ 394.450042] sd 3:0:0:0: [sda] Write Protect is off +[ 394.454315] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +[ 394.454322] sd 3:0:0:0: [sda] Assuming drive cache: write through +[ 394.481010] sd 3:0:0:0: [sda] 4103936 512-byte hardware sectors (2101 MB) +[ 394.493994] sd 3:0:0:0: [sda] Write Protect is off +[ 394.498261] sd 3:0:0:0: [sda] Mode Sense: 03 00 00 00 +[ 394.498268] sd 3:0:0:0: [sda] Assuming drive cache: write through +[ 394.502483] sda: +[ 394.548320] sd 3:0:0:0: [sda] Attached SCSI removable disk +[ 397.912726] qla2xxx 0001:00:04.0: Allocated (252 KB) for firmware dump... +[ 398.044667] qla2xxx 0001:00:04.0: LIP reset occured (f8ef). +[ 398.049170] scsi0 : qla2xxx +[ 398.054582] qla2xxx 0001:00:04.0: +[ 398.054586] QLogic Fibre Channel HBA Driver: 8.02.01-k4 +[ 398.054590] QLogic QLA22xx - +[ 398.054592] ISP2200: PCI (66 MHz) @ 0001:00:04.0 hdma-, host#=0, fw=2.02.08 TP +[ 398.091669] qla2xxx 0001:00:04.0: LIP occured (f8ef). +[ 398.097133] qla2xxx 0001:00:04.0: LOOP UP detected (1 Gbps). +[ 398.110704] scsi 0:0:0:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +[ 398.126430] scsi 0:0:1:0: Direct-Access SEAGATE ST336605FSUN36G 0638 PQ: 0 ANSI: 3 +[ 398.144907] scsi: waiting for bus probes to complete ... +[ 398.153043] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +[ 398.159977] sd 0:0:0:0: [sdb] Write Protect is off +[ 398.164380] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +[ 398.168750] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.181593] sd 0:0:0:0: [sdb] 71132959 512-byte hardware sectors (36420 MB) +[ 398.188754] sd 0:0:0:0: [sdb] Write Protect is off +[ 398.193390] sd 0:0:0:0: [sdb] Mode Sense: db 00 10 08 +[ 398.197775] sd 0:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.207949] sdb: sdb1 sdb2 sdb3 sdb4 +[ 398.219180] sd 0:0:0:0: [sdb] Attached SCSI disk +[ 398.223902] sd 0:0:0:0: Attached scsi generic sg2 type 0 +[ 398.232492] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +[ 398.239757] sd 0:0:1:0: [sdc] Write Protect is off +[ 398.244397] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +[ 398.249021] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.262681] sd 0:0:1:0: [sdc] 71132959 512-byte hardware sectors (36420 MB) +[ 398.270173] sd 0:0:1:0: [sdc] Write Protect is off +[ 398.274917] sd 0:0:1:0: [sdc] Mode Sense: db 00 10 08 +[ 398.279543] sd 0:0:1:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA +[ 398.289888] sdc: sdc1 sdc3 +[ 398.304581] sd 0:0:1:0: [sdc] Attached SCSI disk +[ 398.309417] sd 0:0:1:0: Attached scsi generic sg3 type 0 +[ 398.768132] kjournald starting. Commit interval 5 seconds +[ 398.772864] EXT3-fs: mounted filesystem with ordered data mode. +[ 401.026534] udevd version 125 started +[ 405.141436] Adding 1566320k swap on /dev/sdb4. Priority:-1 extents:1 across:1566320k +[ 405.604286] EXT3 FS on sdb2, internal journal +[ 408.242503] eth0: Link is up at 100 Mbps, full-duplex. +[ 408.249685] eth0: Pause is disabled +[ 410.325778] NET: Registered protocol family 10 +[ 410.330075] lo: Disabled Privacy Extensions +[ 414.287849] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory +[ 414.307535] NFSD: starting 90-second grace period +[ 418.763886] NET: Registered protocol family 5 +[ 420.772658] eth0: no IPv6 routers present +[ 550.132380] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a380) on /dev/pts/0 +[ 550.132405] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a388) on /dev/pts/0 +[ 550.132420] ioctl32(xfce4-terminal:3010): Unknown cmd fd(8) cmd(0000530b){t:'S';sz:0} arg(f7e8a390) on /dev/pts/0 +[ 2388.411343] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a380) on /dev/pts/1 +[ 2388.411368] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a388) on /dev/pts/1 +[ 2388.411383] ioctl32(synaptic:3478): Unknown cmd fd(16) cmd(0000530b){t:'S';sz:0} arg(f755a390) on /dev/pts/1 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/601946 b/results/classifier/deepseek-r1:14b/output/performance/601946 new file mode 100644 index 000000000..b49c5b4fa --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/601946 @@ -0,0 +1,7 @@ + +[Feature request] qemu-img multi-threaded compressed image conversion + +Feature request: +qemu-img multi-threaded compressed image conversion + +Suppose I want to convert raw image to compressed qcow2. Multi-threaded conversion will be much faster, because bottleneck is compressing data. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/630 b/results/classifier/deepseek-r1:14b/output/performance/630 new file mode 100644 index 000000000..7171ce324 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/630 @@ -0,0 +1,2 @@ + +ubuntu-18.04-s390x-all job timeouts at 1h diff --git a/results/classifier/deepseek-r1:14b/output/performance/642 b/results/classifier/deepseek-r1:14b/output/performance/642 new file mode 100644 index 000000000..e66a891ab --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/642 @@ -0,0 +1,5 @@ + +Slow QEMU I/O on macOS host +Description of problem: +QEMU on macOS host gives very low I/O speed. Tested with fio tool, compared to linux host +Tested on QEMU v6.1.0, and the recent master diff --git a/results/classifier/deepseek-r1:14b/output/performance/672 b/results/classifier/deepseek-r1:14b/output/performance/672 new file mode 100644 index 000000000..c690f7b3b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/672 @@ -0,0 +1,4 @@ + +Slow emulation of mac99 (PowerPC G4) due to being single-threaded. +Additional information: +None diff --git a/results/classifier/deepseek-r1:14b/output/performance/693 b/results/classifier/deepseek-r1:14b/output/performance/693 new file mode 100644 index 000000000..b90e799ed --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/693 @@ -0,0 +1,11 @@ + +Qemu increased memory usage with TCG +Description of problem: +The issue is that instances that are supposed to use only a small amount of memory (like 256MB) suddenly use a much higher amount of RSS when running the accel=tcg, around 512MB in the above example. This was not happening with qemu-4.2 (on Ubuntu 20.04). This is also not happening when using accel=kvm instead. The issue has been first noticed on Debian 11 (Bullseye) with the versions above, but it is happening in the same way on Centos 8 Stream, Ubuntu 21.10 and a pre-release version of Ubuntu 22.04. It also also seen when testing with qemu-6.1 built from source. +Steps to reproduce: +1. Deploy devstack (https://opendev.org/openstack/devstack) with VIRT_TYPE=qemu on a VM +2. Start an instance with cirros image and a flavor allocating 256MB +3. Do a ps and see a RSS size of about 512MB being used after the instance has finished booting +4. Expected result (seen with qemu-4.2 or VIRT_TYPE=kvm): RSS stays < 256MB +Additional information: +I can try to find a smaller commandline for manual reproduction if needed. The above sample is generated by OpenStack Nova via libvirt. diff --git a/results/classifier/deepseek-r1:14b/output/performance/719 b/results/classifier/deepseek-r1:14b/output/performance/719 new file mode 100644 index 000000000..8e525eeda --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/719 @@ -0,0 +1,20 @@ + +live migration's performance with compression enabled is much worse than compression disabled +Description of problem: + +Steps to reproduce: +1. Run QEMU the Guests with 1Gpbs network on source host and destination host with QEMU command line +2. Run some memory work loads on Guest, for example, ./memtester 1G 1 +3. Set migration parameters in QEMU monitor. On source and destination, + execute: #migrate_set_capability compress on + Other compression parameters are all default. +4. Run migrate command, # migrate -d tcp:10.156.208.154:4000 +5. The results: + - without compression： total time: 197366 ms throughput: 937.81 mbps transferred Ram: 22593703 kbytes + - with compression: total time: 281711 ms throughput: 90.24 mbps transferred Ram: 3102898 kbytes + +When compression is enabled, the compression transferred ram is reduced a lot. But the throughput is down badly. +The total time of live migration with compression is longer than without compression. +I tried with 100G network bandwidth, it also has the same problem. +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/performance/753916 b/results/classifier/deepseek-r1:14b/output/performance/753916 new file mode 100644 index 000000000..a01302f2a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/753916 @@ -0,0 +1,5 @@ + +performance bug with SeaBios 0.6.x + +in my tests SeaBios 0.5.1 has the best performance (100% faster) +i run qemu port in windows xp (phenom II x4 945, 4 gigas ram DDR3) and windows xp (Pentium 4, 1 giga ram ddr) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/767 b/results/classifier/deepseek-r1:14b/output/performance/767 new file mode 100644 index 000000000..fe79c516c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/767 @@ -0,0 +1,4 @@ + +Improve softmmu TLB utilisation by improving tlb_flush usage on PPC64 +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/performance/80 b/results/classifier/deepseek-r1:14b/output/performance/80 new file mode 100644 index 000000000..353e58bc3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/80 @@ -0,0 +1,2 @@ + +[Feature request] qemu-img multi-threaded compressed image conversion diff --git a/results/classifier/deepseek-r1:14b/output/performance/861 b/results/classifier/deepseek-r1:14b/output/performance/861 new file mode 100644 index 000000000..a51da8dbc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/861 @@ -0,0 +1,2 @@ + +Using qemu+kvm is slower than using qemu in rv6(xv6 rust porting) diff --git a/results/classifier/deepseek-r1:14b/output/performance/919 b/results/classifier/deepseek-r1:14b/output/performance/919 new file mode 100644 index 000000000..517d3754e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/919 @@ -0,0 +1,6 @@ + +Slow in Windows +Description of problem: +Eg . Win8.1 in QEMU on Windows is very slow and other os also are very slow +Steps to reproduce: +Just run a qemu instance diff --git a/results/classifier/deepseek-r1:14b/output/performance/959 b/results/classifier/deepseek-r1:14b/output/performance/959 new file mode 100644 index 000000000..18de7d650 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/959 @@ -0,0 +1,10 @@ + +100% CPU utilization when the guest is idle (FreeBSD on M1 Mac) +Description of problem: +100% CPU utilization when the guest is idle. +Steps to reproduce: +1. Download the FreeBSD qcow2 image and decompress it: https://download.freebsd.org/releases/VM-IMAGES/13.0-RELEASE/aarch64/Latest/ +2. Execute the above command. +3. The QEMU process consumes 100% CPU. +4. + diff --git a/results/classifier/deepseek-r1:14b/output/performance/965867 b/results/classifier/deepseek-r1:14b/output/performance/965867 new file mode 100644 index 000000000..c5fd5e719 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/965867 @@ -0,0 +1,49 @@ + +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 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/performance/973 b/results/classifier/deepseek-r1:14b/output/performance/973 new file mode 100644 index 000000000..20f3d4523 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/973 @@ -0,0 +1,20 @@ + +qemu 6.2 memory leak when failed to boot and infinitely reboot +Description of problem: +qemu allocates tons of memory (very likely memory leak) in certain (rare) cases. + +When I misconfigured qemu so that I have run a bigger linux kernel within insufficient memory (for example 8M bzImage while 16M ram and no hdd), the kernel will obviously fail to boot. In this case qemu will reboot (likely the linux kernel reboots). However reboot does not solve the problem, causing qemu to repeatedly reboot. + +Memory usage of qemu raises sharply in the progress. +Steps to reproduce: +1. Get any linux kernel (tested with 5.15.33) +2. Run the kernel on qemu, with memory smaller than necessary +Additional information: +A reproducing dockerfile: +``` +FROM alpine:3.15 + +RUN apk add qemu-system-x86_64 linux-virt + +CMD ["/usr/bin/qemu-system-x86_64", "-kernel", "/boot/vmlinuz-virt", "-nographic", "-net", "none", "-m", "16M"] +``` diff --git a/results/classifier/deepseek-r1:14b/output/performance/997631 b/results/classifier/deepseek-r1:14b/output/performance/997631 new file mode 100644 index 000000000..5de4ee009 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/performance/997631 @@ -0,0 +1,18 @@ + +Windows 2008R2 very slow cold boot when 4 CPUs + +Hi, + +well, I'm in a similar boat as the one in #992067. But regardless any memory-settings. +It takes "ages" in a cold-boot Windows 2008R2 with qemu-1.0.1, qemu-1.0.50 and latest-n-greatest from today ( 1.0.50 /qemu-1b3e76e ). It eats up 400% host-cpu-load until login-prompt is shown on the console. + +Meanwhile I tried couple of settings with "-cpu features (hv_spinlocks), hv_relaxed and hv_vapic. ". +Due to some Clock-glitches I start qemu-system-x86_64 with "-no-hpet". + +With 2 processors the system is up after 2 minutes, with 4 procs almost 10 minutes... After a reset ( warmstart) the 4 proc-system is up after a couple of 20 secs. + +Hints welcome, though once started, the system seems to operate "normally". + +Thnx in@vance, + +Oliver. \ No newline at end of file |